From ohadlevy at redhat.com Sun Jul 1 06:12:06 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Sun, 01 Jul 2012 09:12:06 +0300 Subject: [katello-devel] Foreman api work In-Reply-To: <4FE32E15.30507@redhat.com> References: <4FE31A85.4030303@redhat.com> <4FE32E15.30507@redhat.com> Message-ID: <4FEFEA36.9020805@redhat.com> On 06/21/2012 05:22 PM, Bryan Kearney wrote: > On 06/21/2012 08:58 AM, Tomas Strachota wrote: >> Just an announcement for the team: >> >> Martin and me have started to work on splitting the Foreman's >> controllers to ui and api part. >> If anyone is interested, we share the code here: >> >> https://github.com/mbacovsky/foreman/tree/api >> > So, will the pattern be to remote the json code from the regular > controllers? The idea is to make V1 of the API identical to the api today (where it makes sense), and do V2 closely after, where we could tell people to just add /api to the url, and for new api stuff, use the version header. Ohad > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From ohadlevy at redhat.com Sun Jul 1 06:13:14 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Sun, 01 Jul 2012 09:13:14 +0300 Subject: [katello-devel] Running Foreman tests - need to change settings.yaml In-Reply-To: <20120622130053.GA9421@localhost.localdomain> References: <20120622130053.GA9421@localhost.localdomain> Message-ID: <4FEFEA7A.6070709@redhat.com> On 06/22/2012 04:00 PM, Chris Alfonso wrote: > I'm posting this on katello-devel even though this is a Foreman tidbit > because of the integration work that's ramping up. > > It was not apparent to me that I would need to set the login setting to > 'true' to get the foreman tests to run. Is there another way to run the > tests successfully without changing the login setting default value? If > not, any reason to not just have the default set to 'true'? If we need > to keep the default set to true, perhaps documenting this in the Foreman > README. > > - Chris I guess the other way to handle it, is for each of those tests, simply turn on login? Ohad From bkearney at redhat.com Sun Jul 1 13:44:00 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Sun, 01 Jul 2012 09:44:00 -0400 Subject: [katello-devel] Log in Interstitial and Manage organizations In-Reply-To: <073eb4e2-8e91-4561-a22a-6081f7957dd1@zmail16.collab.prod.int.phx2.redhat.com> References: <073eb4e2-8e91-4561-a22a-6081f7957dd1@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4FF05420.8050206@redhat.com> On 06/28/2012 12:42 PM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Malini Rao" >> To: katello-devel at redhat.com >> Sent: Thursday, June 28, 2012 12:05:47 PM >> Subject: [katello-devel] Log in Interstitial and Manage organizations >> >> Hey Jason, >> >> As we mentioned in the Converge UI meeting yesterday, Kyle and I have >> been putting together the modified screens for the Org selection as >> part of log in and also the relocation of the original 'Manage >> Organizations' interstitial page. This is not far from what you are >> currently implementing for this iteration but irons out some of the >> wrinkles from the user expectation and perception point of view and >> mostly in terms of visual design. >> >> We also covered some details around where to set/ reset the default >> org etc. > > Not sure what meetings this was discussed in, but be careful about what you mean by "default organization." I have it on my list of things to make the user tab for "Environments" change to accurate reflect what it really is: This is the default environment that a system, when registered by that user, gets placed in and nothing more. > > I think the concept of a default organization (ie. where the user logs into by default) is valid but it doesn't exist today, as far as I know. Someone correct me? In any case, they are two entirely separate concepts. Well.. the default ENV kinda suggests a default org, but I agree they could be different. - bk From msuchy at redhat.com Mon Jul 2 01:37:48 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Mon, 02 Jul 2012 03:37:48 +0200 Subject: [katello-devel] unneccessery packages in rhel6 Message-ID: <4FF0FB6C.3060800@redhat.com> These packages are in our rhel6 yum repo, but they are neither listed in none our package as Require, nor they are installed during "yum install katello-all": glassfish-javamail-repolib jline-repolib ragel ruby-hpricot rubygem-awesome_print rubygem-capistrano rubygem-highline rubygem-hpricot rubygem-macaddr rubygem-multimap rubygem-net-scp rubygem-net-sftp rubygem-net-ssh rubygem-net-ssh-gateway rubygem-redis rubygem-redis-namespace rubygem-redisk rubygem-resque rubygem-resque-status rubygem-ronn rubygem-tilt rubygem-vegas rubygem-will_paginate Can I safely assume that we do not need them and I can get rid of them? Raise your voice now or forever hold your peace! Mirek From msuchy at redhat.com Mon Jul 2 06:07:47 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Mon, 02 Jul 2012 08:07:47 +0200 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <3337eac9-ee6a-4942-b191-b8adcb44a733@zmail11.collab.prod.int.phx2.redhat.com> References: <3337eac9-ee6a-4942-b191-b8adcb44a733@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <4FF13AB3.9000702@redhat.com> On 27.6.2012 16:16, Og Maciel wrote: > To be honest, why can't we use a UID for this? Did you ever dig into regedit in Windows? Users are not supposed to edit it by hand too, but they did sometime. Mirek From inecas at redhat.com Mon Jul 2 07:01:48 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 02 Jul 2012 09:01:48 +0200 Subject: [katello-devel] API documentation In-Reply-To: <4FEED892.1080704@redhat.com> References: <4FEC5F37.3070806@redhat.com> <4FEED892.1080704@redhat.com> Message-ID: <4FF1475C.4010700@redhat.com> On 06/30/2012 12:44 PM, Miroslav Suchy wrote: > On 28.6.2012 15:42, Tomas Strachota wrote: >> Hello team, >> our api documentation efforts are slowly moving. We've got 4 controllers >> finished and 1 assigned but there are still 32 left untouched. We can >> speed it up a lot if everybody takes one and looks at it. It's not >> difficult as we have basic docs already automatically generated. You >> only have to check the parameters and fill in some meaningful >> descriptions. >> >> Those two links will show you where to start: >> https://fedorahosted.org/katello/wiki/ApiDocHowto >> https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > > Can we have subpackage katello-api-doc, which will contain those > static pages? Definitely +1. We will need to incorporate it to our build process once the changes are merged into master. -- Ivan > > Mirek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From lzap at redhat.com Mon Jul 2 10:21:38 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 2 Jul 2012 12:21:38 +0200 Subject: [katello-devel] unneccessery packages in rhel6 In-Reply-To: <4FF0FB6C.3060800@redhat.com> References: <4FF0FB6C.3060800@redhat.com> Message-ID: <20120702102138.GA3743@lzapx.brq.redhat.com> Which repo, I don't see them? http://download.lab.bos.redhat.com/rel-eng/CloudForms/1.0.1/latest/el6-se/x86_64/os/Packages/ LZ On Mon, Jul 02, 2012 at 03:37:48AM +0200, Miroslav Suchy wrote: > These packages are in our rhel6 yum repo, but they are neither > listed in none our package as Require, nor they are installed during > "yum install katello-all": > > glassfish-javamail-repolib > jline-repolib > ragel > ruby-hpricot > rubygem-awesome_print > rubygem-capistrano > rubygem-highline > rubygem-hpricot > rubygem-macaddr > rubygem-multimap > rubygem-net-scp > rubygem-net-sftp > rubygem-net-ssh > rubygem-net-ssh-gateway > rubygem-redis > rubygem-redis-namespace > rubygem-redisk > rubygem-resque > rubygem-resque-status > rubygem-ronn > rubygem-tilt > rubygem-vegas > rubygem-will_paginate > > Can I safely assume that we do not need them and I can get rid of them? > > Raise your voice now or forever hold your peace! > > Mirek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Mon Jul 2 11:28:29 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 02 Jul 2012 13:28:29 +0200 Subject: [katello-devel] unneccessery packages in rhel6 In-Reply-To: <20120702102138.GA3743@lzapx.brq.redhat.com> References: <4FF0FB6C.3060800@redhat.com> <20120702102138.GA3743@lzapx.brq.redhat.com> Message-ID: <4FF185DD.9000408@redhat.com> On 07/02/2012 12:21 PM, Lukas Zapletal wrote: > Which repo, I don't see them? > > http://download.lab.bos.redhat.com/rel-eng/CloudForms/1.0.1/latest/el6-se/x86_64/os/Packages/ http://repos.fedorapeople.org/repos/katello/katello/6Server/x86_64/ -- Miroslav Suchy Red Hat Satellite Engineering From thomasmckay at redhat.com Mon Jul 2 11:38:21 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 02 Jul 2012 07:38:21 -0400 (EDT) Subject: [katello-devel] where to get required katello gems In-Reply-To: <938edb4e-aa78-480c-9d17-42805a92b667@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <93a56aaf-2b37-4a3e-ba24-3e1813a9d1b5@zmail16.collab.prod.int.phx2.redhat.com> It used to be that when setting up a development environment, the Gemfile could simply point to http://repos.fedorapeople.org/repos/katello/gems/ but this is no longer the case. Is there a process for reviving this nicety or is there a reason it is no longer meant to be used? From ehelms at redhat.com Mon Jul 2 12:19:33 2012 From: ehelms at redhat.com (Eric Helms) Date: Mon, 02 Jul 2012 08:19:33 -0400 (EDT) Subject: [katello-devel] where to get required katello gems In-Reply-To: <93a56aaf-2b37-4a3e-ba24-3e1813a9d1b5@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> That repository is meant to contain any gems that are required for development or production that are not already in Fedora. Which reduces the amount of third-party package building we have to do and allows us to rely on the underlying OS more I believe. That is also why the development docs call for you to install Katello via RPM, even in a development setup. - Eric ----- Original Message ----- From: "Tom McKay" To: katello-devel at redhat.com Sent: Monday, July 2, 2012 7:38:21 AM Subject: [katello-devel] where to get required katello gems It used to be that when setting up a development environment, the Gemfile could simply point to http://repos.fedorapeople.org/repos/katello/gems/ but this is no longer the case. Is there a process for reviving this nicety or is there a reason it is no longer meant to be used? _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From thomasmckay at redhat.com Mon Jul 2 12:28:16 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 02 Jul 2012 08:28:16 -0400 (EDT) Subject: [katello-devel] maintaining tab when selecting items in left list In-Reply-To: <0f29cd86-3b4a-4f7c-96bb-bbe725b3d64b@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <6cc0ee41-a4fa-461f-a3e8-9eb8eacbd8e2@zmail16.collab.prod.int.phx2.redhat.com> Had some time this weekend so I picked a feature off my personal wish list to implement. https://github.com/Katello/katello/pull/271 It simply maintains the currently open tab (in the BBQ, the stuff after the # in the url) so that when selecting another item in the left list, that same tab remains open. This makes it moderately more user friendly when browsing through items in the left. From lzap at redhat.com Mon Jul 2 12:42:01 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 2 Jul 2012 14:42:01 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> References: <93a56aaf-2b37-4a3e-ba24-3e1813a9d1b5@zmail16.collab.prod.int.phx2.redhat.com> <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <20120702124201.GF3743@lzapx.brq.redhat.com> Exactly, I will add that Bundler itself with its Gemfile.lock should be able to "lock" versions for us, but guys were seeing some issues in regard to updating, so this is also the reason for our own repo. In future, we would like to build both Fedora and RHEL repositories from Koji and start extracting those gems from RPMs inself - that would give us three gem repos (for Fedoras and for RHEL). So devs should be able to switch over from Fedora environment to RHEL easily. LZ On Mon, Jul 02, 2012 at 08:19:33AM -0400, Eric Helms wrote: > That repository is meant to contain any gems that are required for development or production that are not already in Fedora. Which reduces the amount of third-party package building we have to do and allows us to rely on the underlying OS more I believe. That is also why the development docs call for you to install Katello via RPM, even in a development setup. > > - Eric > > ----- Original Message ----- > From: "Tom McKay" > To: katello-devel at redhat.com > Sent: Monday, July 2, 2012 7:38:21 AM > Subject: [katello-devel] where to get required katello gems > > It used to be that when setting up a development environment, the Gemfile could simply point to > http://repos.fedorapeople.org/repos/katello/gems/ > but this is no longer the case. Is there a process for reviving this nicety or is there a reason it is no longer meant to be used? > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Mon Jul 2 12:50:31 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 02 Jul 2012 08:50:31 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120702124201.GF3743@lzapx.brq.redhat.com> References: <93a56aaf-2b37-4a3e-ba24-3e1813a9d1b5@zmail16.collab.prod.int.phx2.redhat.com> <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> <20120702124201.GF3743@lzapx.brq.redhat.com> Message-ID: <4FF19917.1000007@redhat.com> Whatever new model we go to should be coordinated with the aeolus guys. The closer we are to the same stack the better. -- bk On 07/02/2012 08:42 AM, Lukas Zapletal wrote: > Exactly, I will add that Bundler itself with its Gemfile.lock should be > able to "lock" versions for us, but guys were seeing some issues in > regard to updating, so this is also the reason for our own repo. > > In future, we would like to build both Fedora and RHEL repositories from > Koji and start extracting those gems from RPMs inself - that would give > us three gem repos (for Fedoras and for RHEL). So devs should be able to > switch over from Fedora environment to RHEL easily. > > LZ > > On Mon, Jul 02, 2012 at 08:19:33AM -0400, Eric Helms wrote: >> That repository is meant to contain any gems that are required for development or production that are not already in Fedora. Which reduces the amount of third-party package building we have to do and allows us to rely on the underlying OS more I believe. That is also why the development docs call for you to install Katello via RPM, even in a development setup. >> >> - Eric >> >> ----- Original Message ----- >> From: "Tom McKay" >> To: katello-devel at redhat.com >> Sent: Monday, July 2, 2012 7:38:21 AM >> Subject: [katello-devel] where to get required katello gems >> >> It used to be that when setting up a development environment, the Gemfile could simply point to >> http://repos.fedorapeople.org/repos/katello/gems/ >> but this is no longer the case. Is there a process for reviving this nicety or is there a reason it is no longer meant to be used? >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > From thomasmckay at redhat.com Mon Jul 2 13:33:08 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 02 Jul 2012 09:33:08 -0400 (EDT) Subject: [katello-devel] where to get required katello gems In-Reply-To: <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: It needs to be cleaned up then. It has rails-3.0.5, for example, is that right? ----- Original Message ----- > From: "Eric Helms" > To: katello-devel at redhat.com > Sent: Monday, July 2, 2012 8:19:33 AM > Subject: Re: [katello-devel] where to get required katello gems > > That repository is meant to contain any gems that are required for > development or production that are not already in Fedora. Which > reduces the amount of third-party package building we have to do and > allows us to rely on the underlying OS more I believe. That is also > why the development docs call for you to install Katello via RPM, > even in a development setup. > > - Eric > > ----- Original Message ----- > From: "Tom McKay" > To: katello-devel at redhat.com > Sent: Monday, July 2, 2012 7:38:21 AM > Subject: [katello-devel] where to get required katello gems > > It used to be that when setting up a development environment, the > Gemfile could simply point to > http://repos.fedorapeople.org/repos/katello/gems/ > but this is no longer the case. Is there a process for reviving this > nicety or is there a reason it is no longer meant to be used? > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From thomasmckay at redhat.com Mon Jul 2 13:33:57 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 02 Jul 2012 09:33:57 -0400 (EDT) Subject: [katello-devel] where to get required katello gems In-Reply-To: Message-ID: <0e54229b-b0e0-497e-ae42-ffc2ad89b26d@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Tom McKay" > To: "Eric Helms" > Cc: katello-devel at redhat.com > Sent: Monday, July 2, 2012 9:33:08 AM > Subject: Re: [katello-devel] where to get required katello gems > > It needs to be cleaned up then. It has rails-3.0.5, for example, is > that right? My mistake, it has 3.0.10 as well. > > ----- Original Message ----- > > From: "Eric Helms" > > To: katello-devel at redhat.com > > Sent: Monday, July 2, 2012 8:19:33 AM > > Subject: Re: [katello-devel] where to get required katello gems > > > > That repository is meant to contain any gems that are required for > > development or production that are not already in Fedora. Which > > reduces the amount of third-party package building we have to do > > and > > allows us to rely on the underlying OS more I believe. That is > > also > > why the development docs call for you to install Katello via RPM, > > even in a development setup. > > > > - Eric > > > > ----- Original Message ----- > > From: "Tom McKay" > > To: katello-devel at redhat.com > > Sent: Monday, July 2, 2012 7:38:21 AM > > Subject: [katello-devel] where to get required katello gems > > > > It used to be that when setting up a development environment, the > > Gemfile could simply point to > > http://repos.fedorapeople.org/repos/katello/gems/ > > but this is no longer the case. Is there a process for reviving > > this > > nicety or is there a reason it is no longer meant to be used? > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > From mrao at redhat.com Mon Jul 2 14:03:05 2012 From: mrao at redhat.com (Malini Rao) Date: Mon, 02 Jul 2012 10:03:05 -0400 (EDT) Subject: [katello-devel] maintaining tab when selecting items in left list In-Reply-To: <6cc0ee41-a4fa-461f-a3e8-9eb8eacbd8e2@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <87f1b060-70d5-453d-a13e-998ecdf3a928@zmail12.collab.prod.int.phx2.redhat.com> Woohoo! Nice one. -Malini ----- Original Message ----- From: "Tom McKay" To: katello-devel at redhat.com Sent: Monday, July 2, 2012 8:28:16 AM Subject: [katello-devel] maintaining tab when selecting items in left list Had some time this weekend so I picked a feature off my personal wish list to implement. https://github.com/Katello/katello/pull/271 It simply maintains the currently open tab (in the BBQ, the stuff after the # in the url) so that when selecting another item in the left list, that same tab remains open. This makes it moderately more user friendly when browsing through items in the left. _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From thomasmckay at redhat.com Mon Jul 2 15:17:56 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 02 Jul 2012 11:17:56 -0400 (EDT) Subject: [katello-devel] new help tip for enable Red Hat repositories In-Reply-To: <694c9281-67af-4143-a0bd-db99cd3a03b6@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <56dbf69e-068d-446b-b204-b5511460e09f@zmail16.collab.prod.int.phx2.redhat.com> I need a help tip for the "Enable Red Hat Repositories" view. Can someone suggest a couple sentences describing the what&why? From jrist at redhat.com Mon Jul 2 15:21:28 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 02 Jul 2012 09:21:28 -0600 Subject: [katello-devel] new help tip for enable Red Hat repositories In-Reply-To: <56dbf69e-068d-446b-b204-b5511460e09f@zmail16.collab.prod.int.phx2.redhat.com> References: <694c9281-67af-4143-a0bd-db99cd3a03b6@zmail16.collab.prod.int.phx2.redhat.com> <56dbf69e-068d-446b-b204-b5511460e09f@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4FF1BC78.4000906@redhat.com> On Mon 02 Jul 2012 09:17:56 AM MDT, Tom McKay wrote: > I need a help tip for the "Enable Red Hat Repositories" view. Can someone suggest a couple sentences describing the what&why? > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel How about: "In order to use a particular repository, it must be enabled. Please select the check boxes below for the applicable repositories that you wish to enable for your usage." -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bkearney at redhat.com Mon Jul 2 15:24:15 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 02 Jul 2012 11:24:15 -0400 Subject: [katello-devel] new help tip for enable Red Hat repositories In-Reply-To: <4FF1BC78.4000906@redhat.com> References: <694c9281-67af-4143-a0bd-db99cd3a03b6@zmail16.collab.prod.int.phx2.redhat.com> <56dbf69e-068d-446b-b204-b5511460e09f@zmail16.collab.prod.int.phx2.redhat.com> <4FF1BC78.4000906@redhat.com> Message-ID: <4FF1BD1F.2060700@redhat.com> On 07/02/2012 11:21 AM, Jason Rist wrote: > On Mon 02 Jul 2012 09:17:56 AM MDT, Tom McKay wrote: >> I need a help tip for the "Enable Red Hat Repositories" view. Can >> someone suggest a couple sentences describing the what&why? >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > How about: > "In order to use a particular repository, it must be enabled. Please > select the check boxes below for the applicable repositories that you > wish to enable for your usage." > The goal is to not sync down content you will never use. so, the repos will show those software sources you "can" syncrhnize, but only by enabling will you sync them. -- bk From thomasmckay at redhat.com Mon Jul 2 15:57:37 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 02 Jul 2012 11:57:37 -0400 (EDT) Subject: [katello-devel] new help tip for enable Red Hat repositories In-Reply-To: <4FF1BD1F.2060700@redhat.com> Message-ID: <749e99b4-9eb2-49f2-bd9b-d854107617fe@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Bryan Kearney" > To: katello-devel at redhat.com > Sent: Monday, July 2, 2012 11:24:15 AM > Subject: Re: [katello-devel] new help tip for enable Red Hat repositories > > On 07/02/2012 11:21 AM, Jason Rist wrote: > > On Mon 02 Jul 2012 09:17:56 AM MDT, Tom McKay wrote: > >> I need a help tip for the "Enable Red Hat Repositories" view. Can > >> someone suggest a couple sentences describing the what&why? > >> > >> _______________________________________________ > >> katello-devel mailing list > >> katello-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/katello-devel > > > > How about: > > "In order to use a particular repository, it must be enabled. > > Please > > select the check boxes below for the applicable repositories that > > you > > wish to enable for your usage." > > > The goal is to not sync down content you will never use. so, the > repos > will show those software sources you "can" syncrhnize, but only by > enabling will you sync them. How's this? Expand each Red Hat product below to see the available repositories in each. Selecting the checkbox will make that repository's content available for synchronizing. From bkearney at redhat.com Mon Jul 2 16:11:37 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 02 Jul 2012 12:11:37 -0400 Subject: [katello-devel] new help tip for enable Red Hat repositories In-Reply-To: <749e99b4-9eb2-49f2-bd9b-d854107617fe@zmail16.collab.prod.int.phx2.redhat.com> References: <749e99b4-9eb2-49f2-bd9b-d854107617fe@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4FF1C839.5060803@redhat.com> On 07/02/2012 11:57 AM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Bryan Kearney" >> To: katello-devel at redhat.com >> Sent: Monday, July 2, 2012 11:24:15 AM >> Subject: Re: [katello-devel] new help tip for enable Red Hat repositories >> >> On 07/02/2012 11:21 AM, Jason Rist wrote: >>> On Mon 02 Jul 2012 09:17:56 AM MDT, Tom McKay wrote: >>>> I need a help tip for the "Enable Red Hat Repositories" view. Can >>>> someone suggest a couple sentences describing the what&why? >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >>> How about: >>> "In order to use a particular repository, it must be enabled. >>> Please >>> select the check boxes below for the applicable repositories that >>> you >>> wish to enable for your usage." >>> >> The goal is to not sync down content you will never use. so, the >> repos >> will show those software sources you "can" syncrhnize, but only by >> enabling will you sync them. > > How's this? > > Expand each Red Hat product below to see the available repositories in each. Selecting the checkbox will make that repository's content available for synchronizing. > Is it red hat only? -- bk From thomasmckay at redhat.com Mon Jul 2 16:13:38 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 02 Jul 2012 12:13:38 -0400 (EDT) Subject: [katello-devel] new help tip for enable Red Hat repositories In-Reply-To: <4FF1C839.5060803@redhat.com> Message-ID: ----- Original Message ----- > From: "Bryan Kearney" > To: "Tom McKay" > Cc: katello-devel at redhat.com > Sent: Monday, July 2, 2012 12:11:37 PM > Subject: Re: [katello-devel] new help tip for enable Red Hat repositories > > On 07/02/2012 11:57 AM, Tom McKay wrote: > > > > > > ----- Original Message ----- > >> From: "Bryan Kearney" > >> To: katello-devel at redhat.com > >> Sent: Monday, July 2, 2012 11:24:15 AM > >> Subject: Re: [katello-devel] new help tip for enable Red Hat > >> repositories > >> > >> On 07/02/2012 11:21 AM, Jason Rist wrote: > >>> On Mon 02 Jul 2012 09:17:56 AM MDT, Tom McKay wrote: > >>>> I need a help tip for the "Enable Red Hat Repositories" view. > >>>> Can > >>>> someone suggest a couple sentences describing the what&why? > >>>> > >>>> _______________________________________________ > >>>> katello-devel mailing list > >>>> katello-devel at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/katello-devel > >>> > >>> How about: > >>> "In order to use a particular repository, it must be enabled. > >>> Please > >>> select the check boxes below for the applicable repositories that > >>> you > >>> wish to enable for your usage." > >>> > >> The goal is to not sync down content you will never use. so, the > >> repos > >> will show those software sources you "can" syncrhnize, but only by > >> enabling will you sync them. > > > > How's this? > > > > Expand each Red Hat product below to see the available repositories > > in each. Selecting the checkbox will make that repository's > > content available for synchronizing. > > > Is it red hat only? Yes. The custom content has its own area in the UI. > > -- bk > > > From jrist at redhat.com Mon Jul 2 16:17:24 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 02 Jul 2012 10:17:24 -0600 Subject: [katello-devel] new help tip for enable Red Hat repositories In-Reply-To: <749e99b4-9eb2-49f2-bd9b-d854107617fe@zmail16.collab.prod.int.phx2.redhat.com> References: <749e99b4-9eb2-49f2-bd9b-d854107617fe@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4FF1C994.4050204@redhat.com> On 07/02/2012 09:57 AM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Bryan Kearney" >> To: katello-devel at redhat.com >> Sent: Monday, July 2, 2012 11:24:15 AM >> Subject: Re: [katello-devel] new help tip for enable Red Hat repositories >> >> On 07/02/2012 11:21 AM, Jason Rist wrote: >>> On Mon 02 Jul 2012 09:17:56 AM MDT, Tom McKay wrote: >>>> I need a help tip for the "Enable Red Hat Repositories" view. Can >>>> someone suggest a couple sentences describing the what&why? >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >>> How about: >>> "In order to use a particular repository, it must be enabled. >>> Please >>> select the check boxes below for the applicable repositories that >>> you >>> wish to enable for your usage." >>> >> The goal is to not sync down content you will never use. so, the >> repos >> will show those software sources you "can" syncrhnize, but only by >> enabling will you sync them. > > How's this? > > Expand each Red Hat product below to see the available repositories in each. Selecting the checkbox will make that repository's content available for synchronizing. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Tom - I really like that latest one. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bkearney at redhat.com Mon Jul 2 16:40:56 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 02 Jul 2012 12:40:56 -0400 Subject: [katello-devel] unneccessery packages in rhel6 In-Reply-To: <4FF185DD.9000408@redhat.com> References: <4FF0FB6C.3060800@redhat.com> <20120702102138.GA3743@lzapx.brq.redhat.com> <4FF185DD.9000408@redhat.com> Message-ID: <4FF1CF18.6080409@redhat.com> On 07/02/2012 07:28 AM, Miroslav Such? wrote: > On 07/02/2012 12:21 PM, Lukas Zapletal wrote: >> Which repo, I don't see them? >> >> http://download.lab.bos.redhat.com/rel-eng/CloudForms/1.0.1/latest/el6-se/x86_64/os/Packages/ >> > > http://repos.fedorapeople.org/repos/katello/katello/6Server/x86_64/ > We have trimmed alot as prt of the packaging. My guess is this did not make itback. -- bk From bkearney at redhat.com Mon Jul 2 17:20:37 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 02 Jul 2012 13:20:37 -0400 Subject: [katello-devel] API documentation In-Reply-To: <4FF1475C.4010700@redhat.com> References: <4FEC5F37.3070806@redhat.com> <4FEED892.1080704@redhat.com> <4FF1475C.4010700@redhat.com> Message-ID: <4FF1D865.3070001@redhat.com> On 07/02/2012 03:01 AM, Ivan Ne?as wrote: > On 06/30/2012 12:44 PM, Miroslav Suchy wrote: >> On 28.6.2012 15:42, Tomas Strachota wrote: >>> Hello team, >>> our api documentation efforts are slowly moving. We've got 4 controllers >>> finished and 1 assigned but there are still 32 left untouched. We can >>> speed it up a lot if everybody takes one and looks at it. It's not >>> difficult as we have basic docs already automatically generated. You >>> only have to check the parameters and fill in some meaningful >>> descriptions. >>> >>> Those two links will show you where to start: >>> https://fedorahosted.org/katello/wiki/ApiDocHowto >>> https://fedorahosted.org/katello/wiki/APIDocumentationEfforts >> >> Can we have subpackage katello-api-doc, which will contain those >> static pages? > Definitely +1. We will need to incorporate it to our build process once > the changes are merged into master. Added to the backlog. -- bk From mrao at redhat.com Mon Jul 2 17:24:39 2012 From: mrao at redhat.com (Malini Rao) Date: Mon, 02 Jul 2012 13:24:39 -0400 (EDT) Subject: [katello-devel] new help tip for enable Red Hat repositories In-Reply-To: <4FF1C994.4050204@redhat.com> Message-ID: I second Jason from a UX/ usability perspective. The statements are crisp and clear. But is this a tooltip text or a on screen help/ instructional text. Seems a bit long if it is for a on hover tooltip. -Malini ----- Original Message ----- From: "Jason Rist" To: katello-devel at redhat.com Sent: Monday, July 2, 2012 12:17:24 PM Subject: Re: [katello-devel] new help tip for enable Red Hat repositories On 07/02/2012 09:57 AM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Bryan Kearney" >> To: katello-devel at redhat.com >> Sent: Monday, July 2, 2012 11:24:15 AM >> Subject: Re: [katello-devel] new help tip for enable Red Hat repositories >> >> On 07/02/2012 11:21 AM, Jason Rist wrote: >>> On Mon 02 Jul 2012 09:17:56 AM MDT, Tom McKay wrote: >>>> I need a help tip for the "Enable Red Hat Repositories" view. Can >>>> someone suggest a couple sentences describing the what&why? >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >>> How about: >>> "In order to use a particular repository, it must be enabled. >>> Please >>> select the check boxes below for the applicable repositories that >>> you >>> wish to enable for your usage." >>> >> The goal is to not sync down content you will never use. so, the >> repos >> will show those software sources you "can" syncrhnize, but only by >> enabling will you sync them. > > How's this? > > Expand each Red Hat product below to see the available repositories in each. Selecting the checkbox will make that repository's content available for synchronizing. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Tom - I really like that latest one. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Mon Jul 2 18:24:10 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 02 Jul 2012 11:24:10 -0700 Subject: [katello-devel] new help tip for enable Red Hat repositories In-Reply-To: <749e99b4-9eb2-49f2-bd9b-d854107617fe@zmail16.collab.prod.int.phx2.redhat.com> References: <749e99b4-9eb2-49f2-bd9b-d854107617fe@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4FF1E74A.7050108@redhat.com> On 07/02/2012 08:57 AM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Bryan Kearney" >> To: katello-devel at redhat.com >> Sent: Monday, July 2, 2012 11:24:15 AM >> Subject: Re: [katello-devel] new help tip for enable Red Hat repositories >> >> On 07/02/2012 11:21 AM, Jason Rist wrote: >>> On Mon 02 Jul 2012 09:17:56 AM MDT, Tom McKay wrote: >>>> I need a help tip for the "Enable Red Hat Repositories" view. Can >>>> someone suggest a couple sentences describing the what&why? >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >>> How about: >>> "In order to use a particular repository, it must be enabled. >>> Please >>> select the check boxes below for the applicable repositories that >>> you >>> wish to enable for your usage." >>> >> The goal is to not sync down content you will never use. so, the >> repos >> will show those software sources you "can" syncrhnize, but only by >> enabling will you sync them. > > How's this? > > Expand each Red Hat product below to see the available repositories in each. Selecting the checkbox will make that repository's content available for synchronizing. > +1 From jrist at redhat.com Mon Jul 2 20:39:22 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 02 Jul 2012 14:39:22 -0600 Subject: [katello-devel] Org Switcher Issues Message-ID: <4FF206FA.7000801@redhat.com> Still working out some oddities on Org Switcher. Appears that the hash is off from what should be in there ( b74d799cfcdf53f608005528119b149dfee72749 vs. fedf3e8f631bce9a0fbfced8fbc9363789f8ca08 ) -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From msuchy at redhat.com Tue Jul 3 12:49:19 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Tue, 03 Jul 2012 14:49:19 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120702124201.GF3743@lzapx.brq.redhat.com> References: <93a56aaf-2b37-4a3e-ba24-3e1813a9d1b5@zmail16.collab.prod.int.phx2.redhat.com> <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> <20120702124201.GF3743@lzapx.brq.redhat.com> Message-ID: <4FF2EA4F.6050509@redhat.com> On 07/02/2012 02:42 PM, Lukas Zapletal wrote: > Exactly, I will add that Bundler itself with its Gemfile.lock should be > able to "lock" versions for us, but guys were seeing some issues in > regard to updating, so this is also the reason for our own repo. > > In future, we would like to build both Fedora and RHEL repositories from > Koji and start extracting those gems from RPMs inself - that would give > us three gem repos (for Fedoras and for RHEL). So devs should be able to > switch over from Fedora environment to RHEL easily. I would suggest - If you need gem, which is not in Fedora, do not download pure gem file, but put it in kalpana-gems. Create spec file for that (this will make Review Request in Fedora later easier) and build it in Koji using HOWTO I sent today. I can even create yum repository with developers gem then. And if some of them appear in Fedora/RHEL you do not need to change anything and the transition will be flawless. You can even create meta-package "developer-setup", which will require all developers gem. So if you introduce new gem, everybody will get it during their "yum upgrade" and you even do not have to announce it. -- Miroslav Suchy Red Hat Satellite Engineering From lzap at redhat.com Tue Jul 3 14:32:27 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 3 Jul 2012 16:32:27 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <4FF2EA4F.6050509@redhat.com> References: <93a56aaf-2b37-4a3e-ba24-3e1813a9d1b5@zmail16.collab.prod.int.phx2.redhat.com> <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> <20120702124201.GF3743@lzapx.brq.redhat.com> <4FF2EA4F.6050509@redhat.com> Message-ID: <20120703143227.GG5554@lzapx.brq.redhat.com> On Tue, Jul 03, 2012 at 02:49:19PM +0200, Miroslav Suchy wrote: > On 07/02/2012 02:42 PM, Lukas Zapletal wrote: > >Exactly, I will add that Bundler itself with its Gemfile.lock should be > >able to "lock" versions for us, but guys were seeing some issues in > >regard to updating, so this is also the reason for our own repo. > > > >In future, we would like to build both Fedora and RHEL repositories from > >Koji and start extracting those gems from RPMs inself - that would give > >us three gem repos (for Fedoras and for RHEL). So devs should be able to > >switch over from Fedora environment to RHEL easily. > > I would suggest - If you need gem, which is not in Fedora, do not > download pure gem file, but put it in kalpana-gems. Create spec file > for that (this will make Review Request in Fedora later easier) and > build it in Koji using HOWTO I sent today. > I can even create yum repository with developers gem then. > And if some of them appear in Fedora/RHEL you do not need to change > anything and the transition will be flawless. > You can even create meta-package "developer-setup", which will > require all developers gem. So if you introduce new gem, everybody > will get it during their "yum upgrade" and you even do not have to > announce it. > Sounds like a plan, but that is extra work. But we could do it, would be much nicer for sure. -- Later, Lukas "lzap" Zapletal #katello #systemengine From thomasmckay at redhat.com Tue Jul 3 19:44:03 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 03 Jul 2012 15:44:03 -0400 (EDT) Subject: [katello-devel] async manifest import In-Reply-To: Message-ID: <5fba0f8a-f735-4931-bc6f-83e119e77cdb@zmail16.collab.prod.int.phx2.redhat.com> Several questions have come up during my work of integrating the async manifest import into the two-pane subscriptions. I don't think import can be considered complete before they are answered: First, there is a disconnect between when the import finishes and when the notices popup indicating success/failure. It may be beneficial to move the notice code from the async thread up into katello proper, allowing the UI to show the notice on its own query schedule. Second, and more importantly, there are probably many pages that should have their functionality limited or disabled while a manifest is being imported: Should any subscriptions be shown? Should a subscription be allowed to be applied to a system or activation key? What about repository enabling? There are good reasons we've made the manifest import async, but there are many reasons to lock down the interface while it is going on. From thomasmckay at redhat.com Tue Jul 3 19:56:36 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 03 Jul 2012 15:56:36 -0400 (EDT) Subject: [katello-devel] async manifest import In-Reply-To: <5fba0f8a-f735-4931-bc6f-83e119e77cdb@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <63dce5c9-7292-4276-a686-0997c3c16cba@zmail16.collab.prod.int.phx2.redhat.com> As a by-product of this, the "two-pane subscriptions" feature will not be checked in until the issues with the task status properly updating are resolved. ----- Original Message ----- > From: "Tom McKay" > To: katello-devel at redhat.com > Sent: Tuesday, July 3, 2012 3:44:03 PM > Subject: [katello-devel] async manifest import > > > Several questions have come up during my work of integrating the > async manifest import into the two-pane subscriptions. I don't think > import can be considered complete before they are answered: > > First, there is a disconnect between when the import finishes and > when the notices popup indicating success/failure. It may be > beneficial to move the notice code from the async thread up into > katello proper, allowing the UI to show the notice on its own query > schedule. > > Second, and more importantly, there are probably many pages that > should have their functionality limited or disabled while a manifest > is being imported: Should any subscriptions be shown? Should a > subscription be allowed to be applied to a system or activation key? > What about repository enabling? > > There are good reasons we've made the manifest import async, but > there are many reasons to lock down the interface while it is going > on. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Wed Jul 4 07:24:13 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 4 Jul 2012 09:24:13 +0200 Subject: [katello-devel] async manifest import In-Reply-To: <5fba0f8a-f735-4931-bc6f-83e119e77cdb@zmail16.collab.prod.int.phx2.redhat.com> References: <5fba0f8a-f735-4931-bc6f-83e119e77cdb@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <20120704072412.GA3428@lzapx.brq.redhat.com> Those are really good questions, but I would not them consider blockers. At least not the second point, which I think is appropriate. I was also thinking about async import - what happens if user will continue using Katello. But he already can! I mean, when any web app hangs showing me a spinner or something, I usually open another tab with it doing something else. And Katello user can do this too with old (sync) import. Before locking anything, I would rather ask - what happens if we don't lock it and user does something? Did you try it? We definitely need to do some manual testing scenarios in regard the new import trying to: - mangle with repos - start syncing - registering and subscribing content - editing manifests being imported - ??? Once we find what the issues are, let's talk about how to fix them ;-) LZ On Tue, Jul 03, 2012 at 03:44:03PM -0400, Tom McKay wrote: > > Several questions have come up during my work of integrating the async manifest import into the two-pane subscriptions. I don't think import can be considered complete before they are answered: > > First, there is a disconnect between when the import finishes and when the notices popup indicating success/failure. It may be beneficial to move the notice code from the async thread up into katello proper, allowing the UI to show the notice on its own query schedule. > > Second, and more importantly, there are probably many pages that should have their functionality limited or disabled while a manifest is being imported: Should any subscriptions be shown? Should a subscription be allowed to be applied to a system or activation key? What about repository enabling? > > There are good reasons we've made the manifest import async, but there are many reasons to lock down the interface while it is going on. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From thomasmckay at redhat.com Thu Jul 5 11:57:56 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 05 Jul 2012 07:57:56 -0400 (EDT) Subject: [katello-devel] async manifest import In-Reply-To: <20120704072412.GA3428@lzapx.brq.redhat.com> Message-ID: ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, July 4, 2012 3:24:13 AM > Subject: Re: [katello-devel] async manifest import > > Those are really good questions, but I would not them consider > blockers. > At least not the second point, which I think is appropriate. > I was also thinking about async import - what happens if user will > continue using Katello. But he already can! I mean, when any web app > hangs showing me a spinner or something, I usually open another tab > with > it doing something else. And Katello user can do this too with old > (sync) import. > > Before locking anything, I would rather ask - what happens if we > don't > lock it and user does something? Did you try it? When I say lock, I don't mean the entire page but perhaps the checkbox to enable repos is disabled. Have I tried it? No. Perhaps Petr has as the implementer of the feature. > > We definitely need to do some manual testing scenarios in regard the > new > import trying to: > > - mangle with repos > - start syncing > - registering and subscribing content > - editing manifests being imported > - ??? > > Once we find what the issues are, let's talk about how to fix them > ;-) > > LZ > > On Tue, Jul 03, 2012 at 03:44:03PM -0400, Tom McKay wrote: > > > > Several questions have come up during my work of integrating the > > async manifest import into the two-pane subscriptions. I don't > > think import can be considered complete before they are answered: > > > > First, there is a disconnect between when the import finishes and > > when the notices popup indicating success/failure. It may be > > beneficial to move the notice code from the async thread up into > > katello proper, allowing the UI to show the notice on its own > > query schedule. > > > > Second, and more importantly, there are probably many pages that > > should have their functionality limited or disabled while a > > manifest is being imported: Should any subscriptions be shown? > > Should a subscription be allowed to be applied to a system or > > activation key? What about repository enabling? > > > > There are good reasons we've made the manifest import async, but > > there are many reasons to lock down the interface while it is > > going on. > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From ehelms at redhat.com Thu Jul 5 15:38:49 2012 From: ehelms at redhat.com (Eric Helms) Date: Thu, 05 Jul 2012 11:38:49 -0400 Subject: [katello-devel] JSHint for Developers Message-ID: <4FF5B509.8010202@redhat.com> Howdy, As of https://github.com/Katello/katello/pull/276, the JSHintRB gem with an associated rake task is now available for developers to use as means of doing syntax and code analysis against our Javascript. JSHintrb wraps JSHint functionality, which is itself built upon Douglas Crockford's JSLint, to make incorporation into Ruby projects and creation of a rake task easier. More information and available options can be found here: http://www.jshint.com/options/ The set of options we are currently using be found here: https://github.com/Katello/katello/commit/a0196471cefa99059fb53b25e42cbbb64382194d#src/lib/tasks/jshint.rake The task can be run via: 'rake jshint' And at this time, no clean-up of code has been done so there will be lots of output. Future pull requests will follow focused on applying the tool and cleaning up our code. - Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmckay at redhat.com Thu Jul 5 17:07:17 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 05 Jul 2012 13:07:17 -0400 (EDT) Subject: [katello-devel] async manifest import In-Reply-To: <63dce5c9-7292-4276-a686-0997c3c16cba@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: ----- Original Message ----- > From: "Tom McKay" > To: katello-devel at redhat.com > Sent: Tuesday, July 3, 2012 3:56:36 PM > Subject: Re: [katello-devel] async manifest import > > As a by-product of this, the "two-pane subscriptions" feature will > not be checked in until the issues with the task status properly > updating are resolved. The subs-tupane branch was just merged with master. The async manifest import is working now; if you experience any "inifinite spinner" problems please let me know. > > ----- Original Message ----- > > From: "Tom McKay" > > To: katello-devel at redhat.com > > Sent: Tuesday, July 3, 2012 3:44:03 PM > > Subject: [katello-devel] async manifest import > > > > > > Several questions have come up during my work of integrating the > > async manifest import into the two-pane subscriptions. I don't > > think > > import can be considered complete before they are answered: > > > > First, there is a disconnect between when the import finishes and > > when the notices popup indicating success/failure. It may be > > beneficial to move the notice code from the async thread up into > > katello proper, allowing the UI to show the notice on its own query > > schedule. > > > > Second, and more importantly, there are probably many pages that > > should have their functionality limited or disabled while a > > manifest > > is being imported: Should any subscriptions be shown? Should a > > subscription be allowed to be applied to a system or activation > > key? > > What about repository enabling? > > > > There are good reasons we've made the manifest import async, but > > there are many reasons to lock down the interface while it is going > > on. > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > From thomasmckay at redhat.com Fri Jul 6 15:00:40 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 06 Jul 2012 11:00:40 -0400 (EDT) Subject: [katello-devel] available release versions In-Reply-To: <4d5bb2fb-9102-4728-a595-adee7d20f662@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=834012 Both headpin and subscription-manager-gui reach out to the CDN to get a list of available release versions (5.8, 6.2, etc.). Katello, however, bases the available release versions on the subset that have repos enabled. With that in mind, I think the BZ above is working as intended, ie. release versions shown in subscription-manager-gui have nothing to do with what katello has available. I think there have been BZs/RFEs that systems should not be able to set a release version when registered to katello to a version where no repos (and hence no content) are available. Someone with more knowledge of the feature and intricacies please chime in. From bkearney at redhat.com Sat Jul 7 18:23:37 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Sat, 07 Jul 2012 14:23:37 -0400 Subject: [katello-devel] Fwd: Error message in Katello In-Reply-To: <4FF6FF3D.4040108@redhat.com> References: <4FF6FF3D.4040108@redhat.com> Message-ID: <4FF87EA9.4010100@redhat.com> If you can please respond to the list. Thank you. -- bk -------- Original Message -------- Subject: Error message in Katello Date: Fri, 06 Jul 2012 11:07:41 -0400 From: Jason Ganovsky To: cf-tech at redhat.com Ok, I had a system registered in Katello and after the VM was deleted I went back and deleted it. Now every time I go to Systems I get the error message attached....anyone have any idea what this is and how to fix it? -- Jason Ganovsky Solutions Architect jganovsk at redhat.com 610-509-3724 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot at 2012-07-06 11:05:18.png Type: image/png Size: 115013 bytes Desc: not available URL: From bkearney at redhat.com Mon Jul 9 08:01:19 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 09 Jul 2012 04:01:19 -0400 Subject: [katello-devel] On the plane, I tried 2 controllers worth of API changes Message-ID: <4FFA8FCF.5040203@redhat.com> someone should really check the pull request i sent in, since I was not able to really test. Here were some notes I took while playing with the code: changesets_content_controller ============================= * entire api controller returns text instead of json. * passing in a non existent product id still gets you a 200 return code. (look at render_after_removal) * Looks like the posts take in query parameters instead of JSON in the body. Any reason for that? * For remove_* is seems nasty to have to pass in the product id. Dont we just know this since it is in the changeset already? * For URLS like this: api :DELETE, "/changesets/:changeset_id/templates/:id", " why use :changeset_id and then :id (as opposed to template_id" Changeset_controller ==================== * Update and create seems to do json, which is good * is organization_id ever checked? * Why is name used in #index * Promote seems icky. We are POSTING to /promote which is more of an RPC call. Can we do a POST to another environment instead? * The promotion API automatically moves the changeset to REVIEW. Should we instead make that a unique call? From bkearney at redhat.com Mon Jul 9 10:40:08 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 09 Jul 2012 06:40:08 -0400 Subject: [katello-devel] available release versions In-Reply-To: References: Message-ID: <4FFAB508.90609@redhat.com> On 07/06/2012 11:00 AM, Tom McKay wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=834012 > > Both headpin and subscription-manager-gui reach out to the CDN to get a list of available release versions (5.8, 6.2, etc.). Katello, however, bases the available release versions on the subset that have repos enabled. > > With that in mind, I think the BZ above is working as intended, ie. release versions shown in subscription-manager-gui have nothing to do with what katello has available. > > I think there have been BZs/RFEs that systems should not be able to set a release version when registered to katello to a version where no repos (and hence no content) are available. > > Someone with more knowledge of the feature and intricacies please chime in. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > Where does subscription manager reach out to? It would be great if it looked into the directories which are published by katello. -- bk From tkolhar at redhat.com Mon Jul 9 12:17:56 2012 From: tkolhar at redhat.com (Tazim Kolhar) Date: Mon, 09 Jul 2012 08:17:56 -0400 (EDT) Subject: [katello-devel] SAM test headpin version installation issues In-Reply-To: <3ae1bb77-e5e8-4e18-b26f-b0b0c0b1450f@zmail18.collab.prod.int.phx2.redhat.com> Message-ID: <5e07cd8d-be22-4150-ae10-06f4d4cf1f3f@zmail18.collab.prod.int.phx2.redhat.com> Hi, I am trying to setup sam test headpin version on fedora 16 but facing below errors : Error: Package: katello-headpin-all-0.2.20-1.git.0.540a4b4.fc16.noarch (SAM) Requires: candlepin-tomcat6 Error: Package: katello-headpin-all-0.2.20-1.git.0.540a4b4.fc16.noarch (SAM) Requires: thumbslug the repo file contents : [SAM] name = Red Hat Subscription Asset Manager (for Fedora 16 Server) baseurl=ftp://morbo.usersys.redhat.com/pub/repos.fedorapeople.org/testing/fedora-16/x86_64/ enabled=1 gpgcheck=0 skip_if_unavailable=1 Thanks & Regards, Tazim. From esammons at redhat.com Mon Jul 9 13:43:00 2012 From: esammons at redhat.com (Eric Sammons) Date: Mon, 09 Jul 2012 09:43:00 -0400 (EDT) Subject: [katello-devel] SAM test headpin version installation issues Message-ID: An HTML attachment was scrubbed... URL: From jbowes at redhat.com Mon Jul 9 14:56:38 2012 From: jbowes at redhat.com (James Bowes) Date: Mon, 9 Jul 2012 11:56:38 -0300 Subject: [katello-devel] available release versions In-Reply-To: <4FFAB508.90609@redhat.com> References: <4FFAB508.90609@redhat.com> Message-ID: <20120709145637.GC60192@pipboy.redhat.com> On Mon, Jul 09, 2012 at 06:40:08AM -0400, Bryan Kearney wrote: > On 07/06/2012 11:00 AM, Tom McKay wrote: > >https://bugzilla.redhat.com/show_bug.cgi?id=834012 > > > >Both headpin and subscription-manager-gui reach out to the CDN to get a list of available release versions (5.8, 6.2, etc.). Katello, however, bases the available release versions on the subset that have repos enabled. > > > >With that in mind, I think the BZ above is working as intended, ie. release versions shown in subscription-manager-gui have nothing to do with what katello has available. > > > >I think there have been BZs/RFEs that systems should not be able to set a release version when registered to katello to a version where no repos (and hence no content) are available. > > > >Someone with more knowledge of the feature and intricacies please chime in. > > > >_______________________________________________ > >katello-devel mailing list > >katello-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/katello-devel > > > Where does subscription manager reach out to? It would be great if > it looked into the directories which are published by katello. > Here is roughly what subman does: - for all installed products on a system, iterate over the products: - if a product has the product tag 'rhel-N' consider it to be a base OS product. - take the last found base os product - if no base os products found, set available releases to an empty list. - with the last found base os product, find all entitlements that grant access to that product - create an empty list, listings - for each entitlement, do: - for each _enabled_ content set on the entitlement, do: - compare the product tag to the content set's required tag, ie (rhel-6 matches rhel-6 but not rhel-5). If the tags do not match, continue to the next content set. - take the content set's url, and split it on $releasever. Take the section before the split, and append '/listing' to it. This is the location on the CDN where we expect to find a listing file for this OS. add this file location to the listings list. - for each entry in listings, download the file from the cdn. - create a set containing all entries from all listings files. - done! As far as I can tell, SAM does: - for each content set, grab its listing file, if available. return a set of the results. Katello/CFSE does: - for each enabled content set in a system's environment, get the content set's applicable releases. return a set of the results. I assume the CFSE results come from pulp, but let's also assume that they'll be identical to whatever the CDN would have. Therefore, the difference between CFSE and SAM is that katello only examines the content sets that are enabled in a given environment. This makes sense, as any content not enabled is totally inaccessible for all consumers in that environment. SAM doesn't have environments, so the difference is moot. Between katello and subman, katello's results should be a superset of what subman sees. Subman removes the following content sets: - content sets that don't map to an installed product on the system (makes sense, imo) - content sets that don't map to an entitled product on the system (makes sense for subman. could probably be a toggle for katello, defaulting to only showing entitled ones, or showing all if the system doesn't have any entitlements) - content sets that are not enabled on the client (i dunno if katello has access to this, but i think this could fall in with the above logic) - content sets that don't map to a product tagged with rhel-N (this is probably a bit broken. we should maybe be looking for a product tagged with baseOS or something? but its more of an optimization; other content sets won't have listing files. safe to ignore for katello). - content sets that aren't tagged with the same rhel version as the installed product (this makes sense to do in katello if possible, and again, probably as a toggle. you likely don't want to put your system on 6Server if it has 4AS installed). Phew! That was a lot of stuff. So, back to the original referenced bug. If the cli can use releaseVer against that SAM instance, but the gui can't, that totally sounds like a bug! The logic in both cli and gui should be the same, so we should rectify that, then if that makes the gui work, good. if not, there might be a bug in SAM. -James -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thomasmckay at redhat.com Mon Jul 9 20:17:32 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 09 Jul 2012 16:17:32 -0400 (EDT) Subject: [katello-devel] UX project: redesign of permissions interface In-Reply-To: <4691d02e-5a64-49ca-b37c-2cc8cbf1e6c2@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <7d89ec73-43b1-4777-b098-378b99cd2f98@zmail16.collab.prod.int.phx2.redhat.com> Although the current permissions interface for adding to a role is well crafted, I continually find that it is very difficult to use for my primary two use cases: Seeing what permissions a role has, and setting up the permissions for a new role. Yes, these are probably the two most primary use cases. :) I keep wishing for some sort of spreadsheet or table view where, at a glance, I can both see and modify the permissions with checkbox toggles. Maybe it's not a single table, but multiple small tables. I'm sure some UX magic can be applied to this notion. Would it be possible to get some thoughts on this? From mrao at redhat.com Mon Jul 9 20:33:57 2012 From: mrao at redhat.com (Malini Rao) Date: Mon, 09 Jul 2012 16:33:57 -0400 (EDT) Subject: [katello-devel] UX project: redesign of permissions interface In-Reply-To: <7d89ec73-43b1-4777-b098-378b99cd2f98@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <261b61ac-df97-4fcd-951b-eff7b0de129c@zmail12.collab.prod.int.phx2.redhat.com> Tom, I haven't explored how the Roles UI works in Katello but I worked on some designs for a similar usecase on Aeolus/ Conductor. See attached. This was an initial idea that was well-liked but not sure if it was finally scoped in or not ( This was a long time ago). But I think it definitely points at one of the use cases that you are talking about in some form. We can come up with some proposals if it is something that is a candidate for one of the upcoming sprints. Thanks Malini ----- Original Message ----- From: "Tom McKay" To: "Malini Rao" , "Kyle Baker" Cc: katello-devel at redhat.com Sent: Monday, July 9, 2012 4:17:32 PM Subject: UX project: redesign of permissions interface Although the current permissions interface for adding to a role is well crafted, I continually find that it is very difficult to use for my primary two use cases: Seeing what permissions a role has, and setting up the permissions for a new role. Yes, these are probably the two most primary use cases. :) I keep wishing for some sort of spreadsheet or table view where, at a glance, I can both see and modify the permissions with checkbox toggles. Maybe it's not a single table, but multiple small tables. I'm sure some UX magic can be applied to this notion. Would it be possible to get some thoughts on this? -------------- next part -------------- A non-text attachment was scrubbed... Name: Permissions details on demand.gif Type: image/gif Size: 74373 bytes Desc: not available URL: From bkearney at redhat.com Tue Jul 10 07:53:00 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 10 Jul 2012 03:53:00 -0400 Subject: [katello-devel] UX project: redesign of permissions interface In-Reply-To: <261b61ac-df97-4fcd-951b-eff7b0de129c@zmail12.collab.prod.int.phx2.redhat.com> References: <261b61ac-df97-4fcd-951b-eff7b0de129c@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <4FFBDF5C.7070601@redhat.com> On 07/09/2012 04:33 PM, Malini Rao wrote: > Tom, > > I haven't explored how the Roles UI works in Katello but I worked on some designs for a similar usecase on Aeolus/ Conductor. See attached. This was an initial idea that was well-liked but not sure if it was finally scoped in or not ( This was a long time ago). But I think it definitely points at one of the use cases that you are talking about in some form. We can come up with some proposals if it is something that is a candidate for one of the upcoming sprints. > > Thanks > Malini > That is a pretty cool view. -- bk From thomasmckay at redhat.com Tue Jul 10 11:58:48 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 10 Jul 2012 07:58:48 -0400 (EDT) Subject: [katello-devel] CRUD permissions on a user's systems In-Reply-To: <6cc38d5a-89ad-4c41-b4d8-0e700aea5406@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <5bb0cc8f-2146-4056-980c-45added23b30@zmail16.collab.prod.int.phx2.redhat.com> I'm not sure how to set permissions for a user that would give them CRUD to just their own systems (ie. ones they have registered themselves). The use case, as an example, is setting up an org with custom content and allowing users to register and manage their own systems against it without being able to alter other users' systems. I have a company laptop and want to manage its updates against the company's org. From thomasmckay at redhat.com Tue Jul 10 11:59:58 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 10 Jul 2012 07:59:58 -0400 (EDT) Subject: [katello-devel] UX project: redesign of permissions interface In-Reply-To: <261b61ac-df97-4fcd-951b-eff7b0de129c@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <932a613c-fc84-46f4-9c15-0526791d9152@zmail16.collab.prod.int.phx2.redhat.com> Yes, this is along the lines of what I had imagined. I'll sketch out some ideas during this sprint and see if I can get it added to the backlog. ----- Original Message ----- > From: "Malini Rao" > To: "Tom McKay" > Cc: katello-devel at redhat.com, "Kyle Baker" > Sent: Monday, July 9, 2012 4:33:57 PM > Subject: Re: UX project: redesign of permissions interface > > Tom, > > I haven't explored how the Roles UI works in Katello but I worked on > some designs for a similar usecase on Aeolus/ Conductor. See > attached. This was an initial idea that was well-liked but not sure > if it was finally scoped in or not ( This was a long time ago). But > I think it definitely points at one of the use cases that you are > talking about in some form. We can come up with some proposals if it > is something that is a candidate for one of the upcoming sprints. > > Thanks > Malini > > ----- Original Message ----- > From: "Tom McKay" > To: "Malini Rao" , "Kyle Baker" > Cc: katello-devel at redhat.com > Sent: Monday, July 9, 2012 4:17:32 PM > Subject: UX project: redesign of permissions interface > > > Although the current permissions interface for adding to a role is > well crafted, I continually find that it is very difficult to use > for my primary two use cases: Seeing what permissions a role has, > and setting up the permissions for a new role. Yes, these are > probably the two most primary use cases. :) > > I keep wishing for some sort of spreadsheet or table view where, at a > glance, I can both see and modify the permissions with checkbox > toggles. Maybe it's not a single table, but multiple small tables. > I'm sure some UX magic can be applied to this notion. > > Would it be possible to get some thoughts on this? > From esammons at redhat.com Tue Jul 10 12:33:44 2012 From: esammons at redhat.com (Eric Sammons) Date: Tue, 10 Jul 2012 08:33:44 -0400 (EDT) Subject: [katello-devel] UX project: redesign of permissions interface In-Reply-To: <261b61ac-df97-4fcd-951b-eff7b0de129c@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <7394033f-7449-41d1-9039-52bcf4fc24af@zmail11.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > Tom, > > I haven't explored how the Roles UI works in Katello but I worked on > some designs for a similar usecase on Aeolus/ Conductor. See > attached. This was an initial idea that was well-liked but not sure > if it was finally scoped in or not ( This was a long time ago). But > I think it definitely points at one of the use cases that you are > talking about in some form. We can come up with some proposals if it > is something that is a candidate for one of the upcoming sprints. > > Thanks > Malini > +1 This is a really slick UI. --Eric > ----- Original Message ----- > From: "Tom McKay" > To: "Malini Rao" , "Kyle Baker" > Cc: katello-devel at redhat.com > Sent: Monday, July 9, 2012 4:17:32 PM > Subject: UX project: redesign of permissions interface > > > Although the current permissions interface for adding to a role is > well crafted, I continually find that it is very difficult to use > for my primary two use cases: Seeing what permissions a role has, > and setting up the permissions for a new role. Yes, these are > probably the two most primary use cases. :) > > I keep wishing for some sort of spreadsheet or table view where, at a > glance, I can both see and modify the permissions with checkbox > toggles. Maybe it's not a single table, but multiple small tables. > I'm sure some UX magic can be applied to this notion. > > Would it be possible to get some thoughts on this? > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From thomasmckay at redhat.com Tue Jul 10 13:01:40 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 10 Jul 2012 09:01:40 -0400 (EDT) Subject: [katello-devel] available release versions In-Reply-To: <20120709145637.GC60192@pipboy.redhat.com> Message-ID: <586cf00e-e2bf-46e7-a293-aa286e7ea61e@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "James Bowes" > To: "Bryan Kearney" > Cc: katello-devel at redhat.com > Sent: Monday, July 9, 2012 10:56:38 AM > Subject: Re: [katello-devel] available release versions > > On Mon, Jul 09, 2012 at 06:40:08AM -0400, Bryan Kearney wrote: > > On 07/06/2012 11:00 AM, Tom McKay wrote: > > >https://bugzilla.redhat.com/show_bug.cgi?id=834012 > > > > > >Both headpin and subscription-manager-gui reach out to the CDN to > > >get a list of available release versions (5.8, 6.2, etc.). > > >Katello, however, bases the available release versions on the > > >subset that have repos enabled. > > > > > >With that in mind, I think the BZ above is working as intended, > > >ie. release versions shown in subscription-manager-gui have > > >nothing to do with what katello has available. > > > > > >I think there have been BZs/RFEs that systems should not be able > > >to set a release version when registered to katello to a version > > >where no repos (and hence no content) are available. > > > > > >Someone with more knowledge of the feature and intricacies please > > >chime in. > > > > > >_______________________________________________ > > >katello-devel mailing list > > >katello-devel at redhat.com > > >https://www.redhat.com/mailman/listinfo/katello-devel > > > > > Where does subscription manager reach out to? It would be great if > > it looked into the directories which are published by katello. > > > > Here is roughly what subman does: > - for all installed products on a system, iterate over the products: > - if a product has the product tag 'rhel-N' consider it to be a > base OS > product. > - take the last found base os product > - if no base os products found, set available releases to an empty > list. > - with the last found base os product, find all entitlements that > grant > access to that product > - create an empty list, listings > - for each entitlement, do: > - for each _enabled_ content set on the entitlement, do: > - compare the product tag to the content set's required tag, ie > (rhel-6 matches rhel-6 but not rhel-5). If the tags do not > match, > continue to the next content set. > - take the content set's url, and split it on $releasever. Take > the > section before the split, and append '/listing' to it. This is > the > location on the CDN where we expect to find a listing file for > this OS. add this file location to the listings list. > - for each entry in listings, download the file from the cdn. > - create a set containing all entries from all listings files. > - done! > > > As far as I can tell, SAM does: > - for each content set, grab its listing file, if available. return a > set of the results. > > > Katello/CFSE does: > - for each enabled content set in a system's environment, get the > content set's applicable releases. return a set of the results. > > I assume the CFSE results come from pulp, but let's also assume that > they'll be identical to whatever the CDN would have. > > Therefore, the difference between CFSE and SAM is that katello only > examines the content sets that are enabled in a given environment. > This > makes sense, as any content not enabled is totally inaccessible for > all > consumers in that environment. SAM doesn't have environments, so the > difference is moot. > > Between katello and subman, katello's results should be a superset of > what subman sees. > > Subman removes the following content sets: > - content sets that don't map to an installed product on the system > (makes sense, imo) > - content sets that don't map to an entitled product on the system > (makes sense for subman. could probably be a toggle for katello, > defaulting to only showing entitled ones, or showing all if the > system > doesn't have any entitlements) > - content sets that are not enabled on the client (i dunno if katello > has access to this, but i think this could fall in with the above > logic) > - content sets that don't map to a product tagged with rhel-N (this > is > probably a bit broken. we should maybe be looking for a product > tagged > with baseOS or something? but its more of an optimization; other > content sets won't have listing files. safe to ignore for katello). > - content sets that aren't tagged with the same rhel version as the > installed product (this makes sense to do in katello if possible, > and > again, probably as a toggle. you likely don't want to put your > system > on 6Server if it has 4AS installed). > > Phew! That was a lot of stuff. > > So, back to the original referenced bug. If the cli can use > releaseVer > against that SAM instance, but the gui can't, that totally sounds > like a > bug! The logic in both cli and gui should be the same, so we should > rectify that, then if that makes the gui work, good. if not, there > might > be a bug in SAM. So I think we are agreeing to put this BZ into the subscription-manager bucket at the moment? Is this BZ a blocker in any way? It does need to be addressed, but in which release? > > -James > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jbowes at redhat.com Tue Jul 10 13:06:31 2012 From: jbowes at redhat.com (James Bowes) Date: Tue, 10 Jul 2012 10:06:31 -0300 Subject: [katello-devel] available release versions In-Reply-To: <586cf00e-e2bf-46e7-a293-aa286e7ea61e@zmail16.collab.prod.int.phx2.redhat.com> References: <20120709145637.GC60192@pipboy.redhat.com> <586cf00e-e2bf-46e7-a293-aa286e7ea61e@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <20120710130631.GL60192@pipboy.redhat.com> On Tue, Jul 10, 2012 at 09:01:40AM -0400, Tom McKay wrote: > > > ----- Original Message ----- > > From: "James Bowes" > > To: "Bryan Kearney" > > Cc: katello-devel at redhat.com > > Sent: Monday, July 9, 2012 10:56:38 AM > > Subject: Re: [katello-devel] available release versions > > > > On Mon, Jul 09, 2012 at 06:40:08AM -0400, Bryan Kearney wrote: > > > On 07/06/2012 11:00 AM, Tom McKay wrote: > > > >https://bugzilla.redhat.com/show_bug.cgi?id=834012 > > > > > > > >Both headpin and subscription-manager-gui reach out to the CDN to > > > >get a list of available release versions (5.8, 6.2, etc.). > > > >Katello, however, bases the available release versions on the > > > >subset that have repos enabled. > > > > > > > >With that in mind, I think the BZ above is working as intended, > > > >ie. release versions shown in subscription-manager-gui have > > > >nothing to do with what katello has available. > > > > > > > >I think there have been BZs/RFEs that systems should not be able > > > >to set a release version when registered to katello to a version > > > >where no repos (and hence no content) are available. > > > > > > > >Someone with more knowledge of the feature and intricacies please > > > >chime in. > > > > > > > >_______________________________________________ > > > >katello-devel mailing list > > > >katello-devel at redhat.com > > > >https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > > Where does subscription manager reach out to? It would be great if > > > it looked into the directories which are published by katello. > > > > > > > Here is roughly what subman does: > > - for all installed products on a system, iterate over the products: > > - if a product has the product tag 'rhel-N' consider it to be a > > base OS > > product. > > - take the last found base os product > > - if no base os products found, set available releases to an empty > > list. > > - with the last found base os product, find all entitlements that > > grant > > access to that product > > - create an empty list, listings > > - for each entitlement, do: > > - for each _enabled_ content set on the entitlement, do: > > - compare the product tag to the content set's required tag, ie > > (rhel-6 matches rhel-6 but not rhel-5). If the tags do not > > match, > > continue to the next content set. > > - take the content set's url, and split it on $releasever. Take > > the > > section before the split, and append '/listing' to it. This is > > the > > location on the CDN where we expect to find a listing file for > > this OS. add this file location to the listings list. > > - for each entry in listings, download the file from the cdn. > > - create a set containing all entries from all listings files. > > - done! > > > > > > As far as I can tell, SAM does: > > - for each content set, grab its listing file, if available. return a > > set of the results. > > > > > > Katello/CFSE does: > > - for each enabled content set in a system's environment, get the > > content set's applicable releases. return a set of the results. > > > > I assume the CFSE results come from pulp, but let's also assume that > > they'll be identical to whatever the CDN would have. > > > > Therefore, the difference between CFSE and SAM is that katello only > > examines the content sets that are enabled in a given environment. > > This > > makes sense, as any content not enabled is totally inaccessible for > > all > > consumers in that environment. SAM doesn't have environments, so the > > difference is moot. > > > > Between katello and subman, katello's results should be a superset of > > what subman sees. > > > > Subman removes the following content sets: > > - content sets that don't map to an installed product on the system > > (makes sense, imo) > > - content sets that don't map to an entitled product on the system > > (makes sense for subman. could probably be a toggle for katello, > > defaulting to only showing entitled ones, or showing all if the > > system > > doesn't have any entitlements) > > - content sets that are not enabled on the client (i dunno if katello > > has access to this, but i think this could fall in with the above > > logic) > > - content sets that don't map to a product tagged with rhel-N (this > > is > > probably a bit broken. we should maybe be looking for a product > > tagged > > with baseOS or something? but its more of an optimization; other > > content sets won't have listing files. safe to ignore for katello). > > - content sets that aren't tagged with the same rhel version as the > > installed product (this makes sense to do in katello if possible, > > and > > again, probably as a toggle. you likely don't want to put your > > system > > on 6Server if it has 4AS installed). > > > > Phew! That was a lot of stuff. > > > > So, back to the original referenced bug. If the cli can use > > releaseVer > > against that SAM instance, but the gui can't, that totally sounds > > like a > > bug! The logic in both cli and gui should be the same, so we should > > rectify that, then if that makes the gui work, good. if not, there > > might > > be a bug in SAM. > > So I think we are agreeing to put this BZ into the subscription-manager bucket at the moment? > > Is this BZ a blocker in any way? It does need to be addressed, but in which release? > I'll do some triage on it quickly today, then assign it as appropriate. As for releaseVer setting, IMO katello could use the enhancements I outlined above, to fall more in line with subscription-manager :) > > > > -James > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -James -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mrao at redhat.com Tue Jul 10 14:23:23 2012 From: mrao at redhat.com (Malini Rao) Date: Tue, 10 Jul 2012 10:23:23 -0400 (EDT) Subject: [katello-devel] UX project: redesign of permissions interface In-Reply-To: <932a613c-fc84-46f4-9c15-0526791d9152@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <50b09a25-624d-4572-849e-72ad6b1c1158@zmail12.collab.prod.int.phx2.redhat.com> Tom, If you send us the user stories with the requirements, we will be happy to sketch something out and share with you and everyone else. Thanks Malini ----- Original Message ----- From: "Tom McKay" To: "Malini Rao" Cc: katello-devel at redhat.com, "Kyle Baker" Sent: Tuesday, July 10, 2012 7:59:58 AM Subject: Re: UX project: redesign of permissions interface Yes, this is along the lines of what I had imagined. I'll sketch out some ideas during this sprint and see if I can get it added to the backlog. ----- Original Message ----- > From: "Malini Rao" > To: "Tom McKay" > Cc: katello-devel at redhat.com, "Kyle Baker" > Sent: Monday, July 9, 2012 4:33:57 PM > Subject: Re: UX project: redesign of permissions interface > > Tom, > > I haven't explored how the Roles UI works in Katello but I worked on > some designs for a similar usecase on Aeolus/ Conductor. See > attached. This was an initial idea that was well-liked but not sure > if it was finally scoped in or not ( This was a long time ago). But > I think it definitely points at one of the use cases that you are > talking about in some form. We can come up with some proposals if it > is something that is a candidate for one of the upcoming sprints. > > Thanks > Malini > > ----- Original Message ----- > From: "Tom McKay" > To: "Malini Rao" , "Kyle Baker" > Cc: katello-devel at redhat.com > Sent: Monday, July 9, 2012 4:17:32 PM > Subject: UX project: redesign of permissions interface > > > Although the current permissions interface for adding to a role is > well crafted, I continually find that it is very difficult to use > for my primary two use cases: Seeing what permissions a role has, > and setting up the permissions for a new role. Yes, these are > probably the two most primary use cases. :) > > I keep wishing for some sort of spreadsheet or table view where, at a > glance, I can both see and modify the permissions with checkbox > toggles. Maybe it's not a single table, but multiple small tables. > I'm sure some UX magic can be applied to this notion. > > Would it be possible to get some thoughts on this? > From paji at redhat.com Tue Jul 10 16:27:00 2012 From: paji at redhat.com (Partha Aji) Date: Tue, 10 Jul 2012 12:27:00 -0400 (EDT) Subject: [katello-devel] UX project: redesign of permissions interface In-Reply-To: <932a613c-fc84-46f4-9c15-0526791d9152@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4260bbdb-30b2-417c-8337-b7d72c2d13a6@zmail14.collab.prod.int.phx2.redhat.com> I think the Aeolus/ Conductor view presented is a little simplistic given the degree of detail with respect to the permission clauses in katello. Look at some of the forms of permission clauses https://fedorahosted.org/katello/wiki/PermissionMagic#PermissionExamples The columns would not only need to indicate the verbs which vary by resource types (like provider, activation keys), they would need also indicate the scoping (org/global) and the tag instances. Also the "verbs" used for each of those types are different (not just simple CRUD for everything). I would start by figuring out a way to represent a permission like "Role Foo can Read providers P1 and P2 in Organization 1" and then go along representing "user can modify systems in Organization 2" in the same grid. My view on this at this point is that I can see definite value for some sort of summary on role, it could be something as simple as text that shows up when we hover on a role to show the permissions that belong to it or some cool way to visualize that. As far as editing/creating perms is concerned I m not sure I would care that much for a grid view since the current UI neatly tries to classify things based on "Org Based Perms" vs "Global Perms". That is not to say they can't be improved but for me Role Summary is much more important than Role edit at this point.. Partha ----- Original Message ----- > From: "Tom McKay" > To: "Malini Rao" > Cc: katello-devel at redhat.com > Sent: Tuesday, July 10, 2012 7:59:58 AM > Subject: Re: [katello-devel] UX project: redesign of permissions interface > > Yes, this is along the lines of what I had imagined. I'll sketch out > some ideas during this sprint and see if I can get it added to the > backlog. > > ----- Original Message ----- > > From: "Malini Rao" > > To: "Tom McKay" > > Cc: katello-devel at redhat.com, "Kyle Baker" > > Sent: Monday, July 9, 2012 4:33:57 PM > > Subject: Re: UX project: redesign of permissions interface > > > > Tom, > > > > I haven't explored how the Roles UI works in Katello but I worked > > on > > some designs for a similar usecase on Aeolus/ Conductor. See > > attached. This was an initial idea that was well-liked but not sure > > if it was finally scoped in or not ( This was a long time ago). But > > I think it definitely points at one of the use cases that you are > > talking about in some form. We can come up with some proposals if > > it > > is something that is a candidate for one of the upcoming sprints. > > > > Thanks > > Malini > > > > ----- Original Message ----- > > From: "Tom McKay" > > To: "Malini Rao" , "Kyle Baker" > > > > Cc: katello-devel at redhat.com > > Sent: Monday, July 9, 2012 4:17:32 PM > > Subject: UX project: redesign of permissions interface > > > > > > Although the current permissions interface for adding to a role is > > well crafted, I continually find that it is very difficult to use > > for my primary two use cases: Seeing what permissions a role has, > > and setting up the permissions for a new role. Yes, these are > > probably the two most primary use cases. :) > > > > I keep wishing for some sort of spreadsheet or table view where, at > > a > > glance, I can both see and modify the permissions with checkbox > > toggles. Maybe it's not a single table, but multiple small tables. > > I'm sure some UX magic can be applied to this notion. > > > > Would it be possible to get some thoughts on this? > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From bkearney at redhat.com Thu Jul 12 14:30:44 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 12 Jul 2012 10:30:44 -0400 Subject: [katello-devel] Where should subscriptions be? Message-ID: <4FFEDF94.5090808@redhat.com> Questions from some design sessions on Foreman integration. Where should we tie subscriptions to? We could put them onto the the component outline to say "Any system provisioned from this outline should consume from this subscription". This is better for the case where you create the system record first, and then provision it. Or, we could put them on the activation key which would say "When you register this machine with this key, you get this subscription". This is better when you provision outside of katello and then register the machine back. Or, we could put them on both, and have some logic about how to handle the case when it is on both. Or, perhaps, every component outline gets an activation key? -- bk From bkearney at redhat.com Thu Jul 12 14:34:17 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 12 Jul 2012 10:34:17 -0400 Subject: [katello-devel] where is pulp on doing one time tokens Message-ID: <4FFEE069.60500@redhat.com> Hey Pulp folken. Where is time based urls on your backlog? Is that a V2 thing? I am curious to know where I should put this onto the backlog. -- bk From bkearney at redhat.com Thu Jul 12 15:49:10 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 12 Jul 2012 11:49:10 -0400 Subject: [katello-devel] How should we post objects Message-ID: <4FFEF1F6.9030700@redhat.com> The API Conventions Document (https://fedorahosted.org/katello/wiki/APIConventions) says that objects should be fully qualified. So, if we return a person object the json should be: { person: { name: "JarJar Binks", id: "1" } } My question is, if I want to create or update a person, what should the body of the html messgae be? Should it be: POST /people { person: { name: "Anakin Skywalker", } } POST /people/1 { person: { name: "Jar Jar Binkage", } } OR POST /people { name: "Anakin Skywalker", } POST /people/1 { name: "Jar Jar Binkage", } Opinions? I ask because both are used in the API today :) -- bk From bkearney at redhat.com Thu Jul 12 15:50:53 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 12 Jul 2012 11:50:53 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120703143227.GG5554@lzapx.brq.redhat.com> References: <93a56aaf-2b37-4a3e-ba24-3e1813a9d1b5@zmail16.collab.prod.int.phx2.redhat.com> <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> <20120702124201.GF3743@lzapx.brq.redhat.com> <4FF2EA4F.6050509@redhat.com> <20120703143227.GG5554@lzapx.brq.redhat.com> Message-ID: <4FFEF25D.5000608@redhat.com> On 07/03/2012 10:32 AM, Lukas Zapletal wrote: > On Tue, Jul 03, 2012 at 02:49:19PM +0200, Miroslav Suchy wrote: >> On 07/02/2012 02:42 PM, Lukas Zapletal wrote: >>> Exactly, I will add that Bundler itself with its Gemfile.lock should be >>> able to "lock" versions for us, but guys were seeing some issues in >>> regard to updating, so this is also the reason for our own repo. >>> >>> In future, we would like to build both Fedora and RHEL repositories from >>> Koji and start extracting those gems from RPMs inself - that would give >>> us three gem repos (for Fedoras and for RHEL). So devs should be able to >>> switch over from Fedora environment to RHEL easily. >> >> I would suggest - If you need gem, which is not in Fedora, do not >> download pure gem file, but put it in kalpana-gems. Create spec file >> for that (this will make Review Request in Fedora later easier) and >> build it in Koji using HOWTO I sent today. >> I can even create yum repository with developers gem then. >> And if some of them appear in Fedora/RHEL you do not need to change >> anything and the transition will be flawless. >> You can even create meta-package "developer-setup", which will >> require all developers gem. So if you introduce new gem, everybody >> will get it during their "yum upgrade" and you even do not have to >> announce it. >> > > Sounds like a plan, but that is extra work. But we could do it, would be > much nicer for sure. > > Can we get all the gems we need into a single repo? I ask becuase it would be great to see Katello running on $SOME_OTHER_DISTRO and $SOME_OTHER_OS. -- bk From mmccune at redhat.com Thu Jul 12 17:35:57 2012 From: mmccune at redhat.com (Mike McCune) Date: Thu, 12 Jul 2012 10:35:57 -0700 Subject: [katello-devel] where is pulp on doing one time tokens In-Reply-To: <4FFEE069.60500@redhat.com> References: <4FFEE069.60500@redhat.com> Message-ID: <4FFF0AFD.1080007@redhat.com> On 07/12/2012 07:34 AM, Bryan Kearney wrote: > Hey Pulp folken. Where is time based urls on your backlog? Is that a V2 > thing? I am curious to know where I should put this onto the backlog. > > -- bk did you intend this to go to katello-devel? Or perhaps pulp-list .... Personally I don't know the answer .. Mike From tsanders at redhat.com Thu Jul 12 17:53:39 2012 From: tsanders at redhat.com (Todd Sanders) Date: Thu, 12 Jul 2012 13:53:39 -0400 Subject: [katello-devel] where is pulp on doing one time tokens In-Reply-To: <4FFF0AFD.1080007@redhat.com> References: <4FFEE069.60500@redhat.com> <4FFF0AFD.1080007@redhat.com> Message-ID: <4FFF0F23.7000009@redhat.com> On 07/12/2012 01:35 PM, Mike McCune wrote: > On 07/12/2012 07:34 AM, Bryan Kearney wrote: >> Hey Pulp folken. Where is time based urls on your backlog? Is that a V2 >> thing? I am curious to know where I should put this onto the backlog. >> >> -- bk > > > did you intend this to go to katello-devel? Or perhaps pulp-list .... > > Personally I don't know the answer .. > > Mike > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Prad did a prototype -> https://fedorahosted.org/pulp/wiki/KSTreePublish; could be used for any content unit. What is the use case that katello needs this for? -Todd From jomara at redhat.com Thu Jul 12 20:00:28 2012 From: jomara at redhat.com (Jordan OMara) Date: Thu, 12 Jul 2012 16:00:28 -0400 Subject: [katello-devel] new gem dependency - ldap_fluff Message-ID: <20120712200028.GJ15444@redhat.com> the ldap_fluff gem now provides ldap support to katello. it is a runtime dependency for katello even if you aren't using LDAP so you'll need to install it. if you're connected to our fedorahosted repo you can just: > yum install rubygem-ldap_fluff or if you use rvm/bundler you can: > gem install ldap_fluff enjoy! -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From bkearney at redhat.com Thu Jul 12 21:14:51 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 12 Jul 2012 17:14:51 -0400 Subject: [katello-devel] where is pulp on doing one time tokens In-Reply-To: <4FFF0F23.7000009@redhat.com> References: <4FFEE069.60500@redhat.com> <4FFF0AFD.1080007@redhat.com> <4FFF0F23.7000009@redhat.com> Message-ID: <4FFF3E4B.6090808@redhat.com> On 07/12/2012 01:53 PM, Todd Sanders wrote: > On 07/12/2012 01:35 PM, Mike McCune wrote: >> On 07/12/2012 07:34 AM, Bryan Kearney wrote: >>> Hey Pulp folken. Where is time based urls on your backlog? Is that a V2 >>> thing? I am curious to know where I should put this onto the backlog. >>> >>> -- bk >> >> >> did you intend this to go to katello-devel? Or perhaps pulp-list .... >> >> Personally I don't know the answer .. >> >> Mike >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > Prad did a prototype -> > https://fedorahosted.org/pulp/wiki/KSTreePublish; could be used for any > content unit. > > What is the use case that katello needs this for? > > -Todd > As we look to provisioning, it may be nice to be able to get at content via a protected url instead of openng up the trees. Te thought would be when we generate the ks file that has the toke in it. -- bk From cperry at redhat.com Fri Jul 13 12:33:04 2012 From: cperry at redhat.com (Cliff Perry) Date: Fri, 13 Jul 2012 07:33:04 -0500 Subject: [katello-devel] Where should subscriptions be? In-Reply-To: <4FFEDF94.5090808@redhat.com> References: <4FFEDF94.5090808@redhat.com> Message-ID: <50001580.4000003@redhat.com> On 07/12/2012 09:30 AM, Bryan Kearney wrote: > Questions from some design sessions on Foreman integration. Where should > we tie subscriptions to? > > We could put them onto the the component outline to say "Any system > provisioned from this outline should consume from this subscription". > This is better for the case where you create the system record first, > and then provision it. > > Or, we could put them on the activation key which would say "When you > register this machine with this key, you get this subscription". This is > better when you provision outside of katello and then register the > machine back. > > Or, we could put them on both, and have some logic about how to handle > the case when it is on both. Or, perhaps, every component outline gets > an activation key? The last - every component outline gets an activation key - even if it is by default due to some global activationkey used, when no others is specified. Cliff > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Fri Jul 13 13:46:49 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 13 Jul 2012 15:46:49 +0200 Subject: [katello-devel] How should we post objects In-Reply-To: <4FFEF1F6.9030700@redhat.com> References: <4FFEF1F6.9030700@redhat.com> Message-ID: <20120713134649.GB4100@lzapx.brq.redhat.com> We already discussed this some time ago. There are no big (dis)advantages for any of these. It's just about what we decide to go for. I am for having the wrapper "person" dictionary there. LZ On Thu, Jul 12, 2012 at 11:49:10AM -0400, Bryan Kearney wrote: > The API Conventions Document > (https://fedorahosted.org/katello/wiki/APIConventions) says that > objects should be fully qualified. So, if we return a person object > the json should be: > > > { > person: { > name: "JarJar Binks", > id: "1" > } > } > > My question is, if I want to create or update a person, what should > the body of the html messgae be? Should it be: > > POST /people > { > person: { > name: "Anakin Skywalker", > } > } > > POST /people/1 > { > person: { > name: "Jar Jar Binkage", > } > } > > > OR > > POST /people > { > name: "Anakin Skywalker", > } > > POST /people/1 > { > name: "Jar Jar Binkage", > } > > > Opinions? I ask because both are used in the API today :) > > -- bk > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Jul 13 13:49:42 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 13 Jul 2012 15:49:42 +0200 Subject: [katello-devel] where is pulp on doing one time tokens In-Reply-To: <4FFF3E4B.6090808@redhat.com> References: <4FFEE069.60500@redhat.com> <4FFF0AFD.1080007@redhat.com> <4FFF0F23.7000009@redhat.com> <4FFF3E4B.6090808@redhat.com> Message-ID: <20120713134941.GC4100@lzapx.brq.redhat.com> The required dependency is now in Fedora and EPEL. LZ On Thu, Jul 12, 2012 at 05:14:51PM -0400, Bryan Kearney wrote: > On 07/12/2012 01:53 PM, Todd Sanders wrote: > >On 07/12/2012 01:35 PM, Mike McCune wrote: > >>On 07/12/2012 07:34 AM, Bryan Kearney wrote: > >>>Hey Pulp folken. Where is time based urls on your backlog? Is that a V2 > >>>thing? I am curious to know where I should put this onto the backlog. > >>> > >>>-- bk > >> > >> > >>did you intend this to go to katello-devel? Or perhaps pulp-list .... > >> > >>Personally I don't know the answer .. > >> > >>Mike > >> > >>_______________________________________________ > >>katello-devel mailing list > >>katello-devel at redhat.com > >>https://www.redhat.com/mailman/listinfo/katello-devel > > > >Prad did a prototype -> > >https://fedorahosted.org/pulp/wiki/KSTreePublish; could be used for any > >content unit. > > > >What is the use case that katello needs this for? > > > >-Todd > > > As we look to provisioning, it may be nice to be able to get at > content via a protected url instead of openng up the trees. Te > thought would be when we generate the ks file that has the toke in > it. > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From tsanders at redhat.com Fri Jul 13 14:31:12 2012 From: tsanders at redhat.com (Todd Sanders) Date: Fri, 13 Jul 2012 10:31:12 -0400 Subject: [katello-devel] where is pulp on doing one time tokens In-Reply-To: <20120713134941.GC4100@lzapx.brq.redhat.com> References: <4FFEE069.60500@redhat.com> <4FFF0AFD.1080007@redhat.com> <4FFF0F23.7000009@redhat.com> <4FFF3E4B.6090808@redhat.com> <20120713134941.GC4100@lzapx.brq.redhat.com> Message-ID: <50003130.70600@redhat.com> K. We'll (Pulp) will get this aligned to our next sprint. -Todd On 07/13/2012 09:49 AM, Lukas Zapletal wrote: > The required dependency is now in Fedora and EPEL. > > LZ > > On Thu, Jul 12, 2012 at 05:14:51PM -0400, Bryan Kearney wrote: >> On 07/12/2012 01:53 PM, Todd Sanders wrote: >>> On 07/12/2012 01:35 PM, Mike McCune wrote: >>>> On 07/12/2012 07:34 AM, Bryan Kearney wrote: >>>>> Hey Pulp folken. Where is time based urls on your backlog? Is that a V2 >>>>> thing? I am curious to know where I should put this onto the backlog. >>>>> >>>>> -- bk >>>> >>>> did you intend this to go to katello-devel? Or perhaps pulp-list .... >>>> >>>> Personally I don't know the answer .. >>>> >>>> Mike >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> Prad did a prototype -> >>> https://fedorahosted.org/pulp/wiki/KSTreePublish; could be used for any >>> content unit. >>> >>> What is the use case that katello needs this for? >>> >>> -Todd >>> >> As we look to provisioning, it may be nice to be able to get at >> content via a protected url instead of openng up the trees. Te >> thought would be when we generate the ks file that has the toke in >> it. >> >> -- bk >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From dmitri at redhat.com Fri Jul 13 15:07:54 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 13 Jul 2012 19:07:54 +0400 Subject: [katello-devel] How should we post objects In-Reply-To: <20120713134649.GB4100@lzapx.brq.redhat.com> References: <4FFEF1F6.9030700@redhat.com> <20120713134649.GB4100@lzapx.brq.redhat.com> Message-ID: <500039CA.20900@redhat.com> The difference between creating a new object and updating an existing one is (in the context of this discussion) in idempotency: repeated calls to create an object may return a new object every time, while making the same change over and over again should result in the same state of the object. So: POST is for creation, PUT is for updates. To create a new object it is necessary to pass in a set of attributes that allows a creation of the object in a valid state. Until we have support for PATCH, I'm thinking all updates should be treated as partials, with optimistic locking via ETAGS (we don't have the latter bit yet). Cheers, -d On 13/07/12 05:46 PM, Lukas Zapletal wrote: > We already discussed this some time ago. There are no big > (dis)advantages for any of these. It's just about what we decide to go > for. > > I am for having the wrapper "person" dictionary there. > > LZ > > On Thu, Jul 12, 2012 at 11:49:10AM -0400, Bryan Kearney wrote: >> The API Conventions Document >> (https://fedorahosted.org/katello/wiki/APIConventions) says that >> objects should be fully qualified. So, if we return a person object >> the json should be: >> >> >> { >> person: { >> name: "JarJar Binks", >> id: "1" >> } >> } >> >> My question is, if I want to create or update a person, what should >> the body of the html messgae be? Should it be: >> >> POST /people >> { >> person: { >> name: "Anakin Skywalker", >> } >> } >> >> POST /people/1 >> { >> person: { >> name: "Jar Jar Binkage", >> } >> } >> >> >> OR >> >> POST /people >> { >> name: "Anakin Skywalker", >> } >> >> POST /people/1 >> { >> name: "Jar Jar Binkage", >> } >> >> >> Opinions? I ask because both are used in the API today :) >> >> -- bk >> >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Mon Jul 16 07:51:58 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 16 Jul 2012 09:51:58 +0200 Subject: [katello-devel] New build katello-0.2.45-1 Message-ID: <20120716075158.GC4145@lzapx.brq.redhat.com> Hello, we have a new build in the repo. Many fixes and some new features: - organization login switcher reworked - many changes in system groups - LDAP support using ldap_fluff gem - jshint checker for developers We are nearing first release, if you have any comments please let us know! Happy hacking. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Mon Jul 16 08:32:03 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 16 Jul 2012 10:32:03 +0200 Subject: [katello-devel] Fedora 17 status Message-ID: <20120716083203.GD4145@lzapx.brq.redhat.com> Guys, how far are we with Fedora 17 support? Lot's of things got changed (Ruby 1.9 etc). Is there anyone running Katello on F17? LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From pchalupa at redhat.com Mon Jul 16 11:26:07 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Mon, 16 Jul 2012 13:26:07 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <4FFEF25D.5000608@redhat.com> References: <93a56aaf-2b37-4a3e-ba24-3e1813a9d1b5@zmail16.collab.prod.int.phx2.redhat.com> <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> <20120702124201.GF3743@lzapx.brq.redhat.com> <4FF2EA4F.6050509@redhat.com> <20120703143227.GG5554@lzapx.brq.redhat.com> <4FFEF25D.5000608@redhat.com> Message-ID: <5003FA4F.6080107@redhat.com> I have a counter proposal which is more from Ruby world then the solution described in previous emails. - remove source 'http://repos.fedorapeople.org/repos/katello/gems/' and other sources from Gemfile - store all needed gems in vendor/cache as .gem files (directly in katello master or a git-submodule) (all versions for f16 and RHEL) - install gems with bundle install (without source specified bundler picks up gems from vendor/cache) Advantages: - you can install all required gems on any platform: fedora, ubuntu or osx (which I need) - faster installation - you can switch between fedora/RHEL env by replacing Gemfile.lock (lets say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our git for this purpose) - easy access to and updates of gem versions - you can include gems with CVE patches from fedora, everybody would have correct versions of gems (which I currently don't have) Disadvantages - rubygem-* rpms are not being correctly packed. The included .gem files are not containing CVE patches. We would need to come up with a workaround to build updated .gem files or fix the issue. If this is fixed, all you have to do to store gems in vendor/cache is 'bundle package' [1]. - other possible problems i do not see, any ideas? [1] http://gembundler.com/bundle_package.html What do you think? Petr On 12.07.12 17:50, Bryan Kearney wrote: > On 07/03/2012 10:32 AM, Lukas Zapletal wrote: >> On Tue, Jul 03, 2012 at 02:49:19PM +0200, Miroslav Suchy wrote: >>> On 07/02/2012 02:42 PM, Lukas Zapletal wrote: >>>> Exactly, I will add that Bundler itself with its Gemfile.lock should be >>>> able to "lock" versions for us, but guys were seeing some issues in >>>> regard to updating, so this is also the reason for our own repo. >>>> >>>> In future, we would like to build both Fedora and RHEL repositories >>>> from >>>> Koji and start extracting those gems from RPMs inself - that would give >>>> us three gem repos (for Fedoras and for RHEL). So devs should be >>>> able to >>>> switch over from Fedora environment to RHEL easily. >>> >>> I would suggest - If you need gem, which is not in Fedora, do not >>> download pure gem file, but put it in kalpana-gems. Create spec file >>> for that (this will make Review Request in Fedora later easier) and >>> build it in Koji using HOWTO I sent today. >>> I can even create yum repository with developers gem then. >>> And if some of them appear in Fedora/RHEL you do not need to change >>> anything and the transition will be flawless. >>> You can even create meta-package "developer-setup", which will >>> require all developers gem. So if you introduce new gem, everybody >>> will get it during their "yum upgrade" and you even do not have to >>> announce it. >>> >> >> Sounds like a plan, but that is extra work. But we could do it, would be >> much nicer for sure. >> >> > Can we get all the gems we need into a single repo? I ask becuase it > would be great to see Katello running on $SOME_OTHER_DISTRO and > $SOME_OTHER_OS. > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From thomasmckay at redhat.com Mon Jul 16 12:22:05 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 16 Jul 2012 08:22:05 -0400 (EDT) Subject: [katello-devel] icon to represent "virtual guest" subscription In-Reply-To: Message-ID: <118ee9a9-ad3c-4f10-bf70-7a7b412556fa@zmail16.collab.prod.int.phx2.redhat.com> UXers, I am currently using Green icons for subscriptions with Yellow icons for those created through consumption of a subscription (ie. "virtual guest" subscription). A third possible member of the list, though it is not currently shown, is custom product subscriptions. If you have better icons for these cases, let me know. From bkearney at redhat.com Mon Jul 16 12:23:25 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 16 Jul 2012 08:23:25 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <5003FA4F.6080107@redhat.com> References: <93a56aaf-2b37-4a3e-ba24-3e1813a9d1b5@zmail16.collab.prod.int.phx2.redhat.com> <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> <20120702124201.GF3743@lzapx.brq.redhat.com> <4FF2EA4F.6050509@redhat.com> <20120703143227.GG5554@lzapx.brq.redhat.com> <4FFEF25D.5000608@redhat.com> <5003FA4F.6080107@redhat.com> Message-ID: <500407BD.5050503@redhat.com> On 07/16/2012 07:26 AM, Petr Chalupa wrote: > I have a counter proposal which is more from Ruby world then the > solution described in previous emails. > > - remove source 'http://repos.fedorapeople.org/repos/katello/gems/' and > other sources from Gemfile > - store all needed gems in vendor/cache as .gem files (directly in > katello master or a git-submodule) (all versions for f16 and RHEL) > - install gems with bundle install (without source specified bundler > picks up gems from vendor/cache) > > Advantages: > - you can install all required gems on any platform: fedora, ubuntu or > osx (which I need) > - faster installation > - you can switch between fedora/RHEL env by replacing Gemfile.lock (lets > say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our git for > this purpose) > - easy access to and updates of gem versions > - you can include gems with CVE patches from fedora, everybody would > have correct versions of gems (which I currently don't have) > > Disadvantages > - rubygem-* rpms are not being correctly packed. The included .gem files > are not containing CVE patches. We would need to come up with a > workaround to build updated .gem files or fix the issue. If this is > fixed, all you have to do to store gems in vendor/cache is 'bundle > package' [1]. > - other possible problems i do not see, any ideas? > > [1] http://gembundler.com/bundle_package.html > > What do you think? > > Petr > Could we do this model for DEV, and then work on proper packaging for each distro? I think it would help alot if we could be more friendly to DEVs. -- bk From thomasmckay at redhat.com Mon Jul 16 12:29:35 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 16 Jul 2012 08:29:35 -0400 (EDT) Subject: [katello-devel] where to get required katello gems In-Reply-To: <500407BD.5050503@redhat.com> Message-ID: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Bryan Kearney" > To: katello-devel at redhat.com > Sent: Monday, July 16, 2012 8:23:25 AM > Subject: Re: [katello-devel] where to get required katello gems > > On 07/16/2012 07:26 AM, Petr Chalupa wrote: > > I have a counter proposal which is more from Ruby world then the > > solution described in previous emails. > > > > - remove source 'http://repos.fedorapeople.org/repos/katello/gems/' > > and > > other sources from Gemfile > > - store all needed gems in vendor/cache as .gem files (directly in > > katello master or a git-submodule) (all versions for f16 and RHEL) > > - install gems with bundle install (without source specified > > bundler > > picks up gems from vendor/cache) > > > > Advantages: > > - you can install all required gems on any platform: fedora, ubuntu > > or > > osx (which I need) > > - faster installation > > - you can switch between fedora/RHEL env by replacing Gemfile.lock > > (lets > > say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our git > > for > > this purpose) > > - easy access to and updates of gem versions > > - you can include gems with CVE patches from fedora, everybody > > would > > have correct versions of gems (which I currently don't have) > > > > Disadvantages > > - rubygem-* rpms are not being correctly packed. The included .gem > > files > > are not containing CVE patches. We would need to come up with a > > workaround to build updated .gem files or fix the issue. If this is > > fixed, all you have to do to store gems in vendor/cache is 'bundle > > package' [1]. > > - other possible problems i do not see, any ideas? > > > > [1] http://gembundler.com/bundle_package.html > > > > What do you think? > > > > Petr > > > > Could we do this model for DEV, and then work on proper packaging for > each distro? I think it would help alot if we could be more friendly > to > DEVs. > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > I said half jokingly on IRC the other day that we should have a 'katello-configure --developer' which would install everything for use with a git checkout. This would make it completely simple for anyone to get up and going with a dev setup. Perhaps they would just point to the git checkout: % katello-configure --developer /home/dudette/katello From msuchy at redhat.com Mon Jul 16 12:38:17 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Mon, 16 Jul 2012 14:38:17 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <5003FA4F.6080107@redhat.com> References: <93a56aaf-2b37-4a3e-ba24-3e1813a9d1b5@zmail16.collab.prod.int.phx2.redhat.com> <9bcf5a6d-44b1-4cfe-8abc-4e286ac73f48@zmail16.collab.prod.int.phx2.redhat.com> <20120702124201.GF3743@lzapx.brq.redhat.com> <4FF2EA4F.6050509@redhat.com> <20120703143227.GG5554@lzapx.brq.redhat.com> <4FFEF25D.5000608@redhat.com> <5003FA4F.6080107@redhat.com> Message-ID: <50040B39.8060408@redhat.com> On 16.7.2012 13:26, Petr Chalupa wrote: > What do you think? Can Katello manage gem files? I would keep with stuff which we can manage, i.e. rpms. > - easy access to and updates of gem versions This is actually disadvantage. Common develops thinking is (and I will demonstrate it on commit c8e285af632f539874ae7b6836968996713bc2dd): "We need to add new gem rubygem-daemons" "Lets see what I can get?" - OK, version 1.1.4 "Let put it in buildrequires" And no one cares that in RHEL and Fedora is only 1.0.10. So instead thinking about it, whether we can make it work with 1.0.10, we will have to package and maintain one additional package for 3 other platforms. :( Mirek From kybaker at redhat.com Mon Jul 16 13:24:06 2012 From: kybaker at redhat.com (Kyle Baker) Date: Mon, 16 Jul 2012 09:24:06 -0400 (EDT) Subject: [katello-devel] icon to represent "virtual guest" subscription In-Reply-To: <118ee9a9-ad3c-4f10-bf70-7a7b412556fa@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <98b2ebd4-d0eb-4677-adb7-3aa5bc610916@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > UXers, > > I am currently using Green icons for subscriptions with Yellow icons > for those created through consumption of a subscription (ie. > "virtual guest" subscription). A third possible member of the list, > though it is not currently shown, is custom product subscriptions. > > If you have better icons for these cases, let me know. I think we need to evaluate whether or not we need icons at all. The green, yellow, and red icons traditionally show status and that is how they are used on the Systems screen. Though what you are describing are icons that represent the types of subscriptions. Are these all of the current subscription types? - Current Subscription Subscription created though consumption Custom Product Subscription Do we foresee more types of subscriptions in the future? Is it also important to show the status of a subscription (expired, not expired) in icon form? > From morazi at redhat.com Mon Jul 16 13:28:44 2012 From: morazi at redhat.com (Michael Orazi) Date: Mon, 16 Jul 2012 09:28:44 -0400 (EDT) Subject: [katello-devel] where to get required katello gems In-Reply-To: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: ----- Original Message ----- > > > ----- Original Message ----- > > From: "Bryan Kearney" > > To: katello-devel at redhat.com > > Sent: Monday, July 16, 2012 8:23:25 AM > > Subject: Re: [katello-devel] where to get required katello gems > > > > On 07/16/2012 07:26 AM, Petr Chalupa wrote: > > > I have a counter proposal which is more from Ruby world then the > > > solution described in previous emails. > > > > > > - remove source > > > 'http://repos.fedorapeople.org/repos/katello/gems/' > > > and > > > other sources from Gemfile > > > - store all needed gems in vendor/cache as .gem files (directly > > > in > > > katello master or a git-submodule) (all versions for f16 and > > > RHEL) > > > - install gems with bundle install (without source specified > > > bundler > > > picks up gems from vendor/cache) > > > > > > Advantages: > > > - you can install all required gems on any platform: fedora, > > > ubuntu > > > or > > > osx (which I need) > > > - faster installation > > > - you can switch between fedora/RHEL env by replacing > > > Gemfile.lock > > > (lets > > > say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our > > > git > > > for > > > this purpose) > > > - easy access to and updates of gem versions > > > - you can include gems with CVE patches from fedora, everybody > > > would > > > have correct versions of gems (which I currently don't have) > > > > > > Disadvantages > > > - rubygem-* rpms are not being correctly packed. The included > > > .gem > > > files > > > are not containing CVE patches. We would need to come up with a > > > workaround to build updated .gem files or fix the issue. If this > > > is > > > fixed, all you have to do to store gems in vendor/cache is > > > 'bundle > > > package' [1]. > > > - other possible problems i do not see, any ideas? > > > > > > [1] http://gembundler.com/bundle_package.html > > > > > > What do you think? > > > > > > Petr > > > > > > > Could we do this model for DEV, and then work on proper packaging > > for > > each distro? I think it would help alot if we could be more > > friendly > > to > > DEVs. > > > > -- bk > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > I said half jokingly on IRC the other day that we should have a > 'katello-configure --developer' which would install everything for > use with a git checkout. This would make it completely simple for > anyone to get up and going with a dev setup. Perhaps they would just > point to the git checkout: > > % katello-configure --developer /home/dudette/katello > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > There have been some similar discussions on aeolus-devel as well. Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns. Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems. John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer. Mike From thomasmckay at redhat.com Mon Jul 16 13:37:15 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 16 Jul 2012 09:37:15 -0400 (EDT) Subject: [katello-devel] icon to represent "virtual guest" subscription In-Reply-To: <98b2ebd4-d0eb-4677-adb7-3aa5bc610916@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <7e0522ee-62f9-4a73-9965-60df8c209502@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Kyle Baker" > To: "Tom McKay" > Cc: katello-devel at redhat.com, "Matt Reid" , "Malini Rao" > Sent: Monday, July 16, 2012 9:24:06 AM > Subject: Re: icon to represent "virtual guest" subscription > > > > ----- Original Message ----- > > UXers, > > > > I am currently using Green icons for subscriptions with Yellow > > icons > > for those created through consumption of a subscription (ie. > > "virtual guest" subscription). A third possible member of the list, > > though it is not currently shown, is custom product subscriptions. > > > > If you have better icons for these cases, let me know. > > I think we need to evaluate whether or not we need icons at all. The > green, yellow, and red icons traditionally show status and that is > how they are used on the Systems screen. Though what you are > describing are icons that represent the types of subscriptions. Are > these all of the current subscription types? - > Current Subscription > Subscription created though consumption > Custom Product Subscription > > Do we foresee more types of subscriptions in the future? Is it also > important to show the status of a subscription (expired, not > expired) in icon form? > > > > I am in favor of keeping some colored icon indicator as to the type of subscription. It makes it very easy to scan the list. (In fact, having more colored aspects of the left list in various places should be considered, imo.) I don't know if there are more subscription categories other than those three, but I'd not rule it out completely. From bkearney at redhat.com Mon Jul 16 13:38:09 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 16 Jul 2012 09:38:09 -0400 Subject: [katello-devel] How should we post objects In-Reply-To: <500039CA.20900@redhat.com> References: <4FFEF1F6.9030700@redhat.com> <20120713134649.GB4100@lzapx.brq.redhat.com> <500039CA.20900@redhat.com> Message-ID: <50041941.4070205@redhat.com> On 07/13/2012 11:07 AM, Dmitri Dolguikh wrote: > The difference between creating a new object and updating an existing > one is (in the context of this discussion) in idempotency: repeated > calls to create an object may return a new object every time, while > making the same change over and over again should result in the same > state of the object. So: POST is for creation, PUT is for updates. > Agree. My main qustion is if I should be opening bugs where the json which is postd does not have the following: object_name: { attr: "foo" } an instead has: { attr: "foo" } -- bk From adprice at redhat.com Mon Jul 16 13:38:13 2012 From: adprice at redhat.com (Adam Price) Date: Mon, 16 Jul 2012 09:38:13 -0400 (EDT) Subject: [katello-devel] Fedora 17 status In-Reply-To: <20120716083203.GD4145@lzapx.brq.redhat.com> Message-ID: <2f523436-2ec9-41f9-8c4b-275763053422@zmail02.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Monday, July 16, 2012 4:32:03 AM > Subject: [katello-devel] Fedora 17 status > > Guys, > > how far are we with Fedora 17 support? Lot's of things got changed > (Ruby > 1.9 etc). Is there anyone running Katello on F17? > > LZ i managed to get through the install process fine until I came to installing Katello itself. I could not get Katello installed via yum due to dependency issues. Most of the gems in katello where requiring Ruby 1.8 while 1.9 is what's available for f17. I couldn't figure out how to get yum to force install it anyways. > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > -- adam price From bkearney at redhat.com Mon Jul 16 13:40:22 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 16 Jul 2012 09:40:22 -0400 Subject: [katello-devel] Where should subscriptions be? In-Reply-To: <50001580.4000003@redhat.com> References: <4FFEDF94.5090808@redhat.com> <50001580.4000003@redhat.com> Message-ID: <500419C6.8030909@redhat.com> On 07/13/2012 08:33 AM, Cliff Perry wrote: > On 07/12/2012 09:30 AM, Bryan Kearney wrote: >> Questions from some design sessions on Foreman integration. Where should >> we tie subscriptions to? >> >> We could put them onto the the component outline to say "Any system >> provisioned from this outline should consume from this subscription". >> This is better for the case where you create the system record first, >> and then provision it. >> >> Or, we could put them on the activation key which would say "When you >> register this machine with this key, you get this subscription". This is >> better when you provision outside of katello and then register the >> machine back. >> >> Or, we could put them on both, and have some logic about how to handle >> the case when it is on both. Or, perhaps, every component outline gets >> an activation key? > > The last - every component outline gets an activation key > > - even if it is by default due to some global activationkey used, when > no others is specified. > with this case, only the activation keys carry subscriptions. I have 2 votes for that. Anyone disagree? -- bk From hbrock at redhat.com Mon Jul 16 13:43:15 2012 From: hbrock at redhat.com (Hugh O. Brock) Date: Mon, 16 Jul 2012 09:43:15 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <20120716134315.GJ19456@redhat.com> On Mon, Jul 16, 2012 at 09:28:44AM -0400, Michael Orazi wrote: > > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > From: "Bryan Kearney" > > > To: katello-devel at redhat.com > > > Sent: Monday, July 16, 2012 8:23:25 AM > > > Subject: Re: [katello-devel] where to get required katello gems > > > > > > On 07/16/2012 07:26 AM, Petr Chalupa wrote: > > > > I have a counter proposal which is more from Ruby world then the > > > > solution described in previous emails. > > > > > > > > - remove source > > > > 'http://repos.fedorapeople.org/repos/katello/gems/' > > > > and > > > > other sources from Gemfile > > > > - store all needed gems in vendor/cache as .gem files (directly > > > > in > > > > katello master or a git-submodule) (all versions for f16 and > > > > RHEL) > > > > - install gems with bundle install (without source specified > > > > bundler > > > > picks up gems from vendor/cache) > > > > > > > > Advantages: > > > > - you can install all required gems on any platform: fedora, > > > > ubuntu > > > > or > > > > osx (which I need) > > > > - faster installation > > > > - you can switch between fedora/RHEL env by replacing > > > > Gemfile.lock > > > > (lets > > > > say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our > > > > git > > > > for > > > > this purpose) > > > > - easy access to and updates of gem versions > > > > - you can include gems with CVE patches from fedora, everybody > > > > would > > > > have correct versions of gems (which I currently don't have) > > > > > > > > Disadvantages > > > > - rubygem-* rpms are not being correctly packed. The included > > > > .gem > > > > files > > > > are not containing CVE patches. We would need to come up with a > > > > workaround to build updated .gem files or fix the issue. If this > > > > is > > > > fixed, all you have to do to store gems in vendor/cache is > > > > 'bundle > > > > package' [1]. > > > > - other possible problems i do not see, any ideas? > > > > > > > > [1] http://gembundler.com/bundle_package.html > > > > > > > > What do you think? > > > > > > > > Petr > > > > > > > > > > Could we do this model for DEV, and then work on proper packaging > > > for > > > each distro? I think it would help alot if we could be more > > > friendly > > > to > > > DEVs. > > > > > > -- bk > > > > > > _______________________________________________ > > > katello-devel mailing list > > > katello-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > > I said half jokingly on IRC the other day that we should have a > > 'katello-configure --developer' which would install everything for > > use with a git checkout. This would make it completely simple for > > anyone to get up and going with a dev setup. Perhaps they would just > > point to the git checkout: > > > > % katello-configure --developer /home/dudette/katello > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > There have been some similar discussions on aeolus-devel as well. Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns. > > Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems. John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer. > > Mike Yes. I really, really, really want to get all traces of distro packaging *out* of the Aeolus upstream, which would imply that a. A developer can check out the code base, do $THINGS, and run a dev server, and b. a user can download a tarball, do $THINGS, and launch a functioning instance, regardless of which platform they're on (as long as the platform has a functioning Ruby environment, so Windows is maybe out but who really cares). I'm more than happy to give John and Jay extra time to get this right, if somebody on the Katello team wants to help that would be awesome. Take care, --Hugh -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From bkearney at redhat.com Mon Jul 16 13:51:38 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 16 Jul 2012 09:51:38 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120716134315.GJ19456@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716134315.GJ19456@redhat.com> Message-ID: <50041C6A.5040703@redhat.com> On 07/16/2012 09:43 AM, Hugh O. Brock wrote: > On Mon, Jul 16, 2012 at 09:28:44AM -0400, Michael Orazi wrote: >> >> >> ----- Original Message ----- >>> >>> >>> ----- Original Message ----- >>>> From: "Bryan Kearney" >>>> To: katello-devel at redhat.com >>>> Sent: Monday, July 16, 2012 8:23:25 AM >>>> Subject: Re: [katello-devel] where to get required katello gems >>>> >>>> On 07/16/2012 07:26 AM, Petr Chalupa wrote: >>>>> I have a counter proposal which is more from Ruby world then the >>>>> solution described in previous emails. >>>>> >>>>> - remove source >>>>> 'http://repos.fedorapeople.org/repos/katello/gems/' >>>>> and >>>>> other sources from Gemfile >>>>> - store all needed gems in vendor/cache as .gem files (directly >>>>> in >>>>> katello master or a git-submodule) (all versions for f16 and >>>>> RHEL) >>>>> - install gems with bundle install (without source specified >>>>> bundler >>>>> picks up gems from vendor/cache) >>>>> >>>>> Advantages: >>>>> - you can install all required gems on any platform: fedora, >>>>> ubuntu >>>>> or >>>>> osx (which I need) >>>>> - faster installation >>>>> - you can switch between fedora/RHEL env by replacing >>>>> Gemfile.lock >>>>> (lets >>>>> say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our >>>>> git >>>>> for >>>>> this purpose) >>>>> - easy access to and updates of gem versions >>>>> - you can include gems with CVE patches from fedora, everybody >>>>> would >>>>> have correct versions of gems (which I currently don't have) >>>>> >>>>> Disadvantages >>>>> - rubygem-* rpms are not being correctly packed. The included >>>>> .gem >>>>> files >>>>> are not containing CVE patches. We would need to come up with a >>>>> workaround to build updated .gem files or fix the issue. If this >>>>> is >>>>> fixed, all you have to do to store gems in vendor/cache is >>>>> 'bundle >>>>> package' [1]. >>>>> - other possible problems i do not see, any ideas? >>>>> >>>>> [1] http://gembundler.com/bundle_package.html >>>>> >>>>> What do you think? >>>>> >>>>> Petr >>>>> >>>> >>>> Could we do this model for DEV, and then work on proper packaging >>>> for >>>> each distro? I think it would help alot if we could be more >>>> friendly >>>> to >>>> DEVs. >>>> >>>> -- bk >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> >>> >>> I said half jokingly on IRC the other day that we should have a >>> 'katello-configure --developer' which would install everything for >>> use with a git checkout. This would make it completely simple for >>> anyone to get up and going with a dev setup. Perhaps they would just >>> point to the git checkout: >>> >>> % katello-configure --developer /home/dudette/katello >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> >> There have been some similar discussions on aeolus-devel as well. Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns. >> >> Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems. John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer. >> >> Mike > > Yes. I really, really, really want to get all traces of distro > packaging *out* of the Aeolus upstream, which would imply that a. A > developer can check out the code base, do $THINGS, and run a dev > server, and b. a user can download a tarball, do $THINGS, and launch a > functioning instance, regardless of which platform they're on (as long > as the platform has a functioning Ruby environment, so Windows is > maybe out but who really cares). > > I'm more than happy to give John and Jay extra time to get this right, > if somebody on the Katello team wants to help that would be awesome. > > Take care, > --Hugh > I agree in principal, with the exception of the back end engines (Pulp, Candlepin etc). They wil need to be installed $SOMEHOW. But, I do like the idea of the rails app being (in DEV mode) as DISTRO neutral as possible. -- bk From lzap at redhat.com Mon Jul 16 14:23:59 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 16 Jul 2012 16:23:59 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <20120716142359.GJ4145@lzapx.brq.redhat.com> The issue is not about how to work with bundler. If we package all the build deps as RPMs, we dont need bundler anymore. So installing development setup would be just like installing one metapackage via yum. That's it. And we are not far from that! Rubygems in Red Hat's world are evil. Just like JAR files. Our customer do deliver using RPMs. We should do the same. I can understand it is very comfortable to have ability to run rvm or bunlder, but this is fight that every developer must do its own. Especially those with MacOS ;-) My point is - instead of providing rubygem repos or fighting with bundler configurations, let's just package devel only dependencies as RPMs so devs can install them just like any other software they use. And then handle bunlder the usual way (deleting lock file, generating lock file in RPM post trans script, every team has its own way). Bundler is something we don't need. Actually, it's an obstacle we should rather get rid of. JBoss folks could tell stories (Maven)... LZ On Mon, Jul 16, 2012 at 09:28:44AM -0400, Michael Orazi wrote: > > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > From: "Bryan Kearney" > > > To: katello-devel at redhat.com > > > Sent: Monday, July 16, 2012 8:23:25 AM > > > Subject: Re: [katello-devel] where to get required katello gems > > > > > > On 07/16/2012 07:26 AM, Petr Chalupa wrote: > > > > I have a counter proposal which is more from Ruby world then the > > > > solution described in previous emails. > > > > > > > > - remove source > > > > 'http://repos.fedorapeople.org/repos/katello/gems/' > > > > and > > > > other sources from Gemfile > > > > - store all needed gems in vendor/cache as .gem files (directly > > > > in > > > > katello master or a git-submodule) (all versions for f16 and > > > > RHEL) > > > > - install gems with bundle install (without source specified > > > > bundler > > > > picks up gems from vendor/cache) > > > > > > > > Advantages: > > > > - you can install all required gems on any platform: fedora, > > > > ubuntu > > > > or > > > > osx (which I need) > > > > - faster installation > > > > - you can switch between fedora/RHEL env by replacing > > > > Gemfile.lock > > > > (lets > > > > say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our > > > > git > > > > for > > > > this purpose) > > > > - easy access to and updates of gem versions > > > > - you can include gems with CVE patches from fedora, everybody > > > > would > > > > have correct versions of gems (which I currently don't have) > > > > > > > > Disadvantages > > > > - rubygem-* rpms are not being correctly packed. The included > > > > .gem > > > > files > > > > are not containing CVE patches. We would need to come up with a > > > > workaround to build updated .gem files or fix the issue. If this > > > > is > > > > fixed, all you have to do to store gems in vendor/cache is > > > > 'bundle > > > > package' [1]. > > > > - other possible problems i do not see, any ideas? > > > > > > > > [1] http://gembundler.com/bundle_package.html > > > > > > > > What do you think? > > > > > > > > Petr > > > > > > > > > > Could we do this model for DEV, and then work on proper packaging > > > for > > > each distro? I think it would help alot if we could be more > > > friendly > > > to > > > DEVs. > > > > > > -- bk > > > > > > _______________________________________________ > > > katello-devel mailing list > > > katello-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > > I said half jokingly on IRC the other day that we should have a > > 'katello-configure --developer' which would install everything for > > use with a git checkout. This would make it completely simple for > > anyone to get up and going with a dev setup. Perhaps they would just > > point to the git checkout: > > > > % katello-configure --developer /home/dudette/katello > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > There have been some similar discussions on aeolus-devel as well. Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns. > > Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems. John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer. > > Mike > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From mrao at redhat.com Mon Jul 16 14:30:51 2012 From: mrao at redhat.com (Malini Rao) Date: Mon, 16 Jul 2012 10:30:51 -0400 (EDT) Subject: [katello-devel] icon to represent "virtual guest" subscription In-Reply-To: <7e0522ee-62f9-4a73-9965-60df8c209502@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: Tom, Thanks for reaching out to us about this. I take your point about wanting to easily be able to scan for the type of subscription in the left list but as Kyle mentioned, the green/ yellow/ red icons are universally (and specifically in Katello as well) used to represent status of whether something is on/ off or as an indicator of health or activity. So using these icons to represent anything else will shake the common expectation and also be inconsistent with other areas within the tool. Specifically in this case, the use of these icons is even more dangerous because it is not a stretch to associate these icons with subscription status and so these can easily be misunderstood. The effectiveness of visual indicators in terms of communication and scan-ability in a list is inversely proportional to how many indicators exist per item. Additionally, if we start introducing icons for types of subscriptions here, then we need to do that consistently everywhere else for all other objects and sometimes it is very hard to come up with visually meaningful icons that represent subtle variations of different objects that may be pretty abstract to begin with. At this point, icons will become nothing but visual noise. That said, I still think your core requirement is valid and it can be addressed in other ways - For e.g, we can have list display filters to see only one or more type of subscription. This can scale for more types and be applied across many scenarios consistently and become a list feature. The filters could also be a mix of attributes - so for instance, I should be able to see all subscriptions created through consumption in a particular status ( Nice to have).We should also include the type as an attribute that displays on the rows on the left list for sure. Thoughts? -Malini ----- Original Message ----- From: "Tom McKay" To: "Kyle Baker" Cc: katello-devel at redhat.com, "Matt Reid" , "Malini Rao" Sent: Monday, July 16, 2012 9:37:15 AM Subject: Re: icon to represent "virtual guest" subscription ----- Original Message ----- > From: "Kyle Baker" > To: "Tom McKay" > Cc: katello-devel at redhat.com, "Matt Reid" , "Malini Rao" > Sent: Monday, July 16, 2012 9:24:06 AM > Subject: Re: icon to represent "virtual guest" subscription > > > > ----- Original Message ----- > > UXers, > > > > I am currently using Green icons for subscriptions with Yellow > > icons > > for those created through consumption of a subscription (ie. > > "virtual guest" subscription). A third possible member of the list, > > though it is not currently shown, is custom product subscriptions. > > > > If you have better icons for these cases, let me know. > > I think we need to evaluate whether or not we need icons at all. The > green, yellow, and red icons traditionally show status and that is > how they are used on the Systems screen. Though what you are > describing are icons that represent the types of subscriptions. Are > these all of the current subscription types? - > Current Subscription > Subscription created though consumption > Custom Product Subscription > > Do we foresee more types of subscriptions in the future? Is it also > important to show the status of a subscription (expired, not > expired) in icon form? > > > > I am in favor of keeping some colored icon indicator as to the type of subscription. It makes it very easy to scan the list. (In fact, having more colored aspects of the left list in various places should be considered, imo.) I don't know if there are more subscription categories other than those three, but I'd not rule it out completely. From thomasmckay at redhat.com Mon Jul 16 14:43:47 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 16 Jul 2012 10:43:47 -0400 (EDT) Subject: [katello-devel] icon to represent "virtual guest" subscription In-Reply-To: Message-ID: <528195ae-104f-482d-80b2-9a66b238db73@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Malini Rao" > To: "Tom McKay" > Cc: katello-devel at redhat.com, "Matt Reid" , "Kyle Baker" > Sent: Monday, July 16, 2012 10:30:51 AM > Subject: Re: icon to represent "virtual guest" subscription > > Tom, > > Thanks for reaching out to us about this. I take your point about > wanting to easily be able to scan for the type of subscription in > the left list but as Kyle mentioned, the green/ yellow/ red icons > are universally (and specifically in Katello as well) used to > represent status of whether something is on/ off or as an indicator > of health or activity. So using these icons to represent anything > else will shake the common expectation and also be inconsistent with > other areas within the tool. Specifically in this case, the use of > these icons is even more dangerous because it is not a stretch to > associate these icons with subscription status and so these can > easily be misunderstood. > > The effectiveness of visual indicators in terms of communication and > scan-ability in a list is inversely proportional to how many > indicators exist per item. Additionally, if we start introducing > icons for types of subscriptions here, then we need to do that > consistently everywhere else for all other objects and sometimes it > is very hard to come up with visually meaningful icons that > represent subtle variations of different objects that may be pretty > abstract to begin with. At this point, icons will become nothing but > visual noise. > > That said, I still think your core requirement is valid and it can be > addressed in other ways - For e.g, we can have list display filters > to see only one or more type of subscription. This can scale for > more types and be applied across many scenarios consistently and > become a list feature. The filters could also be a mix of attributes > - so for instance, I should be able to see all subscriptions created > through consumption in a particular status ( Nice to have).We should > also include the type as an attribute that displays on the rows on > the left list for sure. > > Thoughts? > > -Malini > > > The filtering already works as part of the left list. All I'm asking for is some icons to represent two (possibly three) different types of subscriptions. Can you just whip up a couple of icons? Square ones or something different than the round ones. If this is too much, I will do it. I figured you UX folk would be able to do it more quickly than I. > > > ----- Original Message ----- > From: "Tom McKay" > To: "Kyle Baker" > Cc: katello-devel at redhat.com, "Matt Reid" , "Malini > Rao" > Sent: Monday, July 16, 2012 9:37:15 AM > Subject: Re: icon to represent "virtual guest" subscription > > > > ----- Original Message ----- > > From: "Kyle Baker" > > To: "Tom McKay" > > Cc: katello-devel at redhat.com, "Matt Reid" , > > "Malini Rao" > > Sent: Monday, July 16, 2012 9:24:06 AM > > Subject: Re: icon to represent "virtual guest" subscription > > > > > > > > ----- Original Message ----- > > > UXers, > > > > > > I am currently using Green icons for subscriptions with Yellow > > > icons > > > for those created through consumption of a subscription (ie. > > > "virtual guest" subscription). A third possible member of the > > > list, > > > though it is not currently shown, is custom product > > > subscriptions. > > > > > > If you have better icons for these cases, let me know. > > > > I think we need to evaluate whether or not we need icons at all. > > The > > green, yellow, and red icons traditionally show status and that is > > how they are used on the Systems screen. Though what you are > > describing are icons that represent the types of subscriptions. Are > > these all of the current subscription types? - > > Current Subscription > > Subscription created though consumption > > Custom Product Subscription > > > > Do we foresee more types of subscriptions in the future? Is it also > > important to show the status of a subscription (expired, not > > expired) in icon form? > > > > > > > > > I am in favor of keeping some colored icon indicator as to the type > of subscription. It makes it very easy to scan the list. (In fact, > having more colored aspects of the left list in various places > should be considered, imo.) > > I don't know if there are more subscription categories other than > those three, but I'd not rule it out completely. > > From pchalupa at redhat.com Mon Jul 16 15:57:04 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Mon, 16 Jul 2012 17:57:04 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120716142359.GJ4145@lzapx.brq.redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> Message-ID: <500439D0.3050704@redhat.com> I am the osx user so I have to speak out ;) I think this is not just my issue. Not everybody is running on fedora, this affects all debian-based distributions as well. I think it should be solved satisfactory not to discourage potential contributors. I think they like theirs tweaked machines, they are used to theirs tools and They want to use them as I do. To do so you need run katello app locally against a VM with services (db, pulp, candlepin). I may have a compromise: - If all gems are in rpm repos, with the .gem files actualized. - Then a developer can do 'bundle package' on the VM to get vendor/cache with all needed gems including theirs CVE patches. - Then he can run 'bundle install --locally' on any development machine and he is good to go. We can later decide to add a repo with vendor/cache to make it even easier. To sumarize: I think the main issue for non fedora development machines are not updated .gem files in rubygem rpms. Petr On 16.07.12 16:23, Lukas Zapletal wrote: > The issue is not about how to work with bundler. If we package all the > build deps as RPMs, we dont need bundler anymore. So installing > development setup would be just like installing one metapackage via yum. > That's it. And we are not far from that! > > Rubygems in Red Hat's world are evil. Just like JAR files. Our customer > do deliver using RPMs. We should do the same. I can understand it is > very comfortable to have ability to run rvm or bunlder, but this is > fight that every developer must do its own. Especially those with MacOS > ;-) > > My point is - instead of providing rubygem repos or fighting with > bundler configurations, let's just package devel only dependencies as > RPMs so devs can install them just like any other software they use. And > then handle bunlder the usual way (deleting lock file, generating lock > file in RPM post trans script, every team has its own way). > > Bundler is something we don't need. Actually, it's an obstacle we should > rather get rid of. JBoss folks could tell stories (Maven)... > > LZ > > On Mon, Jul 16, 2012 at 09:28:44AM -0400, Michael Orazi wrote: >> >> >> ----- Original Message ----- >>> >>> >>> ----- Original Message ----- >>>> From: "Bryan Kearney" >>>> To: katello-devel at redhat.com >>>> Sent: Monday, July 16, 2012 8:23:25 AM >>>> Subject: Re: [katello-devel] where to get required katello gems >>>> >>>> On 07/16/2012 07:26 AM, Petr Chalupa wrote: >>>>> I have a counter proposal which is more from Ruby world then the >>>>> solution described in previous emails. >>>>> >>>>> - remove source >>>>> 'http://repos.fedorapeople.org/repos/katello/gems/' >>>>> and >>>>> other sources from Gemfile >>>>> - store all needed gems in vendor/cache as .gem files (directly >>>>> in >>>>> katello master or a git-submodule) (all versions for f16 and >>>>> RHEL) >>>>> - install gems with bundle install (without source specified >>>>> bundler >>>>> picks up gems from vendor/cache) >>>>> >>>>> Advantages: >>>>> - you can install all required gems on any platform: fedora, >>>>> ubuntu >>>>> or >>>>> osx (which I need) >>>>> - faster installation >>>>> - you can switch between fedora/RHEL env by replacing >>>>> Gemfile.lock >>>>> (lets >>>>> say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our >>>>> git >>>>> for >>>>> this purpose) >>>>> - easy access to and updates of gem versions >>>>> - you can include gems with CVE patches from fedora, everybody >>>>> would >>>>> have correct versions of gems (which I currently don't have) >>>>> >>>>> Disadvantages >>>>> - rubygem-* rpms are not being correctly packed. The included >>>>> .gem >>>>> files >>>>> are not containing CVE patches. We would need to come up with a >>>>> workaround to build updated .gem files or fix the issue. If this >>>>> is >>>>> fixed, all you have to do to store gems in vendor/cache is >>>>> 'bundle >>>>> package' [1]. >>>>> - other possible problems i do not see, any ideas? >>>>> >>>>> [1] http://gembundler.com/bundle_package.html >>>>> >>>>> What do you think? >>>>> >>>>> Petr >>>>> >>>> >>>> Could we do this model for DEV, and then work on proper packaging >>>> for >>>> each distro? I think it would help alot if we could be more >>>> friendly >>>> to >>>> DEVs. >>>> >>>> -- bk >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> >>> >>> I said half jokingly on IRC the other day that we should have a >>> 'katello-configure --developer' which would install everything for >>> use with a git checkout. This would make it completely simple for >>> anyone to get up and going with a dev setup. Perhaps they would just >>> point to the git checkout: >>> >>> % katello-configure --developer /home/dudette/katello >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> >> There have been some similar discussions on aeolus-devel as well. Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns. >> >> Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems. John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer. >> >> Mike >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > From mmccune at redhat.com Mon Jul 16 16:42:36 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 16 Jul 2012 09:42:36 -0700 Subject: [katello-devel] where to get required katello gems In-Reply-To: <50041C6A.5040703@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716134315.GJ19456@redhat.com> <50041C6A.5040703@redhat.com> Message-ID: <5004447C.8080501@redhat.com> On 07/16/2012 06:51 AM, Bryan Kearney wrote: > On 07/16/2012 09:43 AM, Hugh O. Brock wrote: >> On Mon, Jul 16, 2012 at 09:28:44AM -0400, Michael Orazi wrote: >>> >>> >>> ----- Original Message ----- >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Bryan Kearney" >>>>> To: katello-devel at redhat.com >>>>> Sent: Monday, July 16, 2012 8:23:25 AM >>>>> Subject: Re: [katello-devel] where to get required katello gems >>>>> >>>>> On 07/16/2012 07:26 AM, Petr Chalupa wrote: >>>>>> I have a counter proposal which is more from Ruby world then the >>>>>> solution described in previous emails. >>>>>> >>>>>> - remove source >>>>>> 'http://repos.fedorapeople.org/repos/katello/gems/' >>>>>> and >>>>>> other sources from Gemfile >>>>>> - store all needed gems in vendor/cache as .gem files (directly >>>>>> in >>>>>> katello master or a git-submodule) (all versions for f16 and >>>>>> RHEL) >>>>>> - install gems with bundle install (without source specified >>>>>> bundler >>>>>> picks up gems from vendor/cache) >>>>>> >>>>>> Advantages: >>>>>> - you can install all required gems on any platform: fedora, >>>>>> ubuntu >>>>>> or >>>>>> osx (which I need) >>>>>> - faster installation >>>>>> - you can switch between fedora/RHEL env by replacing >>>>>> Gemfile.lock >>>>>> (lets >>>>>> say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our >>>>>> git >>>>>> for >>>>>> this purpose) >>>>>> - easy access to and updates of gem versions >>>>>> - you can include gems with CVE patches from fedora, everybody >>>>>> would >>>>>> have correct versions of gems (which I currently don't have) >>>>>> >>>>>> Disadvantages >>>>>> - rubygem-* rpms are not being correctly packed. The included >>>>>> .gem >>>>>> files >>>>>> are not containing CVE patches. We would need to come up with a >>>>>> workaround to build updated .gem files or fix the issue. If this >>>>>> is >>>>>> fixed, all you have to do to store gems in vendor/cache is >>>>>> 'bundle >>>>>> package' [1]. >>>>>> - other possible problems i do not see, any ideas? >>>>>> >>>>>> [1] http://gembundler.com/bundle_package.html >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Petr >>>>>> >>>>> >>>>> Could we do this model for DEV, and then work on proper packaging >>>>> for >>>>> each distro? I think it would help alot if we could be more >>>>> friendly >>>>> to >>>>> DEVs. >>>>> >>>>> -- bk >>>>> >>>>> _______________________________________________ >>>>> katello-devel mailing list >>>>> katello-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>> >>>> >>>> I said half jokingly on IRC the other day that we should have a >>>> 'katello-configure --developer' which would install everything for >>>> use with a git checkout. This would make it completely simple for >>>> anyone to get up and going with a dev setup. Perhaps they would just >>>> point to the git checkout: >>>> >>>> % katello-configure --developer /home/dudette/katello >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> >>> >>> There have been some similar discussions on aeolus-devel as well. Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns. >>> >>> Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems. John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer. >>> >>> Mike >> >> Yes. I really, really, really want to get all traces of distro >> packaging *out* of the Aeolus upstream, which would imply that a. A >> developer can check out the code base, do $THINGS, and run a dev >> server, and b. a user can download a tarball, do $THINGS, and launch a >> functioning instance, regardless of which platform they're on (as long >> as the platform has a functioning Ruby environment, so Windows is >> maybe out but who really cares). >> >> I'm more than happy to give John and Jay extra time to get this right, >> if somebody on the Katello team wants to help that would be awesome. >> >> Take care, >> --Hugh >> > I agree in principal, with the exception of the back end engines (Pulp, > Candlepin etc). They wil need to be installed $SOMEHOW. But, I do like > the idea of the rails app being (in DEV mode) as DISTRO neutral as possible. we can always point at a different host. If you don't want to run candlepin and pulp on your dev box, run them somewhere else. Back in the beginning a few devs worked this way. $ katello-configure --development /home/blah/devel/katello --candlepinhost=somecandlepinhost.example.com --pulphost=pulphost.example.com Mike From mmccune at redhat.com Mon Jul 16 16:48:27 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 16 Jul 2012 09:48:27 -0700 Subject: [katello-devel] Fedora 17 status In-Reply-To: <2f523436-2ec9-41f9-8c4b-275763053422@zmail02.collab.prod.int.phx2.redhat.com> References: <2f523436-2ec9-41f9-8c4b-275763053422@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <500445DB.3080100@redhat.com> On 07/16/2012 06:38 AM, Adam Price wrote: > ----- Original Message ----- >> From: "Lukas Zapletal" >> To: katello-devel at redhat.com >> Sent: Monday, July 16, 2012 4:32:03 AM >> Subject: [katello-devel] Fedora 17 status >> >> Guys, >> >> how far are we with Fedora 17 support? Lot's of things got changed >> (Ruby >> 1.9 etc). Is there anyone running Katello on F17? >> >> LZ > > i managed to get through the install process fine until I came to installing Katello itself. I could not get Katello installed via yum due to dependency issues. Most of the gems in katello where requiring Ruby 1.8 while 1.9 is what's available for f17. I couldn't figure out how to get yum to force install it anyways. > we were kind of waiting on the koji setup to at least get the RPMs built and available so we could start seeing what kind of runtime issues we ran into. Should we attack this from a different angle? Mike From mmccune at redhat.com Mon Jul 16 16:49:33 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 16 Jul 2012 09:49:33 -0700 Subject: [katello-devel] Where should subscriptions be? In-Reply-To: <4FFEDF94.5090808@redhat.com> References: <4FFEDF94.5090808@redhat.com> Message-ID: <5004461D.1030809@redhat.com> On 07/12/2012 07:30 AM, Bryan Kearney wrote: > Questions from some design sessions on Foreman integration. Where should > we tie subscriptions to? > > We could put them onto the the component outline to say "Any system > provisioned from this outline should consume from this subscription". > This is better for the case where you create the system record first, > and then provision it. > > Or, we could put them on the activation key which would say "When you > register this machine with this key, you get this subscription". This is > better when you provision outside of katello and then register the > machine back. +1 I know this is how it is done in Satellite and I don't want to blindly just do it like we did before but it worked well to have one central concept that tied a subscription to a registration point. > > Or, we could put them on both, and have some logic about how to handle > the case when it is on both. Or, perhaps, every component outline gets > an activation key? > just have every component outline have an activation key. Let the akeys be the central location for quickly assigning a subscription to a system. You can use them outside a system template or embed them. Mike From bkearney at redhat.com Mon Jul 16 16:54:44 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 16 Jul 2012 12:54:44 -0400 Subject: [katello-devel] Where should subscriptions be? In-Reply-To: <5004461D.1030809@redhat.com> References: <4FFEDF94.5090808@redhat.com> <5004461D.1030809@redhat.com> Message-ID: <50044754.1030708@redhat.com> On 07/16/2012 12:49 PM, Mike McCune wrote: > On 07/12/2012 07:30 AM, Bryan Kearney wrote: >> Questions from some design sessions on Foreman integration. Where should >> we tie subscriptions to? >> >> We could put them onto the the component outline to say "Any system >> provisioned from this outline should consume from this subscription". >> This is better for the case where you create the system record first, >> and then provision it. >> >> Or, we could put them on the activation key which would say "When you >> register this machine with this key, you get this subscription". This is >> better when you provision outside of katello and then register the >> machine back. > > +1 > > I know this is how it is done in Satellite and I don't want to blindly > just do it like we did before but it worked well to have one central > concept that tied a subscription to a registration point. > > >> >> Or, we could put them on both, and have some logic about how to handle >> the case when it is on both. Or, perhaps, every component outline gets >> an activation key? >> > > just have every component outline have an activation key. Let the akeys > be the central location for quickly assigning a subscription to a > system. You can use them outside a system template or embed them. I am fine with the model now being "Subscriptions are on keys, not on CO". when to auto-create keys can be a different story.. but I like that model. -- bk From inecas at redhat.com Mon Jul 16 16:57:08 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 16 Jul 2012 18:57:08 +0200 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <500440E6.5060707@redhat.com> References: <500440E6.5060707@redhat.com> Message-ID: <500447E4.1030509@redhat.com> With funzo, we're trying to figure out how the Aeolus + Katello could better integrate together. The templates in Katello are going to be replaced with component outlines. In discussion about Foreman integration, it was not mentioned, that the Compontent Outline will contain the list of packages (System Template like we know it today has it). This is not required by Foreman (Foreman solves it with Puppet), but Aeolus is able to take the list of packages and install it into the built image, if I understand it correctly. Was it meant to be this way, or we just skipped it when talking about Foreman. It seems quite valuable Aeolus feature to me. Another thing to solve is how to call back to Katello after the instance was deployed by Aeolus (if we're not satisfied with the current status of setting the script manually in deployable, which I guess we're not). It seems for now that Audrey is the only way how to run some scripts after the image was deployed. Will there we some other way for running scripts after deployment in Cloud Engine. If not, it seems that we will need to run Audrey and Puppet side by side. Maybe it's ok, just asking, if its acceptable to have two config servers run against the same machine? Ohad: How does Foreman solve the EC2 deployment against Foreman? -- Ivan From msuchy at redhat.com Mon Jul 16 17:00:31 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Mon, 16 Jul 2012 19:00:31 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <500439D0.3050704@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> Message-ID: <500448AF.1030202@redhat.com> On 16.7.2012 17:57, Petr Chalupa wrote: > Not everybody is running on fedora, this affects all debian-based > distributions as well. How many Debian users we have? Only developers, like to do "make configure && make && make install". All ordinary users like (and admins managing their machines) like good old packages - be it .rpm or .deb. Mirek From inecas at redhat.com Mon Jul 16 17:03:33 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 16 Jul 2012 19:03:33 +0200 Subject: [katello-devel] One component outline - more OSes questions Message-ID: <50044965.5040809@redhat.com> I'm trying to image how a component outline could work with more OSes. And because I like examples, let's try one: 1. Context: a. We have an environment with products Fedora, RHEL and Katello (with repos for both RHEL and Fedora). b. We have a Component Outilne Katello, that could be deployed both on Fedora and RHEL 2. Now I want to provision a system for that component outline in the environment running on RHEL 3. questions? a. Does that mean, that I have to specify what subscription go with what operating system (or determine automagically - it probably could be detected from what the distribution comes from?) b. How to prevent the Katello product to show only available repos for given OS? Or it needs to be a single product for every OS (and potentially arch as well) -- Ivan From msuchy at redhat.com Mon Jul 16 17:03:44 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Mon, 16 Jul 2012 19:03:44 +0200 Subject: [katello-devel] Fedora 17 status In-Reply-To: <2f523436-2ec9-41f9-8c4b-275763053422@zmail02.collab.prod.int.phx2.redhat.com> References: <2f523436-2ec9-41f9-8c4b-275763053422@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <50044970.7030105@redhat.com> On 16.7.2012 15:38, Adam Price wrote: > i managed to get through the install process fine until I came to installing Katello itself. I could not get Katello installed via yum due to dependency issues. Most of the gems in katello where requiring Ruby 1.8 while 1.9 is what's available for f17. I couldn't figure out how to get yum to force install it anyways. Use: http://koji-katello.lab.eng.brq.redhat.com/releases/yum/nightly/Fedora/17/x86_64/ I'm working on F16 and EL6 right now. But you are welcome to test F17. Mirek From calfonso at redhat.com Mon Jul 16 17:04:36 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Mon, 16 Jul 2012 13:04:36 -0400 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <500447E4.1030509@redhat.com> References: <500440E6.5060707@redhat.com> <500447E4.1030509@redhat.com> Message-ID: <20120716170436.GB8398@dhcp-230-220.rdu.redhat.com> On 16/07/12 18:57 +0200, Ivan Ne?as wrote: > >With funzo, we're trying to figure out how the Aeolus + Katello could >better integrate together. > >The templates in Katello are going to be replaced with component outlines. In >discussion about Foreman integration, it was not mentioned, that the >Compontent Outline will contain the list of packages (System Template >like we know it today has it). This is not required by Foreman (Foreman >solves it with Puppet), but Aeolus is able to take the list of >packages and install it into the built image, if I understand it >correctly. Was it meant to be this way, or we just skipped it when >talking about Foreman. It seems quite valuable Aeolus feature to me. > >Another thing to solve is how to call back to Katello after the >instance was deployed by Aeolus (if we're not satisfied with the >current status of setting the script manually in deployable, which I >guess we're not). It seems for now that Audrey is the only way how to >run some scripts after the image was deployed. Will there we some other >way for running scripts after deployment in Cloud Engine. If not, it >seems that we will need to run Audrey and Puppet side by side. Maybe >it's ok, just asking, if its acceptable to have two config servers run >against the same machine? > An alternative the greg blomquist mentioned was to build the image with cloud-init installed and pass in parameters to complete a registration. Doing so would git us the ability to not wire the VM up to a config server. >Ohad: > >How does Foreman solve the EC2 deployment against Foreman? > >-- >Ivan > > > > >_______________________________________________ >katello-devel mailing list >katello-devel at redhat.com >https://www.redhat.com/mailman/listinfo/katello-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From thomasmckay at redhat.com Mon Jul 16 21:19:58 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 16 Jul 2012 17:19:58 -0400 (EDT) Subject: [katello-devel] icon to represent "virtual guest" subscription In-Reply-To: <7e0522ee-62f9-4a73-9965-60df8c209502@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: ----- Original Message ----- > From: "Tom McKay" > To: "Kyle Baker" > Cc: katello-devel at redhat.com, "Matt Reid" , "Malini Rao" > Sent: Monday, July 16, 2012 9:37:15 AM > Subject: Re: icon to represent "virtual guest" subscription > > > > ----- Original Message ----- > > From: "Kyle Baker" > > To: "Tom McKay" > > Cc: katello-devel at redhat.com, "Matt Reid" , > > "Malini Rao" > > Sent: Monday, July 16, 2012 9:24:06 AM > > Subject: Re: icon to represent "virtual guest" subscription > > > > > > > > ----- Original Message ----- > > > UXers, > > > > > > I am currently using Green icons for subscriptions with Yellow > > > icons > > > for those created through consumption of a subscription (ie. > > > "virtual guest" subscription). A third possible member of the > > > list, > > > though it is not currently shown, is custom product > > > subscriptions. > > > > > > If you have better icons for these cases, let me know. > > > > I think we need to evaluate whether or not we need icons at all. > > The > > green, yellow, and red icons traditionally show status and that is > > how they are used on the Systems screen. Though what you are > > describing are icons that represent the types of subscriptions. Are > > these all of the current subscription types? - > > Current Subscription > > Subscription created though consumption > > Custom Product Subscription > > > > Do we foresee more types of subscriptions in the future? Is it also > > important to show the status of a subscription (expired, not > > expired) in icon form? > > > > > > > > > I am in favor of keeping some colored icon indicator as to the type > of subscription. It makes it very easy to scan the list. (In fact, > having more colored aspects of the left list in various places > should be considered, imo.) > > I don't know if there are more subscription categories other than > those three, but I'd not rule it out completely. Another category may be "layered" subscriptions which are meant to be consumed along with other Red Hat products. > > From hbrock at redhat.com Mon Jul 16 22:23:27 2012 From: hbrock at redhat.com (Hugh O. Brock) Date: Mon, 16 Jul 2012 18:23:27 -0400 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <20120716170436.GB8398@dhcp-230-220.rdu.redhat.com> References: <500440E6.5060707@redhat.com> <500447E4.1030509@redhat.com> <20120716170436.GB8398@dhcp-230-220.rdu.redhat.com> Message-ID: <20120716222327.GU19456@redhat.com> On Mon, Jul 16, 2012 at 01:04:36PM -0400, Chris Alfonso wrote: > On 16/07/12 18:57 +0200, Ivan Ne?as wrote: > > > >With funzo, we're trying to figure out how the Aeolus + Katello could > >better integrate together. > > > >The templates in Katello are going to be replaced with component outlines. In > >discussion about Foreman integration, it was not mentioned, that the > >Compontent Outline will contain the list of packages (System Template > >like we know it today has it). This is not required by Foreman (Foreman > >solves it with Puppet), but Aeolus is able to take the list of > >packages and install it into the built image, if I understand it > >correctly. Was it meant to be this way, or we just skipped it when > >talking about Foreman. It seems quite valuable Aeolus feature to me. > > > >Another thing to solve is how to call back to Katello after the > >instance was deployed by Aeolus (if we're not satisfied with the > >current status of setting the script manually in deployable, which I > >guess we're not). It seems for now that Audrey is the only way how to > >run some scripts after the image was deployed. Will there we some other > >way for running scripts after deployment in Cloud Engine. If not, it > >seems that we will need to run Audrey and Puppet side by side. Maybe > >it's ok, just asking, if its acceptable to have two config servers run > >against the same machine? > > > An alternative the greg blomquist mentioned was to build the image with cloud-init installed and pass in parameters to complete a registration. Doing so would git us the ability to not wire the VM up to a config server. > >Ohad: > > > >How does Foreman solve the EC2 deployment against Foreman? > > > >-- > >Ivan > > I love the idea of not *having to have* a config server unless you really need it, for I think obvious reasons... --Hugh -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From hbrock at redhat.com Mon Jul 16 22:43:01 2012 From: hbrock at redhat.com (Hugh O. Brock) Date: Mon, 16 Jul 2012 18:43:01 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <500439D0.3050704@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> Message-ID: <20120716224300.GB19456@redhat.com> On Mon, Jul 16, 2012 at 05:57:04PM +0200, Petr Chalupa wrote: > I am the osx user so I have to speak out ;) > > I think this is not just my issue. Not everybody is running on > fedora, this affects all debian-based distributions as well. I think > it should be solved satisfactory not to discourage potential > contributors. > > I think they like theirs tweaked machines, they are used to theirs > tools and They want to use them as I do. To do so you need run > katello app locally against a VM with services (db, pulp, > candlepin). > > I may have a compromise: > - If all gems are in rpm repos, with the .gem files actualized. > - Then a developer can do 'bundle package' on the VM to get > vendor/cache with all needed gems including theirs CVE patches. > - Then he can run 'bundle install --locally' on any development > machine and he is good to go. > > We can later decide to add a repo with vendor/cache to make it even easier. > > To sumarize: I think the main issue for non fedora development > machines are not updated .gem files in rubygem rpms. > > Petr I've made the mistake before of trying to dictate what happens upstream to the upstream team, so I'm not going to do that this time. :). However, my view, and the view of most of the folks I've talked to on the Aeolus team, is that RPM packaging and installing from RPM or using any other distro tools is an unnatural act for a ruby developer and that it is (one of the many things) impeding our progress with building an upstream community. Now, it goes without saying that we will need to package our upstreams as RPMs in order to productize. However my personal opinion is that it will be better for our upstream community health, and development time, if we can stop the packaging tail from wagging the software dog and let the upstream be a pure Ruby project. One way we could minimize the inevitable package proliferation pain we'll incur by doing this is by pitching in to maintain a shared gem repo across projects. I had even thought about a rubygems.org fork that would provide a bit more of a gate than straight upstream, I don't know what others would think of this. It sounds like Petr has suggested something similar above, but I would skip the RPM step even. Anyway, obviously Katello upstream is free to do what it wants, but I believe Aeolus is going to move away from knee-jerk RPM packaging and instead plan to package our upstream releases as tarball + gems + Gemfile, as you would expect a Ruby project to do. Take care, --Hugh > > On 16.07.12 16:23, Lukas Zapletal wrote: > >The issue is not about how to work with bundler. If we package all the > >build deps as RPMs, we dont need bundler anymore. So installing > >development setup would be just like installing one metapackage via yum. > >That's it. And we are not far from that! > > > >Rubygems in Red Hat's world are evil. Just like JAR files. Our customer > >do deliver using RPMs. We should do the same. I can understand it is > >very comfortable to have ability to run rvm or bunlder, but this is > >fight that every developer must do its own. Especially those with MacOS > >;-) > > > >My point is - instead of providing rubygem repos or fighting with > >bundler configurations, let's just package devel only dependencies as > >RPMs so devs can install them just like any other software they use. And > >then handle bunlder the usual way (deleting lock file, generating lock > >file in RPM post trans script, every team has its own way). > > > >Bundler is something we don't need. Actually, it's an obstacle we should > >rather get rid of. JBoss folks could tell stories (Maven)... > > > >LZ > > > >On Mon, Jul 16, 2012 at 09:28:44AM -0400, Michael Orazi wrote: > >> > >> > >>----- Original Message ----- > >>> > >>> > >>>----- Original Message ----- > >>>>From: "Bryan Kearney" > >>>>To: katello-devel at redhat.com > >>>>Sent: Monday, July 16, 2012 8:23:25 AM > >>>>Subject: Re: [katello-devel] where to get required katello gems > >>>> > >>>>On 07/16/2012 07:26 AM, Petr Chalupa wrote: > >>>>>I have a counter proposal which is more from Ruby world then the > >>>>>solution described in previous emails. > >>>>> > >>>>>- remove source > >>>>>'http://repos.fedorapeople.org/repos/katello/gems/' > >>>>>and > >>>>>other sources from Gemfile > >>>>>- store all needed gems in vendor/cache as .gem files (directly > >>>>>in > >>>>>katello master or a git-submodule) (all versions for f16 and > >>>>>RHEL) > >>>>>- install gems with bundle install (without source specified > >>>>>bundler > >>>>>picks up gems from vendor/cache) > >>>>> > >>>>>Advantages: > >>>>>- you can install all required gems on any platform: fedora, > >>>>>ubuntu > >>>>>or > >>>>>osx (which I need) > >>>>>- faster installation > >>>>>- you can switch between fedora/RHEL env by replacing > >>>>>Gemfile.lock > >>>>>(lets > >>>>>say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our > >>>>>git > >>>>>for > >>>>>this purpose) > >>>>>- easy access to and updates of gem versions > >>>>>- you can include gems with CVE patches from fedora, everybody > >>>>>would > >>>>>have correct versions of gems (which I currently don't have) > >>>>> > >>>>>Disadvantages > >>>>>- rubygem-* rpms are not being correctly packed. The included > >>>>>.gem > >>>>>files > >>>>>are not containing CVE patches. We would need to come up with a > >>>>>workaround to build updated .gem files or fix the issue. If this > >>>>>is > >>>>>fixed, all you have to do to store gems in vendor/cache is > >>>>>'bundle > >>>>>package' [1]. > >>>>>- other possible problems i do not see, any ideas? > >>>>> > >>>>>[1] http://gembundler.com/bundle_package.html > >>>>> > >>>>>What do you think? > >>>>> > >>>>>Petr > >>>>> > >>>> > >>>>Could we do this model for DEV, and then work on proper packaging > >>>>for > >>>>each distro? I think it would help alot if we could be more > >>>>friendly > >>>>to > >>>>DEVs. > >>>> > >>>>-- bk > >>>> > >>>>_______________________________________________ > >>>>katello-devel mailing list > >>>>katello-devel at redhat.com > >>>>https://www.redhat.com/mailman/listinfo/katello-devel > >>>> > >>> > >>>I said half jokingly on IRC the other day that we should have a > >>>'katello-configure --developer' which would install everything for > >>>use with a git checkout. This would make it completely simple for > >>>anyone to get up and going with a dev setup. Perhaps they would just > >>>point to the git checkout: > >>> > >>>% katello-configure --developer /home/dudette/katello > >>> > >>>_______________________________________________ > >>>katello-devel mailing list > >>>katello-devel at redhat.com > >>>https://www.redhat.com/mailman/listinfo/katello-devel > >>> > >> > >>There have been some similar discussions on aeolus-devel as well. Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns. > >> > >>Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems. John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer. > >> > >>Mike > >> > >>_______________________________________________ > >>katello-devel mailing list > >>katello-devel at redhat.com > >>https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From hbrock at redhat.com Mon Jul 16 22:57:12 2012 From: hbrock at redhat.com (Hugh O. Brock) Date: Mon, 16 Jul 2012 18:57:12 -0400 Subject: [katello-devel] Fedora 17 status In-Reply-To: <500445DB.3080100@redhat.com> References: <2f523436-2ec9-41f9-8c4b-275763053422@zmail02.collab.prod.int.phx2.redhat.com> <500445DB.3080100@redhat.com> Message-ID: <20120716225712.GF19456@redhat.com> On Mon, Jul 16, 2012 at 09:48:27AM -0700, Mike McCune wrote: > On 07/16/2012 06:38 AM, Adam Price wrote: > >----- Original Message ----- > >>From: "Lukas Zapletal" > >>To: katello-devel at redhat.com > >>Sent: Monday, July 16, 2012 4:32:03 AM > >>Subject: [katello-devel] Fedora 17 status > >> > >>Guys, > >> > >>how far are we with Fedora 17 support? Lot's of things got changed > >>(Ruby > >>1.9 etc). Is there anyone running Katello on F17? > >> > >>LZ > > > >i managed to get through the install process fine until I came to installing Katello itself. I could not get Katello installed via yum due to dependency issues. Most of the gems in katello where requiring Ruby 1.8 while 1.9 is what's available for f17. I couldn't figure out how to get yum to force install it anyways. > > > > we were kind of waiting on the koji setup to at least get the RPMs > built and available so we could start seeing what kind of runtime > issues we ran into. > > Should we attack this from a different angle? > > Mike If you guys need any info on trouble spots to look for on this, ping Mo Morsi (cc-d). He headed up the ruby 1.8-1.9 move for us and it went very smoothly all in all. We are now (almost) running on f17, we're just waiting on some selinux fixes. Take care, --Hugh -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From ohadlevy at redhat.com Tue Jul 17 07:16:52 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Tue, 17 Jul 2012 10:16:52 +0300 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <20120716170436.GB8398@dhcp-230-220.rdu.redhat.com> References: <500440E6.5060707@redhat.com> <500447E4.1030509@redhat.com> <20120716170436.GB8398@dhcp-230-220.rdu.redhat.com> Message-ID: <50051164.3040505@redhat.com> On 07/16/2012 08:04 PM, Chris Alfonso wrote: > > How does Foreman solve the EC2 deployment against Foreman? at the moment, we relay on SSH as a common transport. we could easily add cloud-init support (for those providers that support it) however, there is still the question of deploying certificates and thats why we chose ssh as a first cut (ec2 has a very simple way to inject ssh pki into an instance). Ohad From inecas at redhat.com Tue Jul 17 09:56:09 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 17 Jul 2012 11:56:09 +0200 Subject: [katello-devel] One component outline - more OSes questions In-Reply-To: <50044965.5040809@redhat.com> References: <50044965.5040809@redhat.com> Message-ID: <500536B9.9080202@redhat.com> On 07/16/2012 07:03 PM, Ivan Ne?as wrote: > I'm trying to image how a component outline could work with more OSes. > And because I like examples, let's try one: > > 1. Context: > > a. We have an environment with products Fedora, RHEL and Katello > (with repos for both RHEL and Fedora). > b. We have a Component Outilne Katello, that could be deployed both > on Fedora and RHEL > > 2. Now I want to provision a system for that component outline in the > environment running on RHEL > > 3. questions? > > a. Does that mean, that I have to specify what subscription go with > what operating system (or determine automagically - it probably could > be detected from what the distribution comes from?) > b. How to prevent the Katello product to show only available repos for > given OS? Or it needs to be a single product for every OS (and > potentially arch as well) It seems, it would be worth to make mapping from repositories to Os and architecture and teach Candlepin about it so that it chooses correctly what repositories to display for particular system (given it would known the OS/arch of the system). For Aeolus, it might lead to Component outline, that would support more OSes/architecture and the actual choice would be made at image build time (when the TDL is sent to Oz), but I still need som info from Aeolus team on that, to know if it's possible or not. If not, we would need to specify the Os/arch when generating TDL. And even there, the mapping between Repos and OSes and Archs would be really helpful. -- Ivan > > -- Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From lzap at redhat.com Tue Jul 17 10:57:51 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 17 Jul 2012 12:57:51 +0200 Subject: [katello-devel] Fedora 17 status In-Reply-To: <500445DB.3080100@redhat.com> References: <2f523436-2ec9-41f9-8c4b-275763053422@zmail02.collab.prod.int.phx2.redhat.com> <500445DB.3080100@redhat.com> Message-ID: <20120717105751.GD3003@lzapx.brq.redhat.com> > we were kind of waiting on the koji setup to at least get the RPMs > built and available so we could start seeing what kind of runtime > issues we ran into. > > Should we attack this from a different angle? No, I was just curious. I heard few weeks ago somebody was testing it out, was not sure about results. So let's wait until Mirek gets us F17 builds and then we can find out what's needed to be changed. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Jul 17 11:08:22 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 17 Jul 2012 13:08:22 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <500439D0.3050704@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> Message-ID: <20120717110822.GE3003@lzapx.brq.redhat.com> That is nice you wonder about different platforms, but seriously - if anyone from the community wants to hack with Katello, Fedora/RHEL are the only supported platforms and it is good reason to use them also for development. We will not forbid use of Bundler at all. It can still be used by other devs, but let's not support it. By support, I mean creating dedicated gem repo. It is part of our (old) build process, yes. The reason for that is rather history - we did not have RPMs yet so whole team was using gems. Now this is different, runtime works from RPM and Mirek reports it should not be big issue to package also development RPMs. Then we don't need to create dedicated gem repo. So my suggestion would be to: - package all development gems as RPMs and provide a metapackage - remove source 'http://repos.fedorapeople.org/repos/katello/gems/' from our Gemfile (that's what you recommend basically) - stop providing the gemrepo after koji migration - users are still able to use rubygems via rubygems.org Once we migrate to Fedora 17 and Ruby 1.9, "pure ruby" developers should take care. All changes must be confirmed to be working on both RHEL6 (Ruby 1.8) and Fedora 17 (RHEL7 perhaps - Ruby 1.9). This needs to be done via standard means - e.g. RPM installation, because I am not sure how to do this via rubygems (maintaining multiple lock files = gem hell :-) LZ On Mon, Jul 16, 2012 at 05:57:04PM +0200, Petr Chalupa wrote: > I am the osx user so I have to speak out ;) > > I think this is not just my issue. Not everybody is running on > fedora, this affects all debian-based distributions as well. I think > it should be solved satisfactory not to discourage potential > contributors. > > I think they like theirs tweaked machines, they are used to theirs > tools and They want to use them as I do. To do so you need run > katello app locally against a VM with services (db, pulp, > candlepin). > > I may have a compromise: > - If all gems are in rpm repos, with the .gem files actualized. > - Then a developer can do 'bundle package' on the VM to get > vendor/cache with all needed gems including theirs CVE patches. > - Then he can run 'bundle install --locally' on any development > machine and he is good to go. > > We can later decide to add a repo with vendor/cache to make it even easier. > > To sumarize: I think the main issue for non fedora development > machines are not updated .gem files in rubygem rpms. > > Petr > > On 16.07.12 16:23, Lukas Zapletal wrote: > >The issue is not about how to work with bundler. If we package all the > >build deps as RPMs, we dont need bundler anymore. So installing > >development setup would be just like installing one metapackage via yum. > >That's it. And we are not far from that! > > > >Rubygems in Red Hat's world are evil. Just like JAR files. Our customer > >do deliver using RPMs. We should do the same. I can understand it is > >very comfortable to have ability to run rvm or bunlder, but this is > >fight that every developer must do its own. Especially those with MacOS > >;-) > > > >My point is - instead of providing rubygem repos or fighting with > >bundler configurations, let's just package devel only dependencies as > >RPMs so devs can install them just like any other software they use. And > >then handle bunlder the usual way (deleting lock file, generating lock > >file in RPM post trans script, every team has its own way). > > > >Bundler is something we don't need. Actually, it's an obstacle we should > >rather get rid of. JBoss folks could tell stories (Maven)... > > > >LZ > > > >On Mon, Jul 16, 2012 at 09:28:44AM -0400, Michael Orazi wrote: > >> > >> > >>----- Original Message ----- > >>> > >>> > >>>----- Original Message ----- > >>>>From: "Bryan Kearney" > >>>>To: katello-devel at redhat.com > >>>>Sent: Monday, July 16, 2012 8:23:25 AM > >>>>Subject: Re: [katello-devel] where to get required katello gems > >>>> > >>>>On 07/16/2012 07:26 AM, Petr Chalupa wrote: > >>>>>I have a counter proposal which is more from Ruby world then the > >>>>>solution described in previous emails. > >>>>> > >>>>>- remove source > >>>>>'http://repos.fedorapeople.org/repos/katello/gems/' > >>>>>and > >>>>>other sources from Gemfile > >>>>>- store all needed gems in vendor/cache as .gem files (directly > >>>>>in > >>>>>katello master or a git-submodule) (all versions for f16 and > >>>>>RHEL) > >>>>>- install gems with bundle install (without source specified > >>>>>bundler > >>>>>picks up gems from vendor/cache) > >>>>> > >>>>>Advantages: > >>>>>- you can install all required gems on any platform: fedora, > >>>>>ubuntu > >>>>>or > >>>>>osx (which I need) > >>>>>- faster installation > >>>>>- you can switch between fedora/RHEL env by replacing > >>>>>Gemfile.lock > >>>>>(lets > >>>>>say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our > >>>>>git > >>>>>for > >>>>>this purpose) > >>>>>- easy access to and updates of gem versions > >>>>>- you can include gems with CVE patches from fedora, everybody > >>>>>would > >>>>>have correct versions of gems (which I currently don't have) > >>>>> > >>>>>Disadvantages > >>>>>- rubygem-* rpms are not being correctly packed. The included > >>>>>.gem > >>>>>files > >>>>>are not containing CVE patches. We would need to come up with a > >>>>>workaround to build updated .gem files or fix the issue. If this > >>>>>is > >>>>>fixed, all you have to do to store gems in vendor/cache is > >>>>>'bundle > >>>>>package' [1]. > >>>>>- other possible problems i do not see, any ideas? > >>>>> > >>>>>[1] http://gembundler.com/bundle_package.html > >>>>> > >>>>>What do you think? > >>>>> > >>>>>Petr > >>>>> > >>>> > >>>>Could we do this model for DEV, and then work on proper packaging > >>>>for > >>>>each distro? I think it would help alot if we could be more > >>>>friendly > >>>>to > >>>>DEVs. > >>>> > >>>>-- bk > >>>> > >>>>_______________________________________________ > >>>>katello-devel mailing list > >>>>katello-devel at redhat.com > >>>>https://www.redhat.com/mailman/listinfo/katello-devel > >>>> > >>> > >>>I said half jokingly on IRC the other day that we should have a > >>>'katello-configure --developer' which would install everything for > >>>use with a git checkout. This would make it completely simple for > >>>anyone to get up and going with a dev setup. Perhaps they would just > >>>point to the git checkout: > >>> > >>>% katello-configure --developer /home/dudette/katello > >>> > >>>_______________________________________________ > >>>katello-devel mailing list > >>>katello-devel at redhat.com > >>>https://www.redhat.com/mailman/listinfo/katello-devel > >>> > >> > >>There have been some similar discussions on aeolus-devel as well. Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns. > >> > >>Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems. John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer. > >> > >>Mike > >> > >>_______________________________________________ > >>katello-devel mailing list > >>katello-devel at redhat.com > >>https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Tue Jul 17 11:46:47 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 17 Jul 2012 07:46:47 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <500448AF.1030202@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> <500448AF.1030202@redhat.com> Message-ID: <500550A7.1000406@redhat.com> On 07/16/2012 01:00 PM, Miroslav Suchy wrote: > On 16.7.2012 17:57, Petr Chalupa wrote: >> Not everybody is running on fedora, this affects all debian-based >> distributions as well. > > How many Debian users we have? None, yet. But, if we only deliver via RPM the ability to get some will by close to Italy's score in the finals. > > Only developers, like to do "make configure && make && make install". > All ordinary users like (and admins managing their machines) like good > old packages - be it .rpm or .deb. > Ruby developers, I bet, hvae a different use case. -- bk From bkearney at redhat.com Tue Jul 17 11:48:18 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 17 Jul 2012 07:48:18 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120716224300.GB19456@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> <20120716224300.GB19456@redhat.com> Message-ID: <50055102.7040500@redhat.com> On 07/16/2012 06:43 PM, Hugh O. Brock wrote: > On Mon, Jul 16, 2012 at 05:57:04PM +0200, Petr Chalupa wrote: >> I am the osx user so I have to speak out ;) >> >> I think this is not just my issue. Not everybody is running on >> fedora, this affects all debian-based distributions as well. I think >> it should be solved satisfactory not to discourage potential >> contributors. >> >> I think they like theirs tweaked machines, they are used to theirs >> tools and They want to use them as I do. To do so you need run >> katello app locally against a VM with services (db, pulp, >> candlepin). >> >> I may have a compromise: >> - If all gems are in rpm repos, with the .gem files actualized. >> - Then a developer can do 'bundle package' on the VM to get >> vendor/cache with all needed gems including theirs CVE patches. >> - Then he can run 'bundle install --locally' on any development >> machine and he is good to go. >> >> We can later decide to add a repo with vendor/cache to make it even easier. >> >> To sumarize: I think the main issue for non fedora development >> machines are not updated .gem files in rubygem rpms. >> >> Petr > > I've made the mistake before of trying to dictate what happens > upstream to the upstream team, so I'm not going to do that this > time. :). > > However, my view, and the view of most of the folks I've talked to on > the Aeolus team, is that RPM packaging and installing from RPM or > using any other distro tools is an unnatural act for a ruby > developer and that it is (one of the many things) impeding our > progress with building an upstream community. > > Now, it goes without saying that we will need to package our upstreams > as RPMs in order to productize. However my personal opinion is that it > will be better for our upstream community health, and development > time, if we can stop the packaging tail from wagging the software dog > and let the upstream be a pure Ruby project. > > One way we could minimize the inevitable package proliferation pain > we'll incur by doing this is by pitching in to maintain a shared gem > repo across projects. I had even thought about a rubygems.org fork > that would provide a bit more of a gate than straight upstream, I > don't know what others would think of this. It sounds like Petr has > suggested something similar above, but I would skip the RPM step > even. Could we use a pulp instance to handle gems, and have it mirror the rubygems url? > > Anyway, obviously Katello upstream is free to do what it wants, but I > believe Aeolus is going to move away from knee-jerk RPM packaging and > instead plan to package our upstream releases as tarball + gems + > Gemfile, as you would expect a Ruby project to do. What about the backend engines, Image Factory et al? - bk From bkearney at redhat.com Tue Jul 17 11:50:24 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 17 Jul 2012 07:50:24 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120717110822.GE3003@lzapx.brq.redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> <20120717110822.GE3003@lzapx.brq.redhat.com> Message-ID: <50055180.3090102@redhat.com> On 07/17/2012 07:08 AM, Lukas Zapletal wrote: > That is nice you wonder about different platforms, but seriously - if > anyone from the community wants to hack with Katello, Fedora/RHEL are > the only supported platforms and it is good reason to use them also for > development. > > We will not forbid use of Bundler at all. It can still be used by other > devs, but let's not support it. By support, I mean creating dedicated > gem repo. It is part of our (old) build process, yes. The reason for > that is rather history - we did not have RPMs yet so whole team was > using gems. > > Now this is different, runtime works from RPM and Mirek reports it > should not be big issue to package also development RPMs. Then we don't > need to create dedicated gem repo. So my suggestion would be to: > > - package all development gems as RPMs and provide a metapackage > - remove source 'http://repos.fedorapeople.org/repos/katello/gems/' from > our Gemfile (that's what you recommend basically) > - stop providing the gemrepo after koji migration > - users are still able to use rubygems via rubygems.org > > Once we migrate to Fedora 17 and Ruby 1.9, "pure ruby" developers should > take care. All changes must be confirmed to be working on both RHEL6 > (Ruby 1.8) and Fedora 17 (RHEL7 perhaps - Ruby 1.9). This needs to be > done via standard means - e.g. RPM installation, because I am not sure > how to do this via rubygems (maintaining multiple lock files = gem hell > :-) > > LZ > TBH.. I am fine with a "get what we have working" approache. But, I think we will quickly (read this year) need to get non rpm distributions out there. -- bk From bkearney at redhat.com Tue Jul 17 11:54:29 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 17 Jul 2012 07:54:29 -0400 Subject: [katello-devel] One component outline - more OSes questions In-Reply-To: <500536B9.9080202@redhat.com> References: <50044965.5040809@redhat.com> <500536B9.9080202@redhat.com> Message-ID: <50055275.4050304@redhat.com> On 07/17/2012 05:56 AM, Ivan Ne?as wrote: > On 07/16/2012 07:03 PM, Ivan Ne?as wrote: >> I'm trying to image how a component outline could work with more OSes. >> And because I like examples, let's try one: >> >> 1. Context: >> >> a. We have an environment with products Fedora, RHEL and Katello >> (with repos for both RHEL and Fedora). >> b. We have a Component Outilne Katello, that could be deployed both >> on Fedora and RHEL >> >> 2. Now I want to provision a system for that component outline in the >> environment running on RHEL >> >> 3. questions? >> >> a. Does that mean, that I have to specify what subscription go with >> what operating system (or determine automagically - it probably could >> be detected from what the distribution comes from?) >> b. How to prevent the Katello product to show only available repos for >> given OS? Or it needs to be a single product for every OS (and >> potentially arch as well) > It seems, it would be worth to make mapping from repositories to Os and > architecture and teach Candlepin about it so that it chooses correctly > what repositories to display for particular system (given it would known > the OS/arch of the system). > > For Aeolus, it might lead to Component outline, that would support more > OSes/architecture and the actual choice would be made at image build > time (when the TDL is sent to Oz), but I still need som info from Aeolus > team on that, to know if it's possible or not. If not, we would need to > specify the Os/arch when generating TDL. And even there, the mapping > between Repos and OSes and Archs would be really helpful. In you contenxt, you may have puppet recipies which say "install apache" and that recipie may work across all oses. So, when you declare a system, you could select an OS and it would "just work". This is why folks have been saying that subscriptions should be tied to activation keys. I may create a key which is "Katello + Red Hat Subscriptions" and one which is "Katello + Fedora Subscriptions". For integration with Aeolus, I think we need the equivilant of a system record. Lets call it an Image record. I select a CO, and an OS, and I say "THis is an image". Any API between the two systems can now talk in terms of image records. -- bk From bkearney at redhat.com Tue Jul 17 12:11:22 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 17 Jul 2012 08:11:22 -0400 Subject: [katello-devel] Can we move the API doc to master Message-ID: <5005566A.905@redhat.com> Any reason to hold off pushing that to the master branch? I assume more doco is better then less :) -- bk From tstrachota at redhat.com Tue Jul 17 12:20:03 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Tue, 17 Jul 2012 14:20:03 +0200 Subject: [katello-devel] How should we post objects In-Reply-To: <50041941.4070205@redhat.com> References: <4FFEF1F6.9030700@redhat.com> <20120713134649.GB4100@lzapx.brq.redhat.com> <500039CA.20900@redhat.com> <50041941.4070205@redhat.com> Message-ID: <50055873.3090802@redhat.com> On 07/16/2012 03:38 PM, Bryan Kearney wrote: > On 07/13/2012 11:07 AM, Dmitri Dolguikh wrote: >> The difference between creating a new object and updating an existing >> one is (in the context of this discussion) in idempotency: repeated >> calls to create an object may return a new object every time, while >> making the same change over and over again should result in the same >> state of the object. So: POST is for creation, PUT is for updates. >> > > Agree. My main qustion is if I should be opening bugs where the json > which is postd does not have the following: > > object_name: { > attr: "foo" > } > > an instead has: > > { > attr: "foo" > } > > -- bk > I'm for opening bugs in such cases and working towards consistency. As far as I remember from the previous discussion more people seemed to like using {obj_name: {...}} pattern as it had slightly more advantages. T. From inecas at redhat.com Tue Jul 17 12:23:13 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 17 Jul 2012 14:23:13 +0200 Subject: [katello-devel] Can we move the API doc to master In-Reply-To: <5005566A.905@redhat.com> References: <5005566A.905@redhat.com> Message-ID: <50055931.9060602@redhat.com> One particular reason was, that some features of Restapi gem were in our separate branch. Since we've got them to upstream, it should be ready to be built as RPM and merged to master. Another one was an intention to get some review first, but since it seems it takes more time to get there, it seems to be bearable to get it into master and continue with the review there (but still I would like to get into master as correct doc as possible) -- Ivan On 07/17/2012 02:11 PM, Bryan Kearney wrote: > Any reason to hold off pushing that to the master branch? I assume > more doco is better then less :) > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From inecas at redhat.com Tue Jul 17 12:49:31 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 17 Jul 2012 14:49:31 +0200 Subject: [katello-devel] One component outline - more OSes questions In-Reply-To: <50055275.4050304@redhat.com> References: <50044965.5040809@redhat.com> <500536B9.9080202@redhat.com> <50055275.4050304@redhat.com> Message-ID: <50055F5B.40902@redhat.com> On 07/17/2012 01:54 PM, Bryan Kearney wrote: > On 07/17/2012 05:56 AM, Ivan Ne?as wrote: >> On 07/16/2012 07:03 PM, Ivan Ne?as wrote: >>> I'm trying to image how a component outline could work with more OSes. >>> And because I like examples, let's try one: >>> >>> 1. Context: >>> >>> a. We have an environment with products Fedora, RHEL and Katello >>> (with repos for both RHEL and Fedora). >>> b. We have a Component Outilne Katello, that could be deployed both >>> on Fedora and RHEL >>> >>> 2. Now I want to provision a system for that component outline in the >>> environment running on RHEL >>> >>> 3. questions? >>> >>> a. Does that mean, that I have to specify what subscription go with >>> what operating system (or determine automagically - it probably could >>> be detected from what the distribution comes from?) >>> b. How to prevent the Katello product to show only available repos for >>> given OS? Or it needs to be a single product for every OS (and >>> potentially arch as well) >> It seems, it would be worth to make mapping from repositories to Os and >> architecture and teach Candlepin about it so that it chooses correctly >> what repositories to display for particular system (given it would known >> the OS/arch of the system). >> >> For Aeolus, it might lead to Component outline, that would support more >> OSes/architecture and the actual choice would be made at image build >> time (when the TDL is sent to Oz), but I still need som info from Aeolus >> team on that, to know if it's possible or not. If not, we would need to >> specify the Os/arch when generating TDL. And even there, the mapping >> between Repos and OSes and Archs would be really helpful. > > In you contenxt, you may have puppet recipies which say "install > apache" and that recipie may work across all oses. So, when you > declare a system, you could select an OS and it would "just work". > > This is why folks have been saying that subscriptions should be tied > to activation keys. I may create a key which is "Katello + Red Hat > Subscriptions" and one which is "Katello + Fedora Subscriptions". Will it require manual selection of the proper OS? It seems to me that would be quite repetitive task, that wouldn't be needed, if we have the OS-repos mapping. And there is still question for the non-os products (like Katello), where there is one subscription for all the OSes (unless we say, that we need separate product for every OS specific repo, which kind of doesn't go with the rest of our model) > > For integration with Aeolus, I think we need the equivilant of a > system record. Lets call it an Image record. I select a CO, and an OS, > and I say "THis is an image". Any API between the two systems can now > talk in terms of image records. In TDL there can be also another repos (not only from distribution). How to deal with that? I could imagagine, that the repos part of TDL would be structured by operating systems, which would allow to use only subset of the repos when building an image for selected OS. I guess we should get some folks from Aeolus and talk about it together. -- Ivan > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From msuchy at redhat.com Tue Jul 17 14:35:31 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Tue, 17 Jul 2012 16:35:31 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <500550A7.1000406@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> <500448AF.1030202@redhat.com> <500550A7.1000406@redhat.com> Message-ID: <50057833.5090009@redhat.com> On 17.7.2012 13:46, Bryan Kearney wrote: > On 07/16/2012 01:00 PM, Miroslav Suchy wrote: >> On 16.7.2012 17:57, Petr Chalupa wrote: >>> Not everybody is running on fedora, this affects all debian-based >>> distributions as well. >> >> How many Debian users we have? > > None, yet. But, if we only deliver via RPM the ability to get some will > by close to Italy's score in the finals. Well it worked with Spacewalk. And Debian people prefer packages as well. >> >> Only developers, like to do "make configure && make && make install". >> All ordinary users like (and admins managing their machines) like good >> old packages - be it .rpm or .deb. >> > > Ruby developers, I bet, hvae a different use case. Yes, they differ from sysadmins who sometimes verify integrity of their systems using: rpm -V some-rubygem Tell me how you can do that with bundler? How you enforce that some file from gem is not overwrite by some other package or gem? Mirek From bkearney at redhat.com Tue Jul 17 15:57:59 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 17 Jul 2012 11:57:59 -0400 Subject: [katello-devel] Cloud Engine - System Engine V2 integration In-Reply-To: <20120717132923.GH19456@redhat.com> References: <500440E6.5060707@redhat.com> <50051284.1060405@redhat.com> <50055774.7000209@redhat.com> <20120717125704.GA9053@dhcp-230-220.rdu.redhat.com> <20120717132923.GH19456@redhat.com> Message-ID: <50058B87.5050900@redhat.com> On 07/17/2012 09:29 AM, Hugh O. Brock wrote: > On Tue, Jul 17, 2012 at 08:57:04AM -0400, Chris Alfonso wrote: >> On 17/07/12 08:15 -0400, Bryan Kearney wrote: >> --snip-- >>> This data would be in the kickstart tempaltes.. yes? I assume if >>> we go with TDL, we will need a way to translate the ks file which >>> foreman generates into TDL. Or, could we: >>> >>> 1) have an alternate TDL tempalte >>> 2) ditch TDL and have image factory get the kickstart from foreman directly? >>> >> Image Factory hands the TDL off to Oz. Ditching TDL would mean Image Factory ditches Oz, and I think the scope of work would quickly increase. I recommend we do not ditch TDL and instead translate the ks from foreman into a valid TDL. >> https://github.com/clalancette/oz/blob/master/docs/tdl.rng > > Fair enough. I think both BK and I would prefer to de-emphasize TDL as > a first-class citizen -- i.e. something we document and tell people > "you must write your component outlines this way" -- but I see no > reason to rush around and make more work for ourselves by ditching it > in a hurry. Fair enough. If we get an "image record" into katello, we have the API point. From then on, it is just deciding who makes the api call, and if it is push or pull. -- bk From inecas at redhat.com Tue Jul 17 16:05:49 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 17 Jul 2012 18:05:49 +0200 Subject: [katello-devel] Cloud Engine - System Engine V2 integration In-Reply-To: <50058B87.5050900@redhat.com> References: <500440E6.5060707@redhat.com> <50051284.1060405@redhat.com> <50055774.7000209@redhat.com> <20120717125704.GA9053@dhcp-230-220.rdu.redhat.com> <20120717132923.GH19456@redhat.com> <50058B87.5050900@redhat.com> Message-ID: <50058D5D.6070004@redhat.com> On 07/17/2012 05:57 PM, Bryan Kearney wrote: > On 07/17/2012 09:29 AM, Hugh O. Brock wrote: >> On Tue, Jul 17, 2012 at 08:57:04AM -0400, Chris Alfonso wrote: >>> On 17/07/12 08:15 -0400, Bryan Kearney wrote: >>> --snip-- >>>> This data would be in the kickstart tempaltes.. yes? I assume if >>>> we go with TDL, we will need a way to translate the ks file which >>>> foreman generates into TDL. Or, could we: >>>> >>>> 1) have an alternate TDL tempalte >>>> 2) ditch TDL and have image factory get the kickstart from foreman >>>> directly? >>>> >>> Image Factory hands the TDL off to Oz. Ditching TDL would mean Image >>> Factory ditches Oz, and I think the scope of work would quickly >>> increase. I recommend we do not ditch TDL and instead translate the >>> ks from foreman into a valid TDL. >>> https://github.com/clalancette/oz/blob/master/docs/tdl.rng >> >> Fair enough. I think both BK and I would prefer to de-emphasize TDL as >> a first-class citizen -- i.e. something we document and tell people >> "you must write your component outlines this way" -- but I see no >> reason to rush around and make more work for ourselves by ditching it >> in a hurry. > > > Fair enough. If we get an "image record" into katello, we have the API > point. From then on, it is just deciding who makes the api call, and > if it is push or pull. Right. I will try to sum up the things we have discussed into a wiki page to have it on one place. -- Ivan > > -- bk > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From thomasmckay at redhat.com Tue Jul 17 19:31:49 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 17 Jul 2012 15:31:49 -0400 (EDT) Subject: [katello-devel] icon to represent "virtual guest" subscription In-Reply-To: Message-ID: <9e02b23b-71e6-468b-91b8-c9c5420fb4a8@zmail16.collab.prod.int.phx2.redhat.com> UX decided that icons and colors would not work so they'll be removed shortly. If there's room, I will try to include text indicating the subscription type in the left list. Users can use the search filters to limit what is shown, should they desire that. ----- Original Message ----- > From: "Tom McKay" > To: "Kyle Baker" > Cc: "Matt Reid" , katello-devel at redhat.com > Sent: Monday, July 16, 2012 5:19:58 PM > Subject: Re: [katello-devel] icon to represent "virtual guest" subscription > > > > ----- Original Message ----- > > From: "Tom McKay" > > To: "Kyle Baker" > > Cc: katello-devel at redhat.com, "Matt Reid" , > > "Malini Rao" > > Sent: Monday, July 16, 2012 9:37:15 AM > > Subject: Re: icon to represent "virtual guest" subscription > > > > > > > > ----- Original Message ----- > > > From: "Kyle Baker" > > > To: "Tom McKay" > > > Cc: katello-devel at redhat.com, "Matt Reid" , > > > "Malini Rao" > > > Sent: Monday, July 16, 2012 9:24:06 AM > > > Subject: Re: icon to represent "virtual guest" subscription > > > > > > > > > > > > ----- Original Message ----- > > > > UXers, > > > > > > > > I am currently using Green icons for subscriptions with Yellow > > > > icons > > > > for those created through consumption of a subscription (ie. > > > > "virtual guest" subscription). A third possible member of the > > > > list, > > > > though it is not currently shown, is custom product > > > > subscriptions. > > > > > > > > If you have better icons for these cases, let me know. > > > > > > I think we need to evaluate whether or not we need icons at all. > > > The > > > green, yellow, and red icons traditionally show status and that > > > is > > > how they are used on the Systems screen. Though what you are > > > describing are icons that represent the types of subscriptions. > > > Are > > > these all of the current subscription types? - > > > Current Subscription > > > Subscription created though consumption > > > Custom Product Subscription > > > > > > Do we foresee more types of subscriptions in the future? Is it > > > also > > > important to show the status of a subscription (expired, not > > > expired) in icon form? > > > > > > > > > > > > > > I am in favor of keeping some colored icon indicator as to the type > > of subscription. It makes it very easy to scan the list. (In fact, > > having more colored aspects of the left list in various places > > should be considered, imo.) > > > > I don't know if there are more subscription categories other than > > those three, but I'd not rule it out completely. > > Another category may be "layered" subscriptions which are meant to be > consumed along with other Red Hat products. > > > > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From tstrachota at redhat.com Tue Jul 17 22:16:24 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Wed, 18 Jul 2012 00:16:24 +0200 Subject: [katello-devel] On the plane, I tried 2 controllers worth of API changes In-Reply-To: <4FFA8FCF.5040203@redhat.com> References: <4FFA8FCF.5040203@redhat.com> Message-ID: <5005E438.2090904@redhat.com> On 07/09/2012 10:01 AM, Bryan Kearney wrote: > someone should really check the pull request i sent in, since I was not > able to really test. Here were some notes I took while playing with the > code: I went through the code. Most of your notes are obvious bugs but in some cases I'm not sure about the best solution. Ideas from experienced RESTers are more than welcome! > > changesets_content_controller > ============================= > > * entire api controller returns text instead of json. > * passing in a non existent product id still gets you a 200 return code. > (look at render_after_removal) > * Looks like the posts take in query parameters instead of JSON in the > body. Any reason for that? > * For remove_* is seems nasty to have to pass in the product id. Dont we > just know this since it is in the changeset already? I'm not sure if we can get rid of product ids. We add packages, errata, repos and distros from a scope of product. That means we can theoretically have two packages with the same id in a changeset twice, each from a different product. Using id of ChangesetPackage record instead of ids of the packages itself could be a solution here. (the same applies to errata, distros and repos) > * For URLS like this: > > api :DELETE, "/changesets/:changeset_id/templates/:id", " > > why use :changeset_id and then :id (as opposed to template_id" +1 it makes code more readable > > Changeset_controller > ==================== > * Update and create seems to do json, which is good > * is organization_id ever checked? I don't think so. We should shorten the route from POST /organizations/:organization_id/environments/:environment_id/changesets to POST /environments/:environment_id/changesets > * Why is name used in #index > * Promote seems icky. We are POSTING to /promote which is more of an RPC > call. Can we do a POST to another environment instead? Agree. I'm not sure how you meant post to another env though. I'd maybe suggest to create a promotion controller. > * The promotion API automatically moves the changeset to REVIEW. Should > we instead make that a unique call? An unique call would be definitely better. It shouldn't be a big deal to change it. T. From lzap at redhat.com Wed Jul 18 07:49:24 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 Jul 2012 09:49:24 +0200 Subject: [katello-devel] How should we post objects In-Reply-To: <50055873.3090802@redhat.com> References: <4FFEF1F6.9030700@redhat.com> <20120713134649.GB4100@lzapx.brq.redhat.com> <500039CA.20900@redhat.com> <50041941.4070205@redhat.com> <50055873.3090802@redhat.com> Message-ID: <20120718074924.GB5587@lzapx.brq.redhat.com> Uh, I completely missed the doco link: https://fedorahosted.org/katello/wiki/APIConventions Disregard my first mail, we do wrap! I would suggest to generate the final API documentation for CFSE V1 (how close are we?) and then we can start changing it. LZ On Tue, Jul 17, 2012 at 02:20:03PM +0200, Tomas Strachota wrote: > On 07/16/2012 03:38 PM, Bryan Kearney wrote: > >On 07/13/2012 11:07 AM, Dmitri Dolguikh wrote: > >>The difference between creating a new object and updating an existing > >>one is (in the context of this discussion) in idempotency: repeated > >>calls to create an object may return a new object every time, while > >>making the same change over and over again should result in the same > >>state of the object. So: POST is for creation, PUT is for updates. > >> > > > >Agree. My main qustion is if I should be opening bugs where the json > >which is postd does not have the following: > > > >object_name: { > >attr: "foo" > >} > > > >an instead has: > > > >{ > >attr: "foo" > >} > > > >-- bk > > > > I'm for opening bugs in such cases and working towards consistency. > > As far as I remember from the previous discussion more people seemed > to like using {obj_name: {...}} pattern as it had slightly more > advantages. > > T. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Jul 18 08:03:58 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 Jul 2012 10:03:58 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <50055102.7040500@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> <20120716224300.GB19456@redhat.com> <50055102.7040500@redhat.com> Message-ID: <20120718080358.GC5587@lzapx.brq.redhat.com> On Tue, Jul 17, 2012 at 07:48:18AM -0400, Bryan Kearney wrote: > >Anyway, obviously Katello upstream is free to do what it wants, but I > >believe Aeolus is going to move away from knee-jerk RPM packaging and > >instead plan to package our upstream releases as tarball + gems + > >Gemfile, as you would expect a Ruby project to do. > > What about the backend engines, Image Factory et al? Yeah it does not make sense to package development setup as a tarball while there is still big portion of the system that is needed. But I can imagine one can run katello locally while having backend engines on other machine, but for development perhaps. Source tarballs will be released as parts of SRPMs, some teams release them also in plain format, but I don't think this is necessary in our case. Developers are using git and users do not want to run production systems from Gemfile. There's this need of runninig all the backend engines, it does not make sense to me. Let me ask the team - what was to original reason for creating our own gemrepo? I guess we were missing some gems on rubygems.org right? Once we change to koji, do we still need to maintain this repo? Can't we just switch back to rubygems.org so pure ruby developers can still use it? -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Wed Jul 18 08:36:55 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 18 Jul 2012 12:36:55 +0400 Subject: [katello-devel] Fedora 17 status In-Reply-To: <20120716083203.GD4145@lzapx.brq.redhat.com> References: <20120716083203.GD4145@lzapx.brq.redhat.com> Message-ID: <500675A7.7010406@redhat.com> On 16/07/12 12:32 PM, Lukas Zapletal wrote: > Guys, > > how far are we with Fedora 17 support? Lot's of things got changed (Ruby > 1.9 etc). Is there anyone running Katello on F17? > > LZ > I'm running on F17, but under ruby 1.8.7. There are quite a few dependencies that need to be updated for 1.9. Cheers, -d PS> For those of you who don't want to use rvm, there's another project rbenv https://github.com/sstephenson/rbenv/ that is much less invasive. I have fixed a few issues of ruby-build plugin for rbenv that simplifies ruby installation: https://github.com/witlessbird/ruby-build/tree/libc-2.14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lzap at redhat.com Wed Jul 18 08:57:17 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 Jul 2012 10:57:17 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <5004447C.8080501@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716134315.GJ19456@redhat.com> <50041C6A.5040703@redhat.com> <5004447C.8080501@redhat.com> Message-ID: <20120718085717.GD5587@lzapx.brq.redhat.com> On Mon, Jul 16, 2012 at 09:42:36AM -0700, Michael McCune wrote: > we can always point at a different host. If you don't want to run > candlepin and pulp on your dev box, run them somewhere else. Back > in the beginning a few devs worked this way. > > $ katello-configure --development /home/blah/devel/katello > --candlepinhost=somecandlepinhost.example.com > --pulphost=pulphost.example.com If I skip the fact there is no katello-configure on non-RH systems, this can only work for developers. But users who want to run Katello on non-RH systems as a whole? How do they run Pulp? Candlepin? I mean, without having possibility to install backend engines on non-RH systems, this is pretty useless for katello users. We should maybe start with that. Let's get koji done and then we can discuss what to do with gem repos. I think distributing katello with Gemfile is enough for ruby folks to start it up on unsupported platforms. We will check that. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Jul 18 09:35:08 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 Jul 2012 11:35:08 +0200 Subject: [katello-devel] API documentation effort Message-ID: <20120718093508.GE5587@lzapx.brq.redhat.com> Guys, we need some help documenting our API. On the following page https://fedorahosted.org/katello/wiki/APIDocumentationEfforts we have a tutorial how to write some API documentation. We have a branch on github for submitting doco work. Thanks for help -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Wed Jul 18 09:58:57 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 18 Jul 2012 11:58:57 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120718085717.GD5587@lzapx.brq.redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716134315.GJ19456@redhat.com> <50041C6A.5040703@redhat.com> <5004447C.8080501@redhat.com> <20120718085717.GD5587@lzapx.brq.redhat.com> Message-ID: <500688E1.5080401@redhat.com> On 07/18/2012 10:57 AM, Lukas Zapletal wrote: > We should maybe start > with that. +1. If we want to think about non-RH OSes, we should think about client stuff for start. Backend is far far away. -- Miroslav Suchy Red Hat Systems Management Engineering From thomasmckay at redhat.com Wed Jul 18 11:45:17 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 18 Jul 2012 07:45:17 -0400 (EDT) Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120718085717.GD5587@lzapx.brq.redhat.com> Message-ID: <3ee69872-1a1a-4e45-9693-15e4a9f849a7@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, July 18, 2012 4:57:17 AM > Subject: Re: [katello-devel] where to get required katello gems > > On Mon, Jul 16, 2012 at 09:42:36AM -0700, Michael McCune wrote: > > we can always point at a different host. If you don't want to run > > candlepin and pulp on your dev box, run them somewhere else. Back > > in the beginning a few devs worked this way. > > > > $ katello-configure --development /home/blah/devel/katello > > --candlepinhost=somecandlepinhost.example.com > > --pulphost=pulphost.example.com > > If I skip the fact there is no katello-configure on non-RH systems, > this > can only work for developers. But users who want to run Katello on > non-RH systems as a whole? How do they run Pulp? Candlepin? What do you mean there is no katello-configure on non-RH systems? That's a bug if the rpm doesn't lay one down. I'm suggesting that the dev setup should easily be: % yum install -y katello-all % cd ~ % git clone git at github.com:Katello/katello.git % katello-configure --development ~/katello This results in all services running, including pulp and candlepin, from the git checkout. > > I mean, without having possibility to install backend engines on > non-RH > systems, this is pretty useless for katello users. We should maybe > start > with that. > > Let's get koji done and then we can discuss what to do with gem > repos. I > think distributing katello with Gemfile is enough for ruby folks to > start it up on unsupported platforms. We will check that. > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From thomasmckay at redhat.com Wed Jul 18 11:48:50 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 18 Jul 2012 07:48:50 -0400 (EDT) Subject: [katello-devel] API documentation effort In-Reply-To: <20120718093508.GE5587@lzapx.brq.redhat.com> Message-ID: <20f74536-39c7-4b45-b680-84180652337e@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, July 18, 2012 5:35:08 AM > Subject: [katello-devel] API documentation effort > > Guys, > > we need some help documenting our API. On the following page > > https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > > we have a tutorial how to write some API documentation. We have a > branch > on github for submitting doco work. Let's just merge it into master? I'm more inclined just to add stuff incrementally when I'm fixing some code. > > Thanks for help > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From msuchy at redhat.com Wed Jul 18 11:52:44 2012 From: msuchy at redhat.com (=?ISO-8859-2?Q?Miroslav_Such=FD?=) Date: Wed, 18 Jul 2012 13:52:44 +0200 Subject: [katello-devel] why we have /usr/share/katello/script ? Message-ID: <5006A38C.8030908@redhat.com> Is there some history behind having: /usr/share/katello/script and having symlinks from /usr/bin to files in that directory? I'm asking because: # ls -l /usr/bin/katello-debug lrwxrwxrwx. 1 root root 39 Jul 17 16:01 /usr/bin/katello-debug -> /usr/share/katello/script/katello-debug # ls -lZ /usr/share/katello/script/katello-debug -rwxr-xr-x. root root system_u:object_r:usr_t:s0 /usr/share/katello/script/katello-debug And I would have expect that this script would have bin_t instead of usr_t. And I could not imagine what is the advantage of having /usr/share/katello/script/ instead of putting thos file directly into /usr/bin/? -- Miroslav Suchy Red Hat Systems Management Engineering From bkearney at redhat.com Wed Jul 18 11:57:21 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 Jul 2012 07:57:21 -0400 Subject: [katello-devel] why we have /usr/share/katello/script ? In-Reply-To: <5006A38C.8030908@redhat.com> References: <5006A38C.8030908@redhat.com> Message-ID: <5006A4A1.3010303@redhat.com> On 07/18/2012 07:52 AM, Miroslav Such? wrote: > Is there some history behind having: > /usr/share/katello/script > and having symlinks from /usr/bin to files in that directory? > > I'm asking because: > # ls -l /usr/bin/katello-debug > lrwxrwxrwx. 1 root root 39 Jul 17 16:01 /usr/bin/katello-debug -> > /usr/share/katello/script/katello-debug > # ls -lZ /usr/share/katello/script/katello-debug > -rwxr-xr-x. root root system_u:object_r:usr_t:s0 > /usr/share/katello/script/katello-debug > > And I would have expect that this script would have bin_t instead of usr_t. > And I could not imagine what is the advantage of having > /usr/share/katello/script/ instead of putting thos file directly into > /usr/bin/? Only reason I can think of is that is where the rails comand is? But, I dont know off hand. -- bk From bkearney at redhat.com Wed Jul 18 11:57:52 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 Jul 2012 07:57:52 -0400 Subject: [katello-devel] API documentation effort In-Reply-To: <20f74536-39c7-4b45-b680-84180652337e@zmail16.collab.prod.int.phx2.redhat.com> References: <20f74536-39c7-4b45-b680-84180652337e@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <5006A4C0.4070000@redhat.com> On 07/18/2012 07:48 AM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Lukas Zapletal" >> To: katello-devel at redhat.com >> Sent: Wednesday, July 18, 2012 5:35:08 AM >> Subject: [katello-devel] API documentation effort >> >> Guys, >> >> we need some help documenting our API. On the following page >> >> https://fedorahosted.org/katello/wiki/APIDocumentationEfforts >> >> we have a tutorial how to write some API documentation. We have a >> branch >> on github for submitting doco work. > > Let's just merge it into master? I'm more inclined just to add stuff incrementally when I'm fixing some code. +1 -- bk From bkearney at redhat.com Wed Jul 18 11:58:49 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 Jul 2012 07:58:49 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <50057833.5090009@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> <500448AF.1030202@redhat.com> <500550A7.1000406@redhat.com> <50057833.5090009@redhat.com> Message-ID: <5006A4F9.2010000@redhat.com> On 07/17/2012 10:35 AM, Miroslav Suchy wrote: > On 17.7.2012 13:46, Bryan Kearney wrote: >> On 07/16/2012 01:00 PM, Miroslav Suchy wrote: >>> On 16.7.2012 17:57, Petr Chalupa wrote: >>>> Not everybody is running on fedora, this affects all debian-based >>>> distributions as well. >>> >>> How many Debian users we have? >> >> None, yet. But, if we only deliver via RPM the ability to get some will >> by close to Italy's score in the finals. > > Well it worked with Spacewalk. > And Debian people prefer packages as well. > >>> >>> Only developers, like to do "make configure && make && make install". >>> All ordinary users like (and admins managing their machines) like good >>> old packages - be it .rpm or .deb. >>> >> >> Ruby developers, I bet, hvae a different use case. > > Yes, they differ from sysadmins who sometimes verify integrity of their > systems using: > rpm -V some-rubygem > Tell me how you can do that with bundler? > How you enforce that some file from gem is not overwrite by some other > package or gem? > Hee.. this is is a fun one. In general, I agree with the appraoch of "lets get fedora, RHEL working great from RPM. Then, we can reach out to other distros" -- bk From lzap at redhat.com Wed Jul 18 12:10:29 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 Jul 2012 14:10:29 +0200 Subject: [katello-devel] where to get required katello gems In-Reply-To: <3ee69872-1a1a-4e45-9693-15e4a9f849a7@zmail16.collab.prod.int.phx2.redhat.com> References: <20120718085717.GD5587@lzapx.brq.redhat.com> <3ee69872-1a1a-4e45-9693-15e4a9f849a7@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <20120718121028.GF5587@lzapx.brq.redhat.com> On Wed, Jul 18, 2012 at 07:45:17AM -0400, Tom McKay wrote: > What do you mean there is no katello-configure on non-RH systems? That's a bug if the rpm doesn't lay one down. > > I'm suggesting that the dev setup should easily be: > > % yum install -y katello-all > % cd ~ > % git clone git at github.com:Katello/katello.git > % katello-configure --development ~/katello > > This results in all services running, including pulp and candlepin, from the git checkout. Well, katello-configure only expects it is executed on RH-based distro. It could work, patches are welcome from the community, but right now, I did not test it. Try to run it on Debian (or whatever) and see it if works. I doubt it works, there are so many differences across other distros. Therefore, creating such an option to katello-configure seems to be lots of work and still it cannot be used on other systems (like MacOS etc). I'd rather stick NOT to extend katello-configure much. Currently I am working on big review and --reset option implementation and its about two weeks of work. Pretty challenging to do everything in Puppet. -- Later, Lukas "lzap" Zapletal #katello #systemengine From thomasmckay at redhat.com Wed Jul 18 12:17:05 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 18 Jul 2012 08:17:05 -0400 (EDT) Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120718121028.GF5587@lzapx.brq.redhat.com> Message-ID: <9018933a-28f8-4d56-85af-33aeb29a26ea@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, July 18, 2012 8:10:29 AM > Subject: Re: [katello-devel] where to get required katello gems > > On Wed, Jul 18, 2012 at 07:45:17AM -0400, Tom McKay wrote: > > What do you mean there is no katello-configure on non-RH systems? > > That's a bug if the rpm doesn't lay one down. > > > > I'm suggesting that the dev setup should easily be: > > > > % yum install -y katello-all > > % cd ~ > > % git clone git at github.com:Katello/katello.git > > % katello-configure --development ~/katello > > > > This results in all services running, including pulp and candlepin, > > from the git checkout. > > Well, katello-configure only expects it is executed on RH-based > distro. > It could work, patches are welcome from the community, but right now, > I > did not test it. Try to run it on Debian (or whatever) and see it if > works. I doubt it works, there are so many differences across other > distros. Oh, by RH you meant both fedora and rhel. > > Therefore, creating such an option to katello-configure seems to be > lots > of work and still it cannot be used on other systems (like MacOS > etc). > I'd rather stick NOT to extend katello-configure much. Currently I am > working on big review and --reset option implementation and its about > two weeks of work. Pretty challenging to do everything in Puppet. Well, while you're in there... :) > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Wed Jul 18 12:24:03 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 Jul 2012 14:24:03 +0200 Subject: [katello-devel] why we have /usr/share/katello/script ? In-Reply-To: <5006A4A1.3010303@redhat.com> References: <5006A38C.8030908@redhat.com> <5006A4A1.3010303@redhat.com> Message-ID: <20120718122403.GH5587@lzapx.brq.redhat.com> Some scripts are really only for development setup, let's do a review: CAN BE MOVED: backup.sh restore.sh - example scripts for backup - not used (maybe should go into docs dir) katello-debug katello-generate-passphrase katello-check - helper scripts (should be moved but must be tested!) katello-reset-dbs - this will gets outdated once I merge --reset option (soon) reset-oauth - we use this in the post RPM section - we should get rid of this (causing issues during upgrades - katello-configure should do this, on my TODO list) SHOULD BE PART OF katello-devel: rails routes run_spec katello-refresh-cdn (?) SHOULD STAY (we use it in our init.d scripts): delayed_job - startup script for delayed_job thin - we start katello instance with it Please comment. LZ On Wed, Jul 18, 2012 at 07:57:21AM -0400, Bryan Kearney wrote: > On 07/18/2012 07:52 AM, Miroslav Such? wrote: > >Is there some history behind having: > > /usr/share/katello/script > >and having symlinks from /usr/bin to files in that directory? > > > >I'm asking because: > ># ls -l /usr/bin/katello-debug > >lrwxrwxrwx. 1 root root 39 Jul 17 16:01 /usr/bin/katello-debug -> > >/usr/share/katello/script/katello-debug > ># ls -lZ /usr/share/katello/script/katello-debug > >-rwxr-xr-x. root root system_u:object_r:usr_t:s0 > >/usr/share/katello/script/katello-debug > > > >And I would have expect that this script would have bin_t instead of usr_t. > >And I could not imagine what is the advantage of having > >/usr/share/katello/script/ instead of putting thos file directly into > >/usr/bin/? > > Only reason I can think of is that is where the rails comand is? > But, I dont know off hand. > > -- bk > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Jul 18 12:25:55 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 Jul 2012 14:25:55 +0200 Subject: [katello-devel] API documentation effort In-Reply-To: <5006A4C0.4070000@redhat.com> References: <20f74536-39c7-4b45-b680-84180652337e@zmail16.collab.prod.int.phx2.redhat.com> <5006A4C0.4070000@redhat.com> Message-ID: <20120718122554.GI5587@lzapx.brq.redhat.com> On Wed, Jul 18, 2012 at 07:57:52AM -0400, Bryan Kearney wrote: > +1 > > -- bk > So you don't want V1 API docs anymore? Well, I am fine with that :-) +1 -- Later, Lukas "lzap" Zapletal #katello #systemengine From inecas at redhat.com Wed Jul 18 12:29:20 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 18 Jul 2012 14:29:20 +0200 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 Message-ID: <5006AC20.4000502@redhat.com> Hi folks, Trying to run latest Foreman with Katello out of the box is not possible right now: Forman depends on Rails 3.0.15 and we 3.0.10. If there are no other reasons to stay with 3.0.10, what about bumping it up to 3.0.15, and as bonus get all the fixes that were introduced there? I've discussed with Ohad the possiblity to loose the dependency condition in the spec file and it seems it would be possible, but going forward is maybe better direction. -- Ivan From inecas at redhat.com Wed Jul 18 12:35:10 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 18 Jul 2012 14:35:10 +0200 Subject: [katello-devel] API documentation effort In-Reply-To: <20f74536-39c7-4b45-b680-84180652337e@zmail16.collab.prod.int.phx2.redhat.com> References: <20f74536-39c7-4b45-b680-84180652337e@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <5006AD7E.4070705@redhat.com> On 07/18/2012 01:48 PM, Tom McKay wrote: > > ----- Original Message ----- >> From: "Lukas Zapletal" >> To: katello-devel at redhat.com >> Sent: Wednesday, July 18, 2012 5:35:08 AM >> Subject: [katello-devel] API documentation effort >> >> Guys, >> >> we need some help documenting our API. On the following page >> >> https://fedorahosted.org/katello/wiki/APIDocumentationEfforts >> >> we have a tutorial how to write some API documentation. We have a >> branch >> on github for submitting doco work. > Let's just merge it into master? I'm more inclined just to add stuff incrementally when I'm fixing some code. It might probably work better then working on it in separate branch and merging the whole stuff at the end. I will try to get what's reviewed into master by the end of this week. -- Ivan > >> Thanks for help >> >> -- >> Later, >> >> Lukas "lzap" Zapletal >> #katello #systemengine >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From thomasmckay at redhat.com Wed Jul 18 12:38:25 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 18 Jul 2012 08:38:25 -0400 (EDT) Subject: [katello-devel] why we have /usr/share/katello/script ? In-Reply-To: <20120718122403.GH5587@lzapx.brq.redhat.com> Message-ID: <0683f4dc-e78a-42b4-af4b-84f8dc41c58f@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, July 18, 2012 8:24:03 AM > Subject: Re: [katello-devel] why we have /usr/share/katello/script ? > > Some scripts are really only for development setup, let's do a > review: > > CAN BE MOVED: > > backup.sh > restore.sh > - example scripts for backup - not used (maybe should go into docs > dir) > katello-debug > katello-generate-passphrase > katello-check > - helper scripts (should be moved but must be tested!) > katello-reset-dbs > - this will gets outdated once I merge --reset option (soon) No! Do not remove katello-reset-dbs. There are two use cases here: katello-configure --reset : Reset the system in preparation for a clean run of katello-configure as if it had never been run before. katello-reset-dbs : Wipe all the data and repopulate it with ACME_Corporation > reset-oauth > - we use this in the post RPM section - we should get rid of this > (causing issues during upgrades - katello-configure should do > this, > on my TODO list) > > SHOULD BE PART OF katello-devel: > > rails > routes > run_spec > katello-refresh-cdn (?) > > SHOULD STAY (we use it in our init.d scripts): > > delayed_job > - startup script for delayed_job > thin > - we start katello instance with it > > Please comment. > > LZ > > On Wed, Jul 18, 2012 at 07:57:21AM -0400, Bryan Kearney wrote: > > On 07/18/2012 07:52 AM, Miroslav Such? wrote: > > >Is there some history behind having: > > > /usr/share/katello/script > > >and having symlinks from /usr/bin to files in that directory? > > > > > >I'm asking because: > > ># ls -l /usr/bin/katello-debug > > >lrwxrwxrwx. 1 root root 39 Jul 17 16:01 /usr/bin/katello-debug -> > > >/usr/share/katello/script/katello-debug > > ># ls -lZ /usr/share/katello/script/katello-debug > > >-rwxr-xr-x. root root system_u:object_r:usr_t:s0 > > >/usr/share/katello/script/katello-debug > > > > > >And I would have expect that this script would have bin_t instead > > >of usr_t. > > >And I could not imagine what is the advantage of having > > >/usr/share/katello/script/ instead of putting thos file directly > > >into > > >/usr/bin/? > > > > Only reason I can think of is that is where the rails comand is? > > But, I dont know off hand. > > > > -- bk > > > > > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From gkhachik at redhat.com Wed Jul 18 12:40:57 2012 From: gkhachik at redhat.com (Garik Khachikyan) Date: Wed, 18 Jul 2012 14:40:57 +0200 Subject: [katello-devel] why we have /usr/share/katello/script ? In-Reply-To: <0683f4dc-e78a-42b4-af4b-84f8dc41c58f@zmail16.collab.prod.int.phx2.redhat.com> References: <0683f4dc-e78a-42b4-af4b-84f8dc41c58f@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <5006AED9.1080805@redhat.com> well, at least please leave it in some github place. We (QE) sometimes find it really useful! thanks. On 18/07/12 14:38, Tom McKay wrote: > > ----- Original Message ----- >> From: "Lukas Zapletal" >> To: katello-devel at redhat.com >> Sent: Wednesday, July 18, 2012 8:24:03 AM >> Subject: Re: [katello-devel] why we have /usr/share/katello/script ? >> >> Some scripts are really only for development setup, let's do a >> review: >> >> CAN BE MOVED: >> >> backup.sh >> restore.sh >> - example scripts for backup - not used (maybe should go into docs >> dir) >> katello-debug >> katello-generate-passphrase >> katello-check >> - helper scripts (should be moved but must be tested!) >> katello-reset-dbs >> - this will gets outdated once I merge --reset option (soon) > No! Do not remove katello-reset-dbs. There are two use cases here: > > katello-configure --reset : Reset the system in preparation for a clean run of katello-configure as if it had never been run before. > > katello-reset-dbs : Wipe all the data and repopulate it with ACME_Corporation > > >> reset-oauth >> - we use this in the post RPM section - we should get rid of this >> (causing issues during upgrades - katello-configure should do >> this, >> on my TODO list) >> >> SHOULD BE PART OF katello-devel: >> >> rails >> routes >> run_spec >> katello-refresh-cdn (?) >> >> SHOULD STAY (we use it in our init.d scripts): >> >> delayed_job >> - startup script for delayed_job >> thin >> - we start katello instance with it >> >> Please comment. >> >> LZ >> >> On Wed, Jul 18, 2012 at 07:57:21AM -0400, Bryan Kearney wrote: >>> On 07/18/2012 07:52 AM, Miroslav Such? wrote: >>>> Is there some history behind having: >>>> /usr/share/katello/script >>>> and having symlinks from /usr/bin to files in that directory? >>>> >>>> I'm asking because: >>>> # ls -l /usr/bin/katello-debug >>>> lrwxrwxrwx. 1 root root 39 Jul 17 16:01 /usr/bin/katello-debug -> >>>> /usr/share/katello/script/katello-debug >>>> # ls -lZ /usr/share/katello/script/katello-debug >>>> -rwxr-xr-x. root root system_u:object_r:usr_t:s0 >>>> /usr/share/katello/script/katello-debug >>>> >>>> And I would have expect that this script would have bin_t instead >>>> of usr_t. >>>> And I could not imagine what is the advantage of having >>>> /usr/share/katello/script/ instead of putting thos file directly >>>> into >>>> /usr/bin/? >>> Only reason I can think of is that is where the rails comand is? >>> But, I dont know off hand. >>> >>> -- bk >>> >>> >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> -- >> Later, >> >> Lukas "lzap" Zapletal >> #katello #systemengine >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jlabocki at redhat.com Wed Jul 18 12:51:16 2012 From: jlabocki at redhat.com (James Labocki) Date: Wed, 18 Jul 2012 08:51:16 -0400 (EDT) Subject: [katello-devel] why we have /usr/share/katello/script ? In-Reply-To: <5006AED9.1080805@redhat.com> References: <0683f4dc-e78a-42b4-af4b-84f8dc41c58f@zmail16.collab.prod.int.phx2.redhat.com> <5006AED9.1080805@redhat.com> Message-ID: <6C5E47CE-02F5-471C-87F5-C290038F9652@redhat.com> Please leave the katello-reset-dbs script in place. We use it a lot in the field and in labs. -James On Jul 18, 2012, at 7:41 AM, Garik Khachikyan wrote: > well, > > at least please leave it in some github place. > > We (QE) sometimes find it really useful! > > thanks. > > On 18/07/12 14:38, Tom McKay wrote: >> >> ----- Original Message ----- >>> From: "Lukas Zapletal" >>> To: katello-devel at redhat.com >>> Sent: Wednesday, July 18, 2012 8:24:03 AM >>> Subject: Re: [katello-devel] why we have /usr/share/katello/script ? >>> >>> Some scripts are really only for development setup, let's do a >>> review: >>> >>> CAN BE MOVED: >>> >>> backup.sh >>> restore.sh >>> - example scripts for backup - not used (maybe should go into docs >>> dir) >>> katello-debug >>> katello-generate-passphrase >>> katello-check >>> - helper scripts (should be moved but must be tested!) >>> katello-reset-dbs >>> - this will gets outdated once I merge --reset option (soon) >> No! Do not remove katello-reset-dbs. There are two use cases here: >> >> katello-configure --reset : Reset the system in preparation for a clean run of katello-configure as if it had never been run before. >> >> katello-reset-dbs : Wipe all the data and repopulate it with ACME_Corporation >> >> >>> reset-oauth >>> - we use this in the post RPM section - we should get rid of this >>> (causing issues during upgrades - katello-configure should do >>> this, >>> on my TODO list) >>> >>> SHOULD BE PART OF katello-devel: >>> >>> rails >>> routes >>> run_spec >>> katello-refresh-cdn (?) >>> >>> SHOULD STAY (we use it in our init.d scripts): >>> >>> delayed_job >>> - startup script for delayed_job >>> thin >>> - we start katello instance with it >>> >>> Please comment. >>> >>> LZ >>> >>> On Wed, Jul 18, 2012 at 07:57:21AM -0400, Bryan Kearney wrote: >>>> On 07/18/2012 07:52 AM, Miroslav Such? wrote: >>>>> Is there some history behind having: >>>>> /usr/share/katello/script >>>>> and having symlinks from /usr/bin to files in that directory? >>>>> >>>>> I'm asking because: >>>>> # ls -l /usr/bin/katello-debug >>>>> lrwxrwxrwx. 1 root root 39 Jul 17 16:01 /usr/bin/katello-debug -> >>>>> /usr/share/katello/script/katello-debug >>>>> # ls -lZ /usr/share/katello/script/katello-debug >>>>> -rwxr-xr-x. root root system_u:object_r:usr_t:s0 >>>>> /usr/share/katello/script/katello-debug >>>>> >>>>> And I would have expect that this script would have bin_t instead >>>>> of usr_t. >>>>> And I could not imagine what is the advantage of having >>>>> /usr/share/katello/script/ instead of putting thos file directly >>>>> into >>>>> /usr/bin/? >>>> Only reason I can think of is that is where the rails comand is? >>>> But, I dont know off hand. >>>> >>>> -- bk >>>> >>>> >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> -- >>> Later, >>> >>> Lukas "lzap" Zapletal >>> #katello #systemengine >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Wed Jul 18 12:55:56 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 Jul 2012 08:55:56 -0400 Subject: [katello-devel] API documentation effort In-Reply-To: <20120718122554.GI5587@lzapx.brq.redhat.com> References: <20f74536-39c7-4b45-b680-84180652337e@zmail16.collab.prod.int.phx2.redhat.com> <5006A4C0.4070000@redhat.com> <20120718122554.GI5587@lzapx.brq.redhat.com> Message-ID: <5006B25C.8080404@redhat.com> On 07/18/2012 08:25 AM, Lukas Zapletal wrote: > On Wed, Jul 18, 2012 at 07:57:52AM -0400, Bryan Kearney wrote: >> +1 >> >> -- bk >> > > So you don't want V1 API docs anymore? Well, I am fine with that :-) > > +1 > IMHO... lets get it into master and get folks working as we go. Would I like it, yes. But, it would be better to have the API docs updated and published as part of the normal end of sprint work. -- bk From lzap at redhat.com Wed Jul 18 13:52:00 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 Jul 2012 15:52:00 +0200 Subject: [katello-devel] why we have /usr/share/katello/script ? In-Reply-To: <0683f4dc-e78a-42b4-af4b-84f8dc41c58f@zmail16.collab.prod.int.phx2.redhat.com> References: <20120718122403.GH5587@lzapx.brq.redhat.com> <0683f4dc-e78a-42b4-af4b-84f8dc41c58f@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <20120718135200.GP5587@lzapx.brq.redhat.com> > No! Do not remove katello-reset-dbs. There are two use cases here: > > katello-configure --reset : Reset the system in preparation for a clean run of katello-configure as if it had never been run before. > > katello-reset-dbs : Wipe all the data and repopulate it with ACME_Corporation > Uh, I am basically done with implementation of katello-configure --reset but what it does is: - drops katello db - drops pulp db - drops candlepin db - erases elasticsearch index - re-executes puppet to re-initalize all databases again Actually I called this --reset-data. So basically it replaces katello-reset-dbs. I was never working on a task that would "clean system as if it had neven been run before". Maybe a misunderstanding here. Anyway the --reset-data option was not so hard, pretty challenging was to rewrite those parts of Puppet that was not possible to run twice (were not idempotent). Now its all idempotent, se we can run katello-configure (even without --reset-data) multiple times and it just "corrects" all configuration deviations. Basically there is no need of any cleanup task now, because you can run katello-configure as many times as you want. Basically it should always just "correct" everything. We will need to test this properly, since its not possible for me to catch all the possible states, but this is it - should always give you proper state. Even after yum update. And you can also change configuration values to different ones. Should work. I am testing with headpin right now. I hope I will push this soon (tomorrow perhaps). LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Jul 18 13:55:33 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 Jul 2012 15:55:33 +0200 Subject: [katello-devel] why we have /usr/share/katello/script ? In-Reply-To: <6C5E47CE-02F5-471C-87F5-C290038F9652@redhat.com> References: <0683f4dc-e78a-42b4-af4b-84f8dc41c58f@zmail16.collab.prod.int.phx2.redhat.com> <5006AED9.1080805@redhat.com> <6C5E47CE-02F5-471C-87F5-C290038F9652@redhat.com> Message-ID: <20120718135533.GQ5587@lzapx.brq.redhat.com> There is new feature coming that will eventually replace this. Should be fully supported option --reset-data of katello-configure that would do the same. Don't worry I will not touch katello-reset-dbs until it is confirmed you are all good with the new approach and your scripts were changed. No need to rush. LZ On Wed, Jul 18, 2012 at 08:51:16AM -0400, James Labocki wrote: > Please leave the katello-reset-dbs script in place. We use it a lot in the field and in labs. > > -James > > > > On Jul 18, 2012, at 7:41 AM, Garik Khachikyan wrote: > > > well, > > > > at least please leave it in some github place. > > > > We (QE) sometimes find it really useful! > > > > thanks. > > > > On 18/07/12 14:38, Tom McKay wrote: > >> > >> ----- Original Message ----- > >>> From: "Lukas Zapletal" > >>> To: katello-devel at redhat.com > >>> Sent: Wednesday, July 18, 2012 8:24:03 AM > >>> Subject: Re: [katello-devel] why we have /usr/share/katello/script ? > >>> > >>> Some scripts are really only for development setup, let's do a > >>> review: > >>> > >>> CAN BE MOVED: > >>> > >>> backup.sh > >>> restore.sh > >>> - example scripts for backup - not used (maybe should go into docs > >>> dir) > >>> katello-debug > >>> katello-generate-passphrase > >>> katello-check > >>> - helper scripts (should be moved but must be tested!) > >>> katello-reset-dbs > >>> - this will gets outdated once I merge --reset option (soon) > >> No! Do not remove katello-reset-dbs. There are two use cases here: > >> > >> katello-configure --reset : Reset the system in preparation for a clean run of katello-configure as if it had never been run before. > >> > >> katello-reset-dbs : Wipe all the data and repopulate it with ACME_Corporation > >> > >> > >>> reset-oauth > >>> - we use this in the post RPM section - we should get rid of this > >>> (causing issues during upgrades - katello-configure should do > >>> this, > >>> on my TODO list) > >>> > >>> SHOULD BE PART OF katello-devel: > >>> > >>> rails > >>> routes > >>> run_spec > >>> katello-refresh-cdn (?) > >>> > >>> SHOULD STAY (we use it in our init.d scripts): > >>> > >>> delayed_job > >>> - startup script for delayed_job > >>> thin > >>> - we start katello instance with it > >>> > >>> Please comment. > >>> > >>> LZ > >>> > >>> On Wed, Jul 18, 2012 at 07:57:21AM -0400, Bryan Kearney wrote: > >>>> On 07/18/2012 07:52 AM, Miroslav Such? wrote: > >>>>> Is there some history behind having: > >>>>> /usr/share/katello/script > >>>>> and having symlinks from /usr/bin to files in that directory? > >>>>> > >>>>> I'm asking because: > >>>>> # ls -l /usr/bin/katello-debug > >>>>> lrwxrwxrwx. 1 root root 39 Jul 17 16:01 /usr/bin/katello-debug -> > >>>>> /usr/share/katello/script/katello-debug > >>>>> # ls -lZ /usr/share/katello/script/katello-debug > >>>>> -rwxr-xr-x. root root system_u:object_r:usr_t:s0 > >>>>> /usr/share/katello/script/katello-debug > >>>>> > >>>>> And I would have expect that this script would have bin_t instead > >>>>> of usr_t. > >>>>> And I could not imagine what is the advantage of having > >>>>> /usr/share/katello/script/ instead of putting thos file directly > >>>>> into > >>>>> /usr/bin/? > >>>> Only reason I can think of is that is where the rails comand is? > >>>> But, I dont know off hand. > >>>> > >>>> -- bk > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> katello-devel mailing list > >>>> katello-devel at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/katello-devel > >>> -- > >>> Later, > >>> > >>> Lukas "lzap" Zapletal > >>> #katello #systemengine > >>> > >>> _______________________________________________ > >>> katello-devel mailing list > >>> katello-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/katello-devel > >>> > >> _______________________________________________ > >> katello-devel mailing list > >> katello-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Jul 18 13:57:29 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 Jul 2012 15:57:29 +0200 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <5006AC20.4000502@redhat.com> References: <5006AC20.4000502@redhat.com> Message-ID: <20120718135729.GR5587@lzapx.brq.redhat.com> I am fine with this but keep in mind CFSE 1.0 still runs on 3.0.10 (and it will likely run to its EOL). Do not (try) to make intrusive changes in the codebase if possible, or cherry-picks will be painful. Also - should we bump Rails in the CFSE 1.1 as well? I guess so... LZ On Wed, Jul 18, 2012 at 02:29:20PM +0200, Ivan Necas wrote: > Hi folks, > > Trying to run latest Foreman with Katello out of the box is not > possible right now: Forman depends on Rails 3.0.15 and we 3.0.10. > > If there are no other reasons to stay with 3.0.10, what about > bumping it up to 3.0.15, and as bonus get all the fixes that were > introduced there? > > I've discussed with Ohad the possiblity to loose the dependency > condition in the spec file and it seems it would be possible, but > going forward is maybe better direction. > > -- > Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From jomara at redhat.com Wed Jul 18 14:01:17 2012 From: jomara at redhat.com (Jordan OMara) Date: Wed, 18 Jul 2012 10:01:17 -0400 Subject: [katello-devel] why we have /usr/share/katello/script ? In-Reply-To: <20120718135200.GP5587@lzapx.brq.redhat.com> References: <20120718122403.GH5587@lzapx.brq.redhat.com> <0683f4dc-e78a-42b4-af4b-84f8dc41c58f@zmail16.collab.prod.int.phx2.redhat.com> <20120718135200.GP5587@lzapx.brq.redhat.com> Message-ID: <20120718140117.GB24554@redhat.com> On 18/07/12 15:52 +0200, Lukas Zapletal wrote: > >Uh, I am basically done with implementation of > >katello-configure --reset > >but what it does is: > >- drops katello db >- drops pulp db >- drops candlepin db >- erases elasticsearch index >- re-executes puppet to re-initalize all databases again > >Actually I called this --reset-data. > I think there are a few people that use reset-dbs for various lab/demo purposes and want to keep it. When I was working on this feature independently of you, I learned that and came up with the following plan katello-configure --clean (executes your new functionality) katello-configure --reset (executes katello-reset-dbs) If you don't like the idea of multiple flags, just add your feature and DONT remove reset-dbs -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From msuchy at redhat.com Wed Jul 18 14:04:42 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Wed, 18 Jul 2012 16:04:42 +0200 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <5006AC20.4000502@redhat.com> References: <5006AC20.4000502@redhat.com> Message-ID: <5006C27A.4090600@redhat.com> On 07/18/2012 02:29 PM, Ivan Ne?as wrote: > Hi folks, > > Trying to run latest Foreman with Katello out of the box is not possible > right now: Forman depends on Rails 3.0.15 and we 3.0.10. > > If there are no other reasons to stay with 3.0.10, what about bumping it > up to 3.0.15, and as bonus get all the fixes that were introduced there? > > I've discussed with Ohad the possiblity to loose the dependency > condition in the spec file and it seems it would be possible, but going > forward is maybe better direction. > That means not only rebuild aprox. 6 packages for rhel6, but build all rails packages for F16, F17, where is 3.0.10 and 3.0.11. This is full day work. Are you ready for that? -- Miroslav Suchy Red Hat Systems Management Engineering From inecas at redhat.com Wed Jul 18 14:16:18 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 18 Jul 2012 16:16:18 +0200 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <5006C27A.4090600@redhat.com> References: <5006AC20.4000502@redhat.com> <5006C27A.4090600@redhat.com> Message-ID: <5006C532.1030005@redhat.com> On 07/18/2012 04:04 PM, Miroslav Such? wrote: > On 07/18/2012 02:29 PM, Ivan Ne?as wrote: >> Hi folks, >> >> Trying to run latest Foreman with Katello out of the box is not possible >> right now: Forman depends on Rails 3.0.15 and we 3.0.10. >> >> If there are no other reasons to stay with 3.0.10, what about bumping it >> up to 3.0.15, and as bonus get all the fixes that were introduced there? >> >> I've discussed with Ohad the possiblity to loose the dependency >> condition in the spec file and it seems it would be possible, but going >> forward is maybe better direction. >> > > That means not only rebuild aprox. 6 packages for rhel6, but build all > rails packages for F16, F17, where is 3.0.10 and 3.0.11. This is full > day work. Are you ready for that? > You tell me :) -- Ivan From calfonso at redhat.com Wed Jul 18 14:18:23 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Wed, 18 Jul 2012 10:18:23 -0400 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <5006AC20.4000502@redhat.com> References: <5006AC20.4000502@redhat.com> Message-ID: <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> On 18/07/12 14:29 +0200, Ivan Ne?as wrote: >Hi folks, > >Trying to run latest Foreman with Katello out of the box is not >possible right now: Forman depends on Rails 3.0.15 and we 3.0.10. > >If there are no other reasons to stay with 3.0.10, what about bumping >it up to 3.0.15, and as bonus get all the fixes that were introduced >there? > >I've discussed with Ohad the possiblity to loose the dependency >condition in the spec file and it seems it would be possible, but >going forward is maybe better direction. > >-- >Ivan > Jordan has created a bz for this and plans to get this out for 1.1. I'm not sure of the bz#. Also, we should get conductor on the same version at the same time. -- Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From jomara at redhat.com Wed Jul 18 14:29:35 2012 From: jomara at redhat.com (Jordan OMara) Date: Wed, 18 Jul 2012 10:29:35 -0400 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> Message-ID: <20120718142935.GC24554@redhat.com> On 18/07/12 10:18 -0400, Chris Alfonso wrote: >On 18/07/12 14:29 +0200, Ivan Ne?as wrote: >>Hi folks, >> >>Trying to run latest Foreman with Katello out of the box is not >>possible right now: Forman depends on Rails 3.0.15 and we 3.0.10. >> >>If there are no other reasons to stay with 3.0.10, what about >>bumping it up to 3.0.15, and as bonus get all the fixes that were >>introduced there? >> >>I've discussed with Ohad the possiblity to loose the dependency >>condition in the spec file and it seems it would be possible, but >>going forward is maybe better direction. >> >>-- >>Ivan >> >Jordan has created a bz for this and plans to get this out for 1.1. >I'm not sure of the bz#. Also, we should get conductor on the same version >at the same time. Didn't create a BZ, just an email thread wherein nobody expressed any major concerns other than ugprading all of the projects at the same time Someone will need to do the RPM packaging! -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From inecas at redhat.com Wed Jul 18 14:39:46 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 18 Jul 2012 16:39:46 +0200 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <5006C27A.4090600@redhat.com> References: <5006AC20.4000502@redhat.com> <5006C27A.4090600@redhat.com> Message-ID: <5006CAB2.8040100@redhat.com> On 07/18/2012 04:04 PM, Miroslav Such? wrote: > On 07/18/2012 02:29 PM, Ivan Ne?as wrote: >> Hi folks, >> >> Trying to run latest Foreman with Katello out of the box is not possible >> right now: Forman depends on Rails 3.0.15 and we 3.0.10. >> >> If there are no other reasons to stay with 3.0.10, what about bumping it >> up to 3.0.15, and as bonus get all the fixes that were introduced there? >> >> I've discussed with Ohad the possiblity to loose the dependency >> condition in the spec file and it seems it would be possible, but going >> forward is maybe better direction. >> > > That means not only rebuild aprox. 6 packages for rhel6, but build all > rails packages for F16, F17, where is 3.0.10 and 3.0.11. This is full > day work. Are you ready for that? Do you think this would be of any use for that? https://github.com/theforeman/foreman-rpms/tree/f16 -- Ivan From msuchy at redhat.com Wed Jul 18 14:51:28 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Wed, 18 Jul 2012 16:51:28 +0200 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <5006CAB2.8040100@redhat.com> References: <5006AC20.4000502@redhat.com> <5006C27A.4090600@redhat.com> <5006CAB2.8040100@redhat.com> Message-ID: <5006CD70.3050609@redhat.com> On 07/18/2012 04:39 PM, Ivan Ne?as wrote: > Do you think this would be of any use for that? > > https://github.com/theforeman/foreman-rpms/tree/f16 not really -- Miroslav Suchy Red Hat Systems Management Engineering From bkearney at redhat.com Wed Jul 18 15:22:38 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 Jul 2012 11:22:38 -0400 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <20120718142935.GC24554@redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> <20120718142935.GC24554@redhat.com> Message-ID: <5006D4BE.1050605@redhat.com> On 07/18/2012 10:29 AM, Jordan OMara wrote: > On 18/07/12 10:18 -0400, Chris Alfonso wrote: >> On 18/07/12 14:29 +0200, Ivan Ne?as wrote: >>> Hi folks, >>> >>> Trying to run latest Foreman with Katello out of the box is not >>> possible right now: Forman depends on Rails 3.0.15 and we 3.0.10. >>> >>> If there are no other reasons to stay with 3.0.10, what about bumping >>> it up to 3.0.15, and as bonus get all the fixes that were introduced >>> there? >>> >>> I've discussed with Ohad the possiblity to loose the dependency >>> condition in the spec file and it seems it would be possible, but >>> going forward is maybe better direction. >>> >>> -- >>> Ivan >>> >> Jordan has created a bz for this and plans to get this out for 1.1. >> I'm not sure of the bz#. Also, we should get conductor on the same >> version >> at the same time. > > Didn't create a BZ, just an email thread wherein nobody expressed any > major concerns other than ugprading all of the projects at the same > time > > Someone will need to do the RPM packaging Sorry.. missing a thread.. where is the fedora packing needs? Is it for F16? -- kb From bkearney at redhat.com Wed Jul 18 15:25:26 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 Jul 2012 11:25:26 -0400 Subject: [katello-devel] why we have /usr/share/katello/script ? In-Reply-To: <20120718140117.GB24554@redhat.com> References: <20120718122403.GH5587@lzapx.brq.redhat.com> <0683f4dc-e78a-42b4-af4b-84f8dc41c58f@zmail16.collab.prod.int.phx2.redhat.com> <20120718135200.GP5587@lzapx.brq.redhat.com> <20120718140117.GB24554@redhat.com> Message-ID: <5006D566.6010305@redhat.com> On 07/18/2012 10:01 AM, Jordan OMara wrote: > On 18/07/12 15:52 +0200, Lukas Zapletal wrote: >> >> Uh, I am basically done with implementation of >> >> katello-configure --reset >> >> but what it does is: >> >> - drops katello db >> - drops pulp db >> - drops candlepin db >> - erases elasticsearch index >> - re-executes puppet to re-initalize all databases again >> >> Actually I called this --reset-data. >> > > I think there are a few people that use reset-dbs for various lab/demo > purposes and want to keep it. When I was working on this feature > independently of you, I learned that and came up with the following > plan > > katello-configure --clean (executes your new functionality) > katello-configure --reset (executes katello-reset-dbs) > > If you don't like the idea of multiple flags, just add your feature > and DONT remove reset-dbs > Does one of these two approaches work? -- bk From jomara at redhat.com Wed Jul 18 15:26:27 2012 From: jomara at redhat.com (Jordan OMara) Date: Wed, 18 Jul 2012 11:26:27 -0400 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <5006D4BE.1050605@redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> <20120718142935.GC24554@redhat.com> <5006D4BE.1050605@redhat.com> Message-ID: <20120718152627.GD24554@redhat.com> On 18/07/12 11:22 -0400, Bryan Kearney wrote: >On 07/18/2012 10:29 AM, Jordan OMara wrote: >>On 18/07/12 10:18 -0400, Chris Alfonso wrote: >>>On 18/07/12 14:29 +0200, Ivan Ne?as wrote: >>>>Hi folks, >>>> >>>>Trying to run latest Foreman with Katello out of the box is not >>>>possible right now: Forman depends on Rails 3.0.15 and we 3.0.10. >>>> >>>>If there are no other reasons to stay with 3.0.10, what about bumping >>>>it up to 3.0.15, and as bonus get all the fixes that were introduced >>>>there? >>>> >>>>I've discussed with Ohad the possiblity to loose the dependency >>>>condition in the spec file and it seems it would be possible, but >>>>going forward is maybe better direction. >>>> >>>>-- >>>>Ivan >>>> >>>Jordan has created a bz for this and plans to get this out for 1.1. >>>I'm not sure of the bz#. Also, we should get conductor on the same >>>version >>>at the same time. >> >>Didn't create a BZ, just an email thread wherein nobody expressed any >>major concerns other than ugprading all of the projects at the same >>time >> >>Someone will need to do the RPM packaging > >Sorry.. missing a thread.. where is the fedora packing needs? Is it for F16? > EPEL6 + F16 rubygem-rails-3.0.15 -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From msuchy at redhat.com Wed Jul 18 15:32:34 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 18 Jul 2012 17:32:34 +0200 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <20120718152627.GD24554@redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> <20120718142935.GC24554@redhat.com> <5006D4BE.1050605@redhat.com> <20120718152627.GD24554@redhat.com> Message-ID: <5006D712.3040108@redhat.com> On 07/18/2012 05:26 PM, Jordan OMara wrote: > EPEL6 + F16 rubygem-rails-3.0.15 + F17 F18 already contains rubygem-rails-3.0.15, so that is safe. -- Miroslav Suchy Red Hat Systems Management Engineering From jeckersb at redhat.com Wed Jul 18 15:37:35 2012 From: jeckersb at redhat.com (John Eckersberg) Date: Wed, 18 Jul 2012 11:37:35 -0400 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <20120718152627.GD24554@redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> <20120718142935.GC24554@redhat.com> <5006D4BE.1050605@redhat.com> <20120718152627.GD24554@redhat.com> Message-ID: <87fw8pjd1c.fsf@redhat.com> Maybe I missed this in the thread, but what exactly is required from 3.0.15 that is not satisfied by 3.0.10 + CVE patches? We certainly can go through the exercise to update everything, but it will be a moderately involved effort. A concrete justification would be good before we dive into that hole. From bkearney at redhat.com Wed Jul 18 15:40:09 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 Jul 2012 11:40:09 -0400 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <87fw8pjd1c.fsf@redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> <20120718142935.GC24554@redhat.com> <5006D4BE.1050605@redhat.com> <20120718152627.GD24554@redhat.com> <87fw8pjd1c.fsf@redhat.com> Message-ID: <5006D8D9.60905@redhat.com> On 07/18/2012 11:37 AM, John Eckersberg wrote: > Maybe I missed this in the thread, but what exactly is required from > 3.0.15 that is not satisfied by 3.0.10 + CVE patches? > > We certainly can go through the exercise to update everything, but it > will be a moderately involved effort. A concrete justification would be > good before we dive into that hole. The main goal is to get to a happy version of rails for foreman + katello + aeolus. -- bk From jomara at redhat.com Wed Jul 18 15:44:56 2012 From: jomara at redhat.com (Jordan OMara) Date: Wed, 18 Jul 2012 11:44:56 -0400 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <87fw8pjd1c.fsf@redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> <20120718142935.GC24554@redhat.com> <5006D4BE.1050605@redhat.com> <20120718152627.GD24554@redhat.com> <87fw8pjd1c.fsf@redhat.com> Message-ID: <20120718154456.GF24554@redhat.com> On 18/07/12 11:37 -0400, John Eckersberg wrote: >Maybe I missed this in the thread, but what exactly is required from >3.0.15 that is not satisfied by 3.0.10 + CVE patches? > My reasoning for wanting the .15 upgrade are the security patches. As long as they are all included in CVE patches, I would be satisfied. Of course, the projects already on .15 would have to downgrade -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From msuchy at redhat.com Wed Jul 18 16:17:53 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 18 Jul 2012 18:17:53 +0200 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <87fw8pjd1c.fsf@redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> <20120718142935.GC24554@redhat.com> <5006D4BE.1050605@redhat.com> <20120718152627.GD24554@redhat.com> <87fw8pjd1c.fsf@redhat.com> Message-ID: <5006E1B1.8040301@redhat.com> On 07/18/2012 05:37 PM, John Eckersberg wrote: > Maybe I missed this in the thread, but what exactly is required from > 3.0.15 that is not satisfied by 3.0.10 + CVE patches? The problem is that foreman is using 3.0.15 Checking their git... at least the reason whey they went from 3.0.14 to 3.0.15 was: https://github.com/rails/rails/issues/6717 I did not dive deeper. The reason why they used 3.0.14 is: https://github.com/theforeman/foreman/commit/758e92e4692a95a72a31fc249d8b13514759e5e8 So I suppose we can use foreman with 3.0.10 + CVE patched -- Miroslav Suchy Red Hat Systems Management Engineering From bkearney at redhat.com Wed Jul 18 17:33:19 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 Jul 2012 13:33:19 -0400 Subject: [katello-devel] Do you want to be a movie star? Message-ID: <5006F35F.60008@redhat.com> Do you want to be a star, and help promote Katello. Have we got a deal for you: https://fedorahosted.org/katello/wiki/Screencasts -- bk From jsherril at redhat.com Wed Jul 18 17:35:34 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 18 Jul 2012 13:35:34 -0400 Subject: [katello-devel] Interesting alternative to curl Message-ID: <5006F3E6.5080502@redhat.com> https://github.com/jkbr/httpie/#readme Looks really neat! -Justin From jrist at redhat.com Wed Jul 18 17:50:27 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 18 Jul 2012 11:50:27 -0600 Subject: [katello-devel] Interesting alternative to curl In-Reply-To: <5006F3E6.5080502@redhat.com> References: <5006F3E6.5080502@redhat.com> Message-ID: <5006F763.5030501@redhat.com> On Wed 18 Jul 2012 11:35:34 AM MDT, Justin Sherrill wrote: > https://github.com/jkbr/httpie/#readme > > Looks really neat! > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Tools named after tasty deserts usually get a +1 from me... -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From adprice at redhat.com Wed Jul 18 20:13:37 2012 From: adprice at redhat.com (Adam Price) Date: Wed, 18 Jul 2012 16:13:37 -0400 (EDT) Subject: [katello-devel] Updated Katello Advanced Install Docs In-Reply-To: <7c75a2b0-f88c-4fc8-94d3-434b57e7eb8a@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <50c58b80-8aac-4ec6-8e1b-2cd0cba76f5c@zmail02.collab.prod.int.phx2.redhat.com> hello folks, I had a horrible time trying to decipher the install docs for Katello . A lot of information there was no longer needed or was redundant. I stripped out most of the old information and built the doc from the process I took to get my katello dev environment up and running. I'm sure it's not the only way, but seemed like the least complicated (to me). Please read over the install doc here [1] and try the process yourself to see whether it works for a wide audience or it this only works for me :) Thanks all! [1] https://fedorahosted.org/katello/wiki/AdvancedInstallation -- adam price From adprice at redhat.com Wed Jul 18 20:31:38 2012 From: adprice at redhat.com (Adam Price) Date: Wed, 18 Jul 2012 16:31:38 -0400 (EDT) Subject: [katello-devel] Updated Katello Advanced Install Docs In-Reply-To: <50c58b80-8aac-4ec6-8e1b-2cd0cba76f5c@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: ----- Original Message ----- > From: "Adam Price" > To: katello-devel at redhat.com > Sent: Wednesday, July 18, 2012 4:13:37 PM > Subject: [katello-devel] Updated Katello Advanced Install Docs > > hello folks, > > I had a horrible time trying to decipher the install docs for Katello > . A lot of information there was no longer needed or was redundant. > > I stripped out most of the old information and built the doc from the > process I took to get my katello dev environment up and running. I'm > sure it's not the only way, but seemed like the least complicated > (to me). > > Please read over the install doc here [1] and try the process > yourself to see whether it works for a wide audience or it this only > works for me :) > > Thanks all! > > > [1] https://fedorahosted.org/katello/wiki/AdvancedInstallation > > -- > adam price > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > oops! ehelms just informed me that the "Building from source" information was still needed. updated. -- adam price From vondruch at redhat.com Thu Jul 19 05:14:16 2012 From: vondruch at redhat.com (=?ISO-8859-1?Q?V=EDt_Ondruch?=) Date: Thu, 19 Jul 2012 07:14:16 +0200 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <5006D712.3040108@redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> <20120718142935.GC24554@redhat.com> <5006D4BE.1050605@redhat.com> <20120718152627.GD24554@redhat.com> <5006D712.3040108@redhat.com> Message-ID: <500797A8.4080407@redhat.com> Dne 18.7.2012 17:32, Miroslav Such? napsal(a): > On 07/18/2012 05:26 PM, Jordan OMara wrote: >> EPEL6 + F16 rubygem-rails-3.0.15 > > + F17 > > F18 already contains rubygem-rails-3.0.15, so that is safe. Not for long. Rails 3.2 were accepted as a F18 feature and we are already building them. Vit From ohadlevy at redhat.com Thu Jul 19 07:20:35 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Thu, 19 Jul 2012 10:20:35 +0300 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <5006F35F.60008@redhat.com> References: <5006F35F.60008@redhat.com> Message-ID: <5007B543.3090600@redhat.com> On 07/18/2012 08:33 PM, Bryan Kearney wrote: > Do you want to be a star, and help promote Katello. Have we got a deal > for you: > > https://fedorahosted.org/katello/wiki/Screencasts > I shamelessly copied that to foreman web site :) Ohad From lzap at redhat.com Thu Jul 19 09:46:42 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 Jul 2012 11:46:42 +0200 Subject: [katello-devel] why we have /usr/share/katello/script ? In-Reply-To: <20120718140117.GB24554@redhat.com> References: <20120718122403.GH5587@lzapx.brq.redhat.com> <0683f4dc-e78a-42b4-af4b-84f8dc41c58f@zmail16.collab.prod.int.phx2.redhat.com> <20120718135200.GP5587@lzapx.brq.redhat.com> <20120718140117.GB24554@redhat.com> Message-ID: <20120719094642.GE4554@lzapx.brq.redhat.com> > I think there are a few people that use reset-dbs for various lab/demo > purposes and want to keep it. When I was working on this feature > independently of you, I learned that and came up with the following > plan > > katello-configure --clean (executes your new functionality) > katello-configure --reset (executes katello-reset-dbs) > > If you don't like the idea of multiple flags, just add your feature > and DONT remove reset-dbs > Well, katello-configure is fully supported utility used by customers and users. While katello-reset-dbs is devel only tool, kind of unsupported script which we use. Why whould we make katello-configure to call this unsupported tool? Additionally, there are no differences between those two. Both results in reseting all databases and restarting all services. I don't see any point. What I would recommend is to leave some time for folks to test katello-configure options and then to remove katello-reset-dbs OR to modify it so it would call (fully supported) katello-configure. I am not getting it, elaborate please. Btw - I want to give a deep dive today if its time about katello-configure new options -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Thu Jul 19 09:58:03 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 Jul 2012 11:58:03 +0200 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <87fw8pjd1c.fsf@redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> <20120718142935.GC24554@redhat.com> <5006D4BE.1050605@redhat.com> <20120718152627.GD24554@redhat.com> <87fw8pjd1c.fsf@redhat.com> Message-ID: <20120719095803.GF4554@lzapx.brq.redhat.com> > Maybe I missed this in the thread, but what exactly is required from > 3.0.15 that is not satisfied by 3.0.10 + CVE patches? > > We certainly can go through the exercise to update everything, but it > will be a moderately involved effort. A concrete justification would be > good before we dive into that hole. I totally share your opinion here. Why would we want to upgrade? If it works, don't touch it. No, seriously in this case (3.0.10 vs 3.0.15) there is no added value. We should use the version which is in the oldest supported Fedora version - which is no Fedora 16. Since it is still supported, we get security fixes "for free". I don't get this "ruby race" of having the latest and greatest versions. This is what geeks don't do :-) My recommendation: 1) Let's make cross-teams deal we will try to stick with latest Fedora version stack. Only if it's absolutely needed, let's upgrade, but I don't see any reason for that. Today it's Fedora 16 rails version, next upgrade would be to Fedora 17 stack. 2) Let's not rush with incorporating latest and greatest features. Sometimes they has very cool things, but let us be realistic. About 10 new features, 20 bug fixes and 20 new bugs are introduced every release. We need to deal with all of them. 3) For now I would recommend to downgrade Foreman. It's not big deal since we already have Fedora 16 rails builds, it's a matter of testing it out if it works. 4) Maybe it's a good time to start discussion about using our shared koji instance. Currently we have koji instance which builds Katello only. There is plenty of possibilities how to re-use it for building Aeolus, Candlepin, Pulp and Foreman. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Thu Jul 19 10:36:10 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 Jul 2012 12:36:10 +0200 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <5006F35F.60008@redhat.com> References: <5006F35F.60008@redhat.com> Message-ID: <20120719103610.GG4554@lzapx.brq.redhat.com> Nice, but why 30 fps? That's too much. Five to ten is way enough saving bandwidth so image is ultra-sharp. Here is my recordmydesktop script (kudos to Jeff Weiss and google.com): https://gist.github.com/3142880 The only drawback is it always records whole screen (if you have multiple monitors then both screens) when using Gnome Shell and other modern desktops (it has only one screen from the X11 perspective). So the hack is to uncomment that RESOLUTION variable and set it properly, so it will only record the first screen (left one in my case). You need this only if you have multi-monitor setup! Just run it in an empty folder and file will be recorded and encoded properly for YouTube. I like this approach very much, it's easy and it gives the best possible quality. I have added the link on the page. LZ On Wed, Jul 18, 2012 at 01:33:19PM -0400, Bryan Kearney wrote: > Do you want to be a star, and help promote Katello. Have we got a > deal for you: > > https://fedorahosted.org/katello/wiki/Screencasts > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Thu Jul 19 11:43:07 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 Jul 2012 07:43:07 -0400 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <20120719103610.GG4554@lzapx.brq.redhat.com> References: <5006F35F.60008@redhat.com> <20120719103610.GG4554@lzapx.brq.redhat.com> Message-ID: <5007F2CB.6090909@redhat.com> On 07/19/2012 06:36 AM, Lukas Zapletal wrote: > Nice, but why 30 fps? That's too much. Five to ten is way enough saving > bandwidth so image is ultra-sharp. Here is my recordmydesktop script > (kudos to Jeff Weiss and google.com): These came from Sean Huck.. who knows susch things. > > https://gist.github.com/3142880 > > The only drawback is it always records whole screen (if you have > multiple monitors then both screens) when using Gnome Shell and other > modern desktops (it has only one screen from the X11 perspective). > So the hack is to uncomment that RESOLUTION variable and set it > properly, so it will only record the first screen (left one in my case). > You need this only if you have multi-monitor setup! > > Just run it in an empty folder and file will be recorded and encoded > properly for YouTube. I like this approach very much, it's easy and it > gives the best possible quality. > > I have added the link on the page. Cool. -- bk From bkearney at redhat.com Thu Jul 19 12:01:57 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 Jul 2012 08:01:57 -0400 Subject: [katello-devel] Blog? Message-ID: <5007F735.8070002@redhat.com> Eric, lzap.. how goes the blog ? :) - bk From calfonso at redhat.com Thu Jul 19 12:26:39 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Thu, 19 Jul 2012 08:26:39 -0400 Subject: [katello-devel] Bumping up the Rails version 3.0.10 -> 3.0.15 In-Reply-To: <20120719095803.GF4554@lzapx.brq.redhat.com> References: <5006AC20.4000502@redhat.com> <20120718141822.GD25332@dhcp-230-220.rdu.redhat.com> <20120718142935.GC24554@redhat.com> <5006D4BE.1050605@redhat.com> <20120718152627.GD24554@redhat.com> <87fw8pjd1c.fsf@redhat.com> <20120719095803.GF4554@lzapx.brq.redhat.com> Message-ID: <20120719122639.GA25980@dhcp-230-220.rdu.redhat.com> On 19/07/12 11:58 +0200, Lukas Zapletal wrote: >> Maybe I missed this in the thread, but what exactly is required from >> 3.0.15 that is not satisfied by 3.0.10 + CVE patches? >> >> We certainly can go through the exercise to update everything, but it >> will be a moderately involved effort. A concrete justification would be >> good before we dive into that hole. > >I totally share your opinion here. Why would we want to upgrade? If it >works, don't touch it. No, seriously in this case (3.0.10 vs 3.0.15) >there is no added value. We should use the version which is in the >oldest supported Fedora version - which is no Fedora 16. Since it is >still supported, we get security fixes "for free". > >I don't get this "ruby race" of having the latest and greatest versions. >This is what geeks don't do :-) > >My recommendation: > >1) Let's make cross-teams deal we will try to stick with latest Fedora >version stack. Only if it's absolutely needed, let's upgrade, but I >don't see any reason for that. Today it's Fedora 16 rails version, next >upgrade would be to Fedora 17 stack. > >2) Let's not rush with incorporating latest and greatest features. >Sometimes they has very cool things, but let us be realistic. About 10 >new features, 20 bug fixes and 20 new bugs are introduced every release. >We need to deal with all of them. > >3) For now I would recommend to downgrade Foreman. It's not big deal >since we already have Fedora 16 rails builds, it's a matter of testing >it out if it works. > +1 >4) Maybe it's a good time to start discussion about using our shared >koji instance. Currently we have koji instance which builds Katello >only. There is plenty of possibilities how to re-use it for building >Aeolus, Candlepin, Pulp and Foreman. > >-- >Later, > > Lukas "lzap" Zapletal > #katello #systemengine > >_______________________________________________ >katello-devel mailing list >katello-devel at redhat.com >https://www.redhat.com/mailman/listinfo/katello-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From bkearney at redhat.com Thu Jul 19 12:35:02 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 Jul 2012 08:35:02 -0400 Subject: [katello-devel] How should we post objects In-Reply-To: <20120718074924.GB5587@lzapx.brq.redhat.com> References: <4FFEF1F6.9030700@redhat.com> <20120713134649.GB4100@lzapx.brq.redhat.com> <500039CA.20900@redhat.com> <50041941.4070205@redhat.com> <50055873.3090802@redhat.com> <20120718074924.GB5587@lzapx.brq.redhat.com> Message-ID: <5007FEF6.6030605@redhat.com> On 07/18/2012 03:49 AM, Lukas Zapletal wrote: > Uh, I completely missed the doco link: > > https://fedorahosted.org/katello/wiki/APIConventions > > Disregard my first mail, we do wrap! I would suggest to generate the > final API documentation for CFSE V1 (how close are we?) and then we can > start changing it. ok.. i will open up bugs against the same. -- bk From msuchy at redhat.com Thu Jul 19 12:41:04 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Thu, 19 Jul 2012 14:41:04 +0200 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <20120719103610.GG4554@lzapx.brq.redhat.com> References: <5006F35F.60008@redhat.com> <20120719103610.GG4554@lzapx.brq.redhat.com> Message-ID: <50080060.3020508@redhat.com> On 07/19/2012 12:36 PM, Lukas Zapletal wrote: > Nice, but why 30 fps? That's too much. Five to ten is way enough saving > bandwidth so image is ultra-sharp. Here is my recordmydesktop script > (kudos to Jeff Weiss and google.com): > > https://gist.github.com/3142880 Nice. I used recordmydesktop in past. It just work, it has nice gui. Just use "encode later" to avoid problems with sound synchronization. And I uploaded it to youtube as is and youtube did the encoding to webm for me for free. -- Miroslav Suchy Red Hat Systems Management Engineering From jrist at redhat.com Thu Jul 19 13:41:56 2012 From: jrist at redhat.com (Jason Rist) Date: Thu, 19 Jul 2012 07:41:56 -0600 Subject: [katello-devel] Blog? In-Reply-To: <5007F735.8070002@redhat.com> References: <5007F735.8070002@redhat.com> Message-ID: <50080EA4.1000407@redhat.com> On Thu 19 Jul 2012 06:01:57 AM MDT, Bryan Kearney wrote: > Eric, lzap.. how goes the blog ? > > :) > > - bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel We're workin' on it :) -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From omaciel at redhat.com Thu Jul 19 15:02:01 2012 From: omaciel at redhat.com (Og Maciel) Date: Thu, 19 Jul 2012 11:02:01 -0400 (EDT) Subject: [katello-devel] Blog? In-Reply-To: <50080EA4.1000407@redhat.com> Message-ID: fwiw I created a Katello page on Google+ https://plus.google.com/u/1/b/106761937932528197228/106761937932528197228/posts I can add anyone to the "managers" group. -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From lzap at redhat.com Thu Jul 19 16:10:56 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 Jul 2012 18:10:56 +0200 Subject: [katello-devel] Blog? In-Reply-To: References: <50080EA4.1000407@redhat.com> Message-ID: <20120719161055.GK4554@lzapx.brq.redhat.com> Add everybody who follows you and is from the team :-) Followed. LZ On Thu, Jul 19, 2012 at 11:02:01AM -0400, Og Maciel wrote: > fwiw I created a Katello page on Google+ https://plus.google.com/u/1/b/106761937932528197228/106761937932528197228/posts > > I can add anyone to the "managers" group. > -- > Og Maciel > > Senior QA Engineer > Red Hat, Inc. > +1.919.754.4782 > irc: omaciel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From omaciel at redhat.com Thu Jul 19 17:18:28 2012 From: omaciel at redhat.com (Og Maciel) Date: Thu, 19 Jul 2012 13:18:28 -0400 (EDT) Subject: [katello-devel] Blog? In-Reply-To: <20120719161055.GK4554@lzapx.brq.redhat.com> Message-ID: <0953aed2-2206-4877-8cda-cb1d0406937f@zmail11.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Thursday, July 19, 2012 12:10:56 PM > Subject: Re: [katello-devel] Blog? > > Add everybody who follows you and is from the team :-) Unfortunately the interface for adding "managers" requires an email (seems to prefer Gmail too) which has to be entered manually. Just send me your emails and I'll add you. -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From esammons at redhat.com Thu Jul 19 17:23:57 2012 From: esammons at redhat.com (Eric Sammons) Date: Thu, 19 Jul 2012 13:23:57 -0400 (EDT) Subject: [katello-devel] Blog? In-Reply-To: <0953aed2-2206-4877-8cda-cb1d0406937f@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: While I like the idea of the google plus as it increases visibility through yet another medium I do favor the pulp approach. We already have http://katello.org so it seems that we could easily add the blog here. Keeping it all centralized I believe gives the project more credit-ability rather than scattering bits across the internet. Now it may be worth adding g+, like, and tweet options to these projects. And there is no reason that once blogged we couldn't share in the g+ page. My $0.02 --Eric ----- Original Message ----- > ----- Original Message ----- > > From: "Lukas Zapletal" > > To: katello-devel at redhat.com > > Sent: Thursday, July 19, 2012 12:10:56 PM > > Subject: Re: [katello-devel] Blog? > > > > Add everybody who follows you and is from the team :-) > > Unfortunately the interface for adding "managers" requires an email > (seems to prefer Gmail too) which has to be entered manually. Just > send me your emails and I'll add you. > -- > Og Maciel > > Senior QA Engineer > Red Hat, Inc. > +1.919.754.4782 > irc: omaciel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From omaciel at redhat.com Thu Jul 19 17:27:46 2012 From: omaciel at redhat.com (Og Maciel) Date: Thu, 19 Jul 2012 13:27:46 -0400 (EDT) Subject: [katello-devel] Blog? In-Reply-To: Message-ID: Another reason for using Google Plus? Google Hangout session, broadcast LIVE on Youtube to the community, showing off new features, etc :) -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From esammons at redhat.com Thu Jul 19 17:39:08 2012 From: esammons at redhat.com (Eric Sammons) Date: Thu, 19 Jul 2012 13:39:08 -0400 (EDT) Subject: [katello-devel] Blog? In-Reply-To: Message-ID: <730f99b4-69cb-407e-af06-c88f1c0f5ec1@zmail11.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > Another reason for using Google Plus? Google Hangout session, > broadcast LIVE on Youtube to the community, showing off new > features, etc :) > +1 I agree. Though I do not believe g+ takes the place of a blog, g+ is meant to be social, spread the word. So along with all the above reasons and many more, I imagine that when the blog is updated someone could / would go to g+ or click the g+ to share the new blog post. btw, elsammons at gmail.com. --Eric From jrist at redhat.com Thu Jul 19 17:45:53 2012 From: jrist at redhat.com (Jason Rist) Date: Thu, 19 Jul 2012 11:45:53 -0600 Subject: [katello-devel] Blog? In-Reply-To: <730f99b4-69cb-407e-af06-c88f1c0f5ec1@zmail11.collab.prod.int.phx2.redhat.com> References: <730f99b4-69cb-407e-af06-c88f1c0f5ec1@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <500847D1.80907@redhat.com> On Thu 19 Jul 2012 11:39:08 AM MDT, Eric Sammons wrote: > > > ----- Original Message ----- >> Another reason for using Google Plus? Google Hangout session, >> broadcast LIVE on Youtube to the community, showing off new >> features, etc :) >> > > +1 I agree. Though I do not believe g+ takes the place of a blog, g+ is meant to be social, spread the word. So along with all the above reasons and many more, I imagine that when the blog is updated someone could / would go to g+ or click the g+ to share the new blog post. > > btw, elsammons at gmail.com. > > > --Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I'm with Eric - happy to use G+ but don't let it be the primary source of info. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From omaciel at redhat.com Thu Jul 19 17:52:22 2012 From: omaciel at redhat.com (Og Maciel) Date: Thu, 19 Jul 2012 13:52:22 -0400 (EDT) Subject: [katello-devel] Blog? In-Reply-To: <500847D1.80907@redhat.com> Message-ID: > I'm with Eric - happy to use G+ but don't let it be the primary > source > of info. I agree with you both. Not trying to make G+ to be the equivalent of a blog, but to provide a presence in the social media environment. -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From jsherril at redhat.com Thu Jul 19 19:31:13 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 19 Jul 2012 15:31:13 -0400 Subject: [katello-devel] Content Search Merged to master Message-ID: <50086081.3090603@redhat.com> Hi All, The first cut of content search is now in master. You'll need to do a db migrate for a small schema change. It is not 100% feature complete yet, but should be about 95% with the rest on the way shortly. -Justin From jlabocki at redhat.com Thu Jul 19 19:45:13 2012 From: jlabocki at redhat.com (James Labocki) Date: Thu, 19 Jul 2012 15:45:13 -0400 (EDT) Subject: [katello-devel] Content Search Merged to master In-Reply-To: <50086081.3090603@redhat.com> References: <50086081.3090603@redhat.com> Message-ID: <3176A0A9-AE67-49FF-8F19-B3F73603256A@redhat.com> On Jul 19, 2012, at 2:31 PM, Justin Sherrill wrote: > Hi All, > > The first cut of content search is now in master. You'll need to do a db migrate for a small schema change. Will katello-upgrade run the appropriate "db migrate" actions? Or is "db migrate" something else? Pardon my ignorance. > It is not 100% feature complete yet, but should be about 95% with the rest on the way shortly. > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jsherril at redhat.com Thu Jul 19 19:48:01 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 19 Jul 2012 15:48:01 -0400 Subject: [katello-devel] Content Search Merged to master In-Reply-To: <3176A0A9-AE67-49FF-8F19-B3F73603256A@redhat.com> References: <50086081.3090603@redhat.com> <3176A0A9-AE67-49FF-8F19-B3F73603256A@redhat.com> Message-ID: <50086471.9090409@redhat.com> On 07/19/2012 03:45 PM, James Labocki wrote: > > > > On Jul 19, 2012, at 2:31 PM, Justin Sherrill wrote: > >> Hi All, >> >> The first cut of content search is now in master. You'll need to do a db migrate for a small schema change. > Will katello-upgrade run the appropriate "db migrate" actions? Or is "db migrate" something else? Pardon my ignorance. katello-upgrade will run the correct db migrate, but as Og just pointed out it also requires pulp to be shut down. Normally that's ok but this particular migration script requires pulp to be running. I'm gonna look into this ASAP. In the meantime if you are using katello-upgrade, i'd hold off upgrading. > >> It is not 100% feature complete yet, but should be about 95% with the rest on the way shortly. >> >> -Justin >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Thu Jul 19 19:49:14 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 Jul 2012 15:49:14 -0400 Subject: [katello-devel] Content Search Merged to master In-Reply-To: <3176A0A9-AE67-49FF-8F19-B3F73603256A@redhat.com> References: <50086081.3090603@redhat.com> <3176A0A9-AE67-49FF-8F19-B3F73603256A@redhat.com> Message-ID: <500864BA.5040102@redhat.com> On 07/19/2012 03:45 PM, James Labocki wrote: > > > > > On Jul 19, 2012, at 2:31 PM, Justin Sherrill wrote: > >> Hi All, >> >> The first cut of content search is now in master. You'll need to do a db migrate for a small schema change. > > Will katello-upgrade run the appropriate "db migrate" actions? Or is "db migrate" something else? Pardon my ignorance. Yes, it will do the needful. -- bk From omaciel at redhat.com Thu Jul 19 19:55:15 2012 From: omaciel at redhat.com (Og Maciel) Date: Thu, 19 Jul 2012 15:55:15 -0400 (EDT) Subject: [katello-devel] Content Search Merged to master In-Reply-To: <50086471.9090409@redhat.com> Message-ID: <276c22a1-609c-4f98-b6b7-a25e4e0c59d2@zmail11.collab.prod.int.phx2.redhat.com> fwiw I ran the following: katello-service stop then, edit /usr/sbin/katello-upgrade, changing the following line: -BACKEND_SERVICES = ['katello', 'katello-jobs', 'tomcat6', 'pulp-server', 'thumbslug'] +BACKEND_SERVICES = ['katello', 'katello-jobs', 'tomcat6', 'thumbslug'] Then, service pulp-server start service elasticsearch start katello-upgrade -y katello-service start -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From jlabocki at redhat.com Thu Jul 19 20:06:11 2012 From: jlabocki at redhat.com (James Labocki) Date: Thu, 19 Jul 2012 16:06:11 -0400 (EDT) Subject: [katello-devel] Content Search Merged to master In-Reply-To: <276c22a1-609c-4f98-b6b7-a25e4e0c59d2@zmail11.collab.prod.int.phx2.redhat.com> References: <276c22a1-609c-4f98-b6b7-a25e4e0c59d2@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <2109D8D4-0886-4ADA-BC35-9403F75801A0@redhat.com> Sounds like we need another IF statement in there and to split the backed services into separate variables? On Jul 19, 2012, at 2:55 PM, Og Maciel wrote: > fwiw I ran the following: > > katello-service stop > > then, edit /usr/sbin/katello-upgrade, changing the following line: > > -BACKEND_SERVICES = ['katello', 'katello-jobs', 'tomcat6', 'pulp-server', 'thumbslug'] > +BACKEND_SERVICES = ['katello', 'katello-jobs', 'tomcat6', 'thumbslug'] > > Then, > > service pulp-server start > service elasticsearch start > > katello-upgrade -y > katello-service start > -- > Og Maciel > > Senior QA Engineer > Red Hat, Inc. > +1.919.754.4782 > irc: omaciel From bkearney at redhat.com Thu Jul 19 21:01:47 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 Jul 2012 17:01:47 -0400 Subject: [katello-devel] Content Search Merged to master In-Reply-To: <2109D8D4-0886-4ADA-BC35-9403F75801A0@redhat.com> References: <276c22a1-609c-4f98-b6b7-a25e4e0c59d2@zmail11.collab.prod.int.phx2.redhat.com> <2109D8D4-0886-4ADA-BC35-9403F75801A0@redhat.com> Message-ID: <500875BB.5060108@redhat.com> On 07/19/2012 04:06 PM, James Labocki wrote: > Sounds like we need another IF statement in there and to split the backed services into separate variables? > Need to take into consideration Headpin mode vs not. -- bk From jsherril at redhat.com Thu Jul 19 21:25:48 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 19 Jul 2012 17:25:48 -0400 Subject: [katello-devel] Content Search Merged to master In-Reply-To: <50086471.9090409@redhat.com> References: <50086081.3090603@redhat.com> <3176A0A9-AE67-49FF-8F19-B3F73603256A@redhat.com> <50086471.9090409@redhat.com> Message-ID: <50087B5C.7050600@redhat.com> On 07/19/2012 03:48 PM, Justin Sherrill wrote: > On 07/19/2012 03:45 PM, James Labocki wrote: >> >> >> >> On Jul 19, 2012, at 2:31 PM, Justin Sherrill >> wrote: >> >>> Hi All, >>> >>> The first cut of content search is now in master. You'll need to do >>> a db migrate for a small schema change. >> Will katello-upgrade run the appropriate "db migrate" actions? Or is >> "db migrate" something else? Pardon my ignorance. > > katello-upgrade will run the correct db migrate, but as Og just > pointed out it also requires pulp to be shut down. Normally that's ok > but this particular migration script requires pulp to be running. I'm > gonna look into this ASAP. In the meantime if you are using > katello-upgrade, i'd hold off upgrading. > I'm working on fixing this and noticed that the katello migration script is run BEFORE the pulp and candlepin migration scripts in katello-upgrade. This seems backwards to me. Is there a reason for this? For this fix, I'm planning on having the katello migration script start candlepin, pulp, & elastic search prior to the migration. -Justin >> >>> It is not 100% feature complete yet, but should be about 95% with >>> the rest on the way shortly. >>> >>> -Justin >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From pchalupa at redhat.com Fri Jul 20 08:05:30 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Fri, 20 Jul 2012 10:05:30 +0200 Subject: [katello-devel] Blog? In-Reply-To: <5007F735.8070002@redhat.com> References: <5007F735.8070002@redhat.com> Message-ID: <5009114A.6080207@redhat.com> Where is the blog? What about have it in katello on github a generate the blog with Jekyll [1]? Jekyll generates static html which can be placed on github [2] or katello.org. [1] https://github.com/mojombo/jekyll/ [2] https://help.github.com/categories/20/articles Petr On 19.07.12 14:01, Bryan Kearney wrote: > Eric, lzap.. how goes the blog ? > > :) > > - bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From pchalupa at redhat.com Fri Jul 20 10:34:25 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Fri, 20 Jul 2012 12:34:25 +0200 Subject: [katello-devel] Interesting alternative to curl In-Reply-To: <5006F3E6.5080502@redhat.com> References: <5006F3E6.5080502@redhat.com> Message-ID: <50093431.6090905@redhat.com> thanks :) I've just installed and I like it! On 18.07.12 19:35, Justin Sherrill wrote: > https://github.com/jkbr/httpie/#readme > > Looks really neat! > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From ehelms at redhat.com Fri Jul 20 11:22:43 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 20 Jul 2012 07:22:43 -0400 (EDT) Subject: [katello-devel] Blog? In-Reply-To: <5009114A.6080207@redhat.com> Message-ID: <4b409b49-a39c-433c-836e-7876352d9a1e@zmail16.collab.prod.int.phx2.redhat.com> Early week bogged me down, but this is currently in the works with regards to being setup and themed and will be included in an email (hopefully) today that is aimed at overall community improvement planning. ----- Original Message ----- From: "Petr Chalupa" Cc: katello-devel at redhat.com Sent: Friday, July 20, 2012 4:05:30 AM Subject: Re: [katello-devel] Blog? Where is the blog? What about have it in katello on github a generate the blog with Jekyll [1]? Jekyll generates static html which can be placed on github [2] or katello.org. [1] https://github.com/mojombo/jekyll/ [2] https://help.github.com/categories/20/articles Petr On 19.07.12 14:01, Bryan Kearney wrote: > Eric, lzap.. how goes the blog ? > > :) > > - bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From jrist at redhat.com Fri Jul 20 14:24:58 2012 From: jrist at redhat.com (Jason Rist) Date: Fri, 20 Jul 2012 08:24:58 -0600 Subject: [katello-devel] Blog? In-Reply-To: <5009114A.6080207@redhat.com> References: <5007F735.8070002@redhat.com> <5009114A.6080207@redhat.com> Message-ID: <50096A3A.1080105@redhat.com> On 07/20/2012 02:05 AM, Petr Chalupa wrote: > Where is the blog? What about have it in katello on github a generate > the blog with Jekyll [1]? > > Jekyll generates static html which can be placed on github [2] or > katello.org. > > [1] https://github.com/mojombo/jekyll/ > [2] https://help.github.com/categories/20/articles > > Petr > > On 19.07.12 14:01, Bryan Kearney wrote: >> Eric, lzap.. how goes the blog ? >> >> :) >> >> - bk >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel This is a great idea. I think we were talking about using "our own dog food" via OpenShift + Wordpress. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bbuckingham at redhat.com Fri Jul 20 15:49:24 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Fri, 20 Jul 2012 11:49:24 -0400 Subject: [katello-devel] Promotions UI - looking for input on naming Message-ID: <50097E04.2050609@redhat.com> Hey Folks, In the Katello UI, we currently have the following navigation leading to the Promotions page: Content -> Changeset Promotions -> Promotions (page) The current promotions page allows users to create change sets and promote content from the current (e.g. Dev) to next (e.g. Test) environment. We are now in the process of developing functionality to allow users to also delete content from an environment. This functionality will be built in to the current promotions UI; therefore, the UI will now support 2 possible actions (deletions and promotions). As a result, it seems like we should consider the navigation and page. Any thoughts/opinions? Possible renames might be: Content -> Changeset Promotion / Deletion -> Promotions / Deletions Content -> Changeset Management -> Promotions / Deletions Content -> Changesets -> Promotions / Deletions Content -> ... -> ... thanks in advance, Brad From paji at redhat.com Fri Jul 20 15:52:26 2012 From: paji at redhat.com (Partha Aji) Date: Fri, 20 Jul 2012 11:52:26 -0400 (EDT) Subject: [katello-devel] RFE -> Promotion should show only unpromoted packages In-Reply-To: <0878df83-4ea8-4ac5-8128-4e1f7538974a@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <53daddc5-3de8-4438-a238-2b243d89d3c0@zmail14.collab.prod.int.phx2.redhat.com> One of the annoyances with browsing contents in the promotions UI is that shows too many packages including those that have already been promoted. So example scenario is some one promotes a huge product and then want to selectively promote the updated packages, but for that they'll have to navigate through pages and pages to see the few packages that have not been promoted. Recently with some of the data model changes in content search, its now possible to only show packages that have not been promoted. I wonder if it makes sense to have that as the default filter in the promotions page. Another thing to consider here is with Content Deletion we'd want to see all the packages in the current environment, but OTOH with promotions we'd only want to see what has not been previously promoted . Any thoughts ? Partha From cperry at redhat.com Fri Jul 20 15:55:32 2012 From: cperry at redhat.com (Cliff Perry) Date: Fri, 20 Jul 2012 10:55:32 -0500 Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <50097E04.2050609@redhat.com> References: <50097E04.2050609@redhat.com> Message-ID: <50097F74.3060107@redhat.com> On 07/20/2012 10:49 AM, Brad Buckingham wrote: > Hey Folks, > > In the Katello UI, we currently have the following navigation leading to > the Promotions page: > Content -> Changeset Promotions -> Promotions (page) > > The current promotions page allows users to create change sets and > promote content from the current (e.g. Dev) to next (e.g. Test) > environment. > > We are now in the process of developing functionality to allow users to > also delete content from an environment. This functionality will be > built in to the current promotions UI; therefore, the UI will now > support 2 possible actions (deletions and promotions). As a result, it > seems like we should consider the navigation and page. > > Any thoughts/opinions? > > Possible renames might be: > Content -> Changeset Promotion / Deletion -> Promotions / Deletions > Content -> Changeset Management -> Promotions / Deletions I like this one the most ^^^^ Content > Changeset Management > Promotions / Deletions Though 'Promotions / Deletions' seems wrongly worded, it doesn't sound right to me - hurts my ears. Shouldn't it be demotion and promotion? or Additions / Deletions or... Delta Sets :) or... Upgrade / Downgrade I'm sure you picked the word 'deletions' because that is what is happening, without thinking does that term work well with the others in play. Cliff > Content -> Changesets -> Promotions / Deletions > Content -> ... -> ... > > thanks in advance, > Brad > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From taw at redhat.com Fri Jul 20 15:59:57 2012 From: taw at redhat.com (Todd Warner) Date: Fri, 20 Jul 2012 11:59:57 -0400 Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <50097F74.3060107@redhat.com> References: <50097E04.2050609@redhat.com> <50097F74.3060107@redhat.com> Message-ID: <5009807D.6030803@redhat.com> On 07/20/2012 11:55 AM, Cliff Perry wrote: > On 07/20/2012 10:49 AM, Brad Buckingham wrote: >> Hey Folks, >> >> In the Katello UI, we currently have the following navigation leading to >> the Promotions page: >> Content -> Changeset Promotions -> Promotions (page) >> >> The current promotions page allows users to create change sets and >> promote content from the current (e.g. Dev) to next (e.g. Test) >> environment. >> >> We are now in the process of developing functionality to allow users to >> also delete content from an environment. This functionality will be >> built in to the current promotions UI; therefore, the UI will now >> support 2 possible actions (deletions and promotions). As a result, it >> seems like we should consider the navigation and page. >> >> Any thoughts/opinions? >> >> Possible renames might be: >> Content -> Changeset Promotion / Deletion -> Promotions / Deletions >> Content -> Changeset Management -> Promotions / Deletions > > I like this one the most ^^^^ > Content > Changeset Management > Promotions / Deletions > > > Though 'Promotions / Deletions' seems wrongly worded, it doesn't sound > right to me - hurts my ears. > > Shouldn't it be demotion and promotion? > or Additions / Deletions > > or... Delta Sets :) > > or... Upgrade / Downgrade > > I'm sure you picked the word 'deletions' because that is what is > happening, without thinking does that term work well with the others > in play. > > Cliff Yeah. But it is a deletion, right? You are not reverting something and you are not... demoting it. Or are you? It almost seems like two different, unrelated actions. I'm with Cliff... is sounds "square-peggish". I'm not sure and am interested in other folks' opinions. -todd > >> Content -> Changesets -> Promotions / Deletions >> Content -> ... -> ... >> >> thanks in advance, >> Brad >> -- Todd Warner Product Manager, RH Management and Cloud taw at redhat.com - IRC: taw From jrist at redhat.com Fri Jul 20 16:21:11 2012 From: jrist at redhat.com (Jason Rist) Date: Fri, 20 Jul 2012 10:21:11 -0600 Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <5009807D.6030803@redhat.com> References: <50097E04.2050609@redhat.com> <50097F74.3060107@redhat.com> <5009807D.6030803@redhat.com> Message-ID: <50098577.50301@redhat.com> On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: > On 07/20/2012 11:55 AM, Cliff Perry wrote: >> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>> Hey Folks, >>> >>> In the Katello UI, we currently have the following navigation leading to >>> the Promotions page: >>> Content -> Changeset Promotions -> Promotions (page) >>> >>> The current promotions page allows users to create change sets and >>> promote content from the current (e.g. Dev) to next (e.g. Test) >>> environment. >>> >>> We are now in the process of developing functionality to allow users to >>> also delete content from an environment. This functionality will be >>> built in to the current promotions UI; therefore, the UI will now >>> support 2 possible actions (deletions and promotions). As a result, it >>> seems like we should consider the navigation and page. >>> >>> Any thoughts/opinions? >>> >>> Possible renames might be: >>> Content -> Changeset Promotion / Deletion -> Promotions / Deletions >>> Content -> Changeset Management -> Promotions / Deletions >> >> I like this one the most ^^^^ >> Content> Changeset Management> Promotions / Deletions >> >> >> Though 'Promotions / Deletions' seems wrongly worded, it doesn't sound >> right to me - hurts my ears. >> >> Shouldn't it be demotion and promotion? >> or Additions / Deletions >> >> or... Delta Sets :) >> >> or... Upgrade / Downgrade >> >> I'm sure you picked the word 'deletions' because that is what is >> happening, without thinking does that term work well with the others >> in play. >> >> Cliff > > Yeah. But it is a deletion, right? You are not reverting something and > you are not... demoting it. Or are you? It almost seems like two > different, unrelated actions. I'm with Cliff... is sounds > "square-peggish". I'm not sure and am interested in other folks' opinions. > > -todd > >> >>> Content -> Changesets -> Promotions / Deletions >>> Content -> ... -> ... >>> >>> thanks in advance, >>> Brad >>> > I think I like "Changeset Management -> Promotions and Deletions" -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bkearney at redhat.com Fri Jul 20 16:35:36 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 20 Jul 2012 12:35:36 -0400 Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <50098577.50301@redhat.com> References: <50097E04.2050609@redhat.com> <50097F74.3060107@redhat.com> <5009807D.6030803@redhat.com> <50098577.50301@redhat.com> Message-ID: <500988D8.2040600@redhat.com> On 07/20/2012 12:21 PM, Jason Rist wrote: > On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>> Hey Folks, >>>> >>>> In the Katello UI, we currently have the following navigation >>>> leading to >>>> the Promotions page: >>>> Content -> Changeset Promotions -> Promotions (page) >>>> >>>> The current promotions page allows users to create change sets and >>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>> environment. >>>> >>>> We are now in the process of developing functionality to allow users to >>>> also delete content from an environment. This functionality will be >>>> built in to the current promotions UI; therefore, the UI will now >>>> support 2 possible actions (deletions and promotions). As a result, it >>>> seems like we should consider the navigation and page. >>>> >>>> Any thoughts/opinions? >>>> >>>> Possible renames might be: >>>> Content -> Changeset Promotion / Deletion -> Promotions / Deletions >>>> Content -> Changeset Management -> Promotions / Deletions >>> >>> I like this one the most ^^^^ >>> Content> Changeset Management> Promotions / Deletions >>> >>> >>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't sound >>> right to me - hurts my ears. >>> >>> Shouldn't it be demotion and promotion? >>> or Additions / Deletions >>> >>> or... Delta Sets :) >>> >>> or... Upgrade / Downgrade >>> >>> I'm sure you picked the word 'deletions' because that is what is >>> happening, without thinking does that term work well with the others >>> in play. >>> >>> Cliff >> >> Yeah. But it is a deletion, right? You are not reverting something and >> you are not... demoting it. Or are you? It almost seems like two >> different, unrelated actions. I'm with Cliff... is sounds >> "square-peggish". I'm not sure and am interested in other folks' >> opinions. >> >> -todd >> >>> >>>> Content -> Changesets -> Promotions / Deletions >>>> Content -> ... -> ... >>>> >>>> thanks in advance, >>>> Brad >>>> >> > > I think I like "Changeset Management -> Promotions and Deletions" > > -J > +1 -- bk From mmccune at redhat.com Fri Jul 20 16:45:34 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 20 Jul 2012 09:45:34 -0700 Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <50098577.50301@redhat.com> References: <50097E04.2050609@redhat.com> <50097F74.3060107@redhat.com> <5009807D.6030803@redhat.com> <50098577.50301@redhat.com> Message-ID: <50098B2E.9060907@redhat.com> On 07/20/2012 09:21 AM, Jason Rist wrote: > On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>> Hey Folks, >>>> >>>> In the Katello UI, we currently have the following navigation leading to >>>> the Promotions page: >>>> Content -> Changeset Promotions -> Promotions (page) >>>> >>>> The current promotions page allows users to create change sets and >>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>> environment. >>>> >>>> We are now in the process of developing functionality to allow users to >>>> also delete content from an environment. This functionality will be >>>> built in to the current promotions UI; therefore, the UI will now >>>> support 2 possible actions (deletions and promotions). As a result, it >>>> seems like we should consider the navigation and page. >>>> >>>> Any thoughts/opinions? >>>> >>>> Possible renames might be: >>>> Content -> Changeset Promotion / Deletion -> Promotions / Deletions >>>> Content -> Changeset Management -> Promotions / Deletions >>> >>> I like this one the most ^^^^ >>> Content> Changeset Management> Promotions / Deletions >>> >>> >>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't sound >>> right to me - hurts my ears. >>> >>> Shouldn't it be demotion and promotion? >>> or Additions / Deletions >>> >>> or... Delta Sets :) >>> >>> or... Upgrade / Downgrade >>> >>> I'm sure you picked the word 'deletions' because that is what is >>> happening, without thinking does that term work well with the others >>> in play. >>> >>> Cliff >> >> Yeah. But it is a deletion, right? You are not reverting something and >> you are not... demoting it. Or are you? It almost seems like two >> different, unrelated actions. I'm with Cliff... is sounds >> "square-peggish". I'm not sure and am interested in other folks' opinions. >> >> -todd >> >>> >>>> Content -> Changesets -> Promotions / Deletions >>>> Content -> ... -> ... >>>> >>>> thanks in advance, >>>> Brad >>>> >> > > I think I like "Changeset Management -> Promotions and Deletions" > what about just: Content -> Changesets why put the type in the title? that said, I do like the clarity of Promotions and Deletions because it helps explain a bit to new users what changesets do. Mike From taw at redhat.com Fri Jul 20 16:51:05 2012 From: taw at redhat.com (Todd Warner) Date: Fri, 20 Jul 2012 12:51:05 -0400 Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <50098B2E.9060907@redhat.com> References: <50097E04.2050609@redhat.com> <50097F74.3060107@redhat.com> <5009807D.6030803@redhat.com> <50098577.50301@redhat.com> <50098B2E.9060907@redhat.com> Message-ID: <50098C79.5050606@redhat.com> On 07/20/2012 12:45 PM, Mike McCune wrote: > On 07/20/2012 09:21 AM, Jason Rist wrote: >> On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >>> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>>> Hey Folks, >>>>> >>>>> In the Katello UI, we currently have the following navigation >>>>> leading to >>>>> the Promotions page: >>>>> Content -> Changeset Promotions -> Promotions (page) >>>>> >>>>> The current promotions page allows users to create change sets and >>>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>>> environment. >>>>> >>>>> We are now in the process of developing functionality to allow >>>>> users to >>>>> also delete content from an environment. This functionality will be >>>>> built in to the current promotions UI; therefore, the UI will now >>>>> support 2 possible actions (deletions and promotions). As a >>>>> result, it >>>>> seems like we should consider the navigation and page. >>>>> >>>>> Any thoughts/opinions? >>>>> >>>>> Possible renames might be: >>>>> Content -> Changeset Promotion / Deletion -> Promotions / >>>>> Deletions >>>>> Content -> Changeset Management -> Promotions / Deletions >>>> >>>> I like this one the most ^^^^ >>>> Content> Changeset Management> Promotions / Deletions >>>> >>>> >>>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't sound >>>> right to me - hurts my ears. >>>> >>>> Shouldn't it be demotion and promotion? >>>> or Additions / Deletions >>>> >>>> or... Delta Sets :) >>>> >>>> or... Upgrade / Downgrade >>>> >>>> I'm sure you picked the word 'deletions' because that is what is >>>> happening, without thinking does that term work well with the others >>>> in play. >>>> >>>> Cliff >>> >>> Yeah. But it is a deletion, right? You are not reverting something and >>> you are not... demoting it. Or are you? It almost seems like two >>> different, unrelated actions. I'm with Cliff... is sounds >>> "square-peggish". I'm not sure and am interested in other folks' >>> opinions. >>> >>> -todd >>> >>>> >>>>> Content -> Changesets -> Promotions / Deletions >>>>> Content -> ... -> ... >>>>> >>>>> thanks in advance, >>>>> Brad >>>>> >>> >> >> I think I like "Changeset Management -> Promotions and Deletions" >> > > what about just: > > Content -> Changesets > > why put the type in the title? YES! > > that said, I do like the clarity of Promotions and Deletions because > it helps explain a bit to new users what changesets do. Shove "what changeset do" into contextual help? -todd -- Todd Warner Product Manager, RH Management and Cloud taw at redhat.com - IRC: taw From mrao at redhat.com Fri Jul 20 17:02:26 2012 From: mrao at redhat.com (Malini Rao) Date: Fri, 20 Jul 2012 13:02:26 -0400 (EDT) Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <50098C79.5050606@redhat.com> Message-ID: <0eb9e7ac-b94c-4d2e-baa7-26954916917a@zmail12.collab.prod.int.phx2.redhat.com> My suggestion would be - Content -> Changeset Management -> Changesets & Content -> Changeset Management -> Changesets History Thanks Malini ----- Original Message ----- From: "Todd Warner" To: "Mike McCune" Cc: katello-devel at redhat.com Sent: Friday, July 20, 2012 12:51:05 PM Subject: Re: [katello-devel] Promotions UI - looking for input on naming On 07/20/2012 12:45 PM, Mike McCune wrote: > On 07/20/2012 09:21 AM, Jason Rist wrote: >> On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >>> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>>> Hey Folks, >>>>> >>>>> In the Katello UI, we currently have the following navigation >>>>> leading to >>>>> the Promotions page: >>>>> Content -> Changeset Promotions -> Promotions (page) >>>>> >>>>> The current promotions page allows users to create change sets and >>>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>>> environment. >>>>> >>>>> We are now in the process of developing functionality to allow >>>>> users to >>>>> also delete content from an environment. This functionality will be >>>>> built in to the current promotions UI; therefore, the UI will now >>>>> support 2 possible actions (deletions and promotions). As a >>>>> result, it >>>>> seems like we should consider the navigation and page. >>>>> >>>>> Any thoughts/opinions? >>>>> >>>>> Possible renames might be: >>>>> Content -> Changeset Promotion / Deletion -> Promotions / >>>>> Deletions >>>>> Content -> Changeset Management -> Promotions / Deletions >>>> >>>> I like this one the most ^^^^ >>>> Content> Changeset Management> Promotions / Deletions >>>> >>>> >>>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't sound >>>> right to me - hurts my ears. >>>> >>>> Shouldn't it be demotion and promotion? >>>> or Additions / Deletions >>>> >>>> or... Delta Sets :) >>>> >>>> or... Upgrade / Downgrade >>>> >>>> I'm sure you picked the word 'deletions' because that is what is >>>> happening, without thinking does that term work well with the others >>>> in play. >>>> >>>> Cliff >>> >>> Yeah. But it is a deletion, right? You are not reverting something and >>> you are not... demoting it. Or are you? It almost seems like two >>> different, unrelated actions. I'm with Cliff... is sounds >>> "square-peggish". I'm not sure and am interested in other folks' >>> opinions. >>> >>> -todd >>> >>>> >>>>> Content -> Changesets -> Promotions / Deletions >>>>> Content -> ... -> ... >>>>> >>>>> thanks in advance, >>>>> Brad >>>>> >>> >> >> I think I like "Changeset Management -> Promotions and Deletions" >> > > what about just: > > Content -> Changesets > > why put the type in the title? YES! > > that said, I do like the clarity of Promotions and Deletions because > it helps explain a bit to new users what changesets do. Shove "what changeset do" into contextual help? -todd -- Todd Warner Product Manager, RH Management and Cloud taw at redhat.com - IRC: taw _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From bbuckingham at redhat.com Fri Jul 20 17:17:48 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Fri, 20 Jul 2012 13:17:48 -0400 Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <0eb9e7ac-b94c-4d2e-baa7-26954916917a@zmail12.collab.prod.int.phx2.redhat.com> References: <0eb9e7ac-b94c-4d2e-baa7-26954916917a@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <500992BC.4000005@redhat.com> You all are awesome! Appreciate the quick feedback. I am going to let the thread go for additional inputs until early next week; however, I also lean towards the latest suggestion, which I believe captures most folks intent. i.e. Content -> Changeset Management -> Changesets Content -> Changeset Management -> Changesets History (This one also exists in the UI. It was not in my original email, but does show that we need to have the 3rd level). Cliff, To your earlier question on thread, the new feature is not a demotion of content but an actual deletion of the content from the current environment. Example scenario: - user goes to the Changesets page (aka Promotions today) - navigates to an environment (e.g. Dev) - creates a Deletion Changeset - adds content to the Changeset (e.g. products, repos, packages...etc) - user 'applies' the Changeset (and content in changeset is deleted from that environment) - any environment before or after that environment remain unchanged thanks, Brad On 07/20/2012 01:02 PM, Malini Rao wrote: > My suggestion would be - > Content -> Changeset Management -> Changesets > > & > > Content -> Changeset Management -> Changesets History > > > Thanks > Malini > > ----- Original Message ----- > From: "Todd Warner" > To: "Mike McCune" > Cc: katello-devel at redhat.com > Sent: Friday, July 20, 2012 12:51:05 PM > Subject: Re: [katello-devel] Promotions UI - looking for input on naming > > On 07/20/2012 12:45 PM, Mike McCune wrote: >> On 07/20/2012 09:21 AM, Jason Rist wrote: >>> On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >>>> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>>>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>>>> Hey Folks, >>>>>> >>>>>> In the Katello UI, we currently have the following navigation >>>>>> leading to >>>>>> the Promotions page: >>>>>> Content -> Changeset Promotions -> Promotions (page) >>>>>> >>>>>> The current promotions page allows users to create change sets and >>>>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>>>> environment. >>>>>> >>>>>> We are now in the process of developing functionality to allow >>>>>> users to >>>>>> also delete content from an environment. This functionality will be >>>>>> built in to the current promotions UI; therefore, the UI will now >>>>>> support 2 possible actions (deletions and promotions). As a >>>>>> result, it >>>>>> seems like we should consider the navigation and page. >>>>>> >>>>>> Any thoughts/opinions? >>>>>> >>>>>> Possible renames might be: >>>>>> Content -> Changeset Promotion / Deletion -> Promotions / >>>>>> Deletions >>>>>> Content -> Changeset Management -> Promotions / Deletions >>>>> I like this one the most ^^^^ >>>>> Content> Changeset Management> Promotions / Deletions >>>>> >>>>> >>>>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't sound >>>>> right to me - hurts my ears. >>>>> >>>>> Shouldn't it be demotion and promotion? >>>>> or Additions / Deletions >>>>> >>>>> or... Delta Sets :) >>>>> >>>>> or... Upgrade / Downgrade >>>>> >>>>> I'm sure you picked the word 'deletions' because that is what is >>>>> happening, without thinking does that term work well with the others >>>>> in play. >>>>> >>>>> Cliff >>>> Yeah. But it is a deletion, right? You are not reverting something and >>>> you are not... demoting it. Or are you? It almost seems like two >>>> different, unrelated actions. I'm with Cliff... is sounds >>>> "square-peggish". I'm not sure and am interested in other folks' >>>> opinions. >>>> >>>> -todd >>>> >>>>>> Content -> Changesets -> Promotions / Deletions >>>>>> Content -> ... -> ... >>>>>> >>>>>> thanks in advance, >>>>>> Brad >>>>>> >>> I think I like "Changeset Management -> Promotions and Deletions" >>> >> what about just: >> >> Content -> Changesets >> >> why put the type in the title? > YES! > >> that said, I do like the clarity of Promotions and Deletions because >> it helps explain a bit to new users what changesets do. > Shove "what changeset do" into contextual help? > -todd > From ehelms at redhat.com Fri Jul 20 17:32:07 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 20 Jul 2012 13:32:07 -0400 (EDT) Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <500992BC.4000005@redhat.com> Message-ID: <889d7c15-5503-4f23-a324-b79d541007fa@zmail16.collab.prod.int.phx2.redhat.com> +1 to Changeset Mangement -> Changesets I prefer that we keep our current convention of navigation pointing to entities and not actions. Let the actions come about once a user has landed on the entities page. - Eric ----- Original Message ----- From: "Brad Buckingham" To: katello-devel at redhat.com Sent: Friday, July 20, 2012 1:17:48 PM Subject: Re: [katello-devel] Promotions UI - looking for input on naming You all are awesome! Appreciate the quick feedback. I am going to let the thread go for additional inputs until early next week; however, I also lean towards the latest suggestion, which I believe captures most folks intent. i.e. Content -> Changeset Management -> Changesets Content -> Changeset Management -> Changesets History (This one also exists in the UI. It was not in my original email, but does show that we need to have the 3rd level). Cliff, To your earlier question on thread, the new feature is not a demotion of content but an actual deletion of the content from the current environment. Example scenario: - user goes to the Changesets page (aka Promotions today) - navigates to an environment (e.g. Dev) - creates a Deletion Changeset - adds content to the Changeset (e.g. products, repos, packages...etc) - user 'applies' the Changeset (and content in changeset is deleted from that environment) - any environment before or after that environment remain unchanged thanks, Brad On 07/20/2012 01:02 PM, Malini Rao wrote: > My suggestion would be - > Content -> Changeset Management -> Changesets > > & > > Content -> Changeset Management -> Changesets History > > > Thanks > Malini > > ----- Original Message ----- > From: "Todd Warner" > To: "Mike McCune" > Cc: katello-devel at redhat.com > Sent: Friday, July 20, 2012 12:51:05 PM > Subject: Re: [katello-devel] Promotions UI - looking for input on naming > > On 07/20/2012 12:45 PM, Mike McCune wrote: >> On 07/20/2012 09:21 AM, Jason Rist wrote: >>> On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >>>> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>>>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>>>> Hey Folks, >>>>>> >>>>>> In the Katello UI, we currently have the following navigation >>>>>> leading to >>>>>> the Promotions page: >>>>>> Content -> Changeset Promotions -> Promotions (page) >>>>>> >>>>>> The current promotions page allows users to create change sets and >>>>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>>>> environment. >>>>>> >>>>>> We are now in the process of developing functionality to allow >>>>>> users to >>>>>> also delete content from an environment. This functionality will be >>>>>> built in to the current promotions UI; therefore, the UI will now >>>>>> support 2 possible actions (deletions and promotions). As a >>>>>> result, it >>>>>> seems like we should consider the navigation and page. >>>>>> >>>>>> Any thoughts/opinions? >>>>>> >>>>>> Possible renames might be: >>>>>> Content -> Changeset Promotion / Deletion -> Promotions / >>>>>> Deletions >>>>>> Content -> Changeset Management -> Promotions / Deletions >>>>> I like this one the most ^^^^ >>>>> Content> Changeset Management> Promotions / Deletions >>>>> >>>>> >>>>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't sound >>>>> right to me - hurts my ears. >>>>> >>>>> Shouldn't it be demotion and promotion? >>>>> or Additions / Deletions >>>>> >>>>> or... Delta Sets :) >>>>> >>>>> or... Upgrade / Downgrade >>>>> >>>>> I'm sure you picked the word 'deletions' because that is what is >>>>> happening, without thinking does that term work well with the others >>>>> in play. >>>>> >>>>> Cliff >>>> Yeah. But it is a deletion, right? You are not reverting something and >>>> you are not... demoting it. Or are you? It almost seems like two >>>> different, unrelated actions. I'm with Cliff... is sounds >>>> "square-peggish". I'm not sure and am interested in other folks' >>>> opinions. >>>> >>>> -todd >>>> >>>>>> Content -> Changesets -> Promotions / Deletions >>>>>> Content -> ... -> ... >>>>>> >>>>>> thanks in advance, >>>>>> Brad >>>>>> >>> I think I like "Changeset Management -> Promotions and Deletions" >>> >> what about just: >> >> Content -> Changesets >> >> why put the type in the title? > YES! > >> that said, I do like the clarity of Promotions and Deletions because >> it helps explain a bit to new users what changesets do. > Shove "what changeset do" into contextual help? > -todd > _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From omaciel at redhat.com Fri Jul 20 17:33:52 2012 From: omaciel at redhat.com (Og Maciel) Date: Fri, 20 Jul 2012 13:33:52 -0400 (EDT) Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <50098B2E.9060907@redhat.com> Message-ID: <6c10b026-b511-4e42-98bc-e55afb783e6d@zmail11.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Mike McCune" > To: jrist at redhat.com > Cc: katello-devel at redhat.com > Sent: Friday, July 20, 2012 12:45:34 PM > Subject: Re: [katello-devel] Promotions UI - looking for input on naming > what about just: > > Content -> Changesets +1 -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From cperry at redhat.com Fri Jul 20 17:37:01 2012 From: cperry at redhat.com (Cliff Perry) Date: Fri, 20 Jul 2012 12:37:01 -0500 Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <500992BC.4000005@redhat.com> References: <0eb9e7ac-b94c-4d2e-baa7-26954916917a@zmail12.collab.prod.int.phx2.redhat.com> <500992BC.4000005@redhat.com> Message-ID: <5009973D.2000000@redhat.com> On 07/20/2012 12:17 PM, Brad Buckingham wrote: > You all are awesome! Appreciate the quick feedback. > > I am going to let the thread go for additional inputs until early next > week; however, I also lean > towards the latest suggestion, which I believe captures most folks intent. > > i.e. > > Content -> Changeset Management -> Changesets > > Content -> Changeset Management -> Changesets History (This one also > exists in the UI. It was not in my original email, but does show that we > need to have the 3rd level). > I like those ^^^ > > Cliff, > > To your earlier question on thread, the new feature is not a demotion of > content but an actual deletion of the content from the current > environment. Example scenario: > - user goes to the Changesets page (aka Promotions today) > - navigates to an environment (e.g. Dev) > - creates a Deletion Changeset > - adds content to the Changeset (e.g. products, repos, packages...etc) > - user 'applies' the Changeset (and content in changeset is deleted from > that environment) > - any environment before or after that environment remain unchanged I find it inconsistent that the package/content could be further up the environment path... but that is not what is being asked for here :) Well... Library holds all content, content in environments has to be in library. When you populate content into an environment, we call it today a 'promotion'. Well, that promotion today ADDs content, it is an addition, that we choose to give a fancier word, Promotion. So, when you delete the content from the 'DEV' environment, shouldn't we give it the same fancier word - demotion. It is the same net-effect, the package is removed (removed/deleted/demoted/foreclosed) . :) I'm not a UDX type guy. I just think the terminology should be consistent and won't argue the point further in this thread (I given the input which was asked ;) Cliff > thanks, > Brad > > On 07/20/2012 01:02 PM, Malini Rao wrote: >> My suggestion would be - >> Content -> Changeset Management -> Changesets >> >> & >> >> Content -> Changeset Management -> Changesets History >> >> >> Thanks >> Malini >> >> ----- Original Message ----- >> From: "Todd Warner" >> To: "Mike McCune" >> Cc: katello-devel at redhat.com >> Sent: Friday, July 20, 2012 12:51:05 PM >> Subject: Re: [katello-devel] Promotions UI - looking for input on naming >> >> On 07/20/2012 12:45 PM, Mike McCune wrote: >>> On 07/20/2012 09:21 AM, Jason Rist wrote: >>>> On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >>>>> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>>>>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>>>>> Hey Folks, >>>>>>> >>>>>>> In the Katello UI, we currently have the following navigation >>>>>>> leading to >>>>>>> the Promotions page: >>>>>>> Content -> Changeset Promotions -> Promotions (page) >>>>>>> >>>>>>> The current promotions page allows users to create change sets and >>>>>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>>>>> environment. >>>>>>> >>>>>>> We are now in the process of developing functionality to allow >>>>>>> users to >>>>>>> also delete content from an environment. This functionality will be >>>>>>> built in to the current promotions UI; therefore, the UI will now >>>>>>> support 2 possible actions (deletions and promotions). As a >>>>>>> result, it >>>>>>> seems like we should consider the navigation and page. >>>>>>> >>>>>>> Any thoughts/opinions? >>>>>>> >>>>>>> Possible renames might be: >>>>>>> Content -> Changeset Promotion / Deletion -> Promotions / >>>>>>> Deletions >>>>>>> Content -> Changeset Management -> Promotions / Deletions >>>>>> I like this one the most ^^^^ >>>>>> Content> Changeset Management> Promotions / Deletions >>>>>> >>>>>> >>>>>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't >>>>>> sound >>>>>> right to me - hurts my ears. >>>>>> >>>>>> Shouldn't it be demotion and promotion? >>>>>> or Additions / Deletions >>>>>> >>>>>> or... Delta Sets :) >>>>>> >>>>>> or... Upgrade / Downgrade >>>>>> >>>>>> I'm sure you picked the word 'deletions' because that is what is >>>>>> happening, without thinking does that term work well with the others >>>>>> in play. >>>>>> >>>>>> Cliff >>>>> Yeah. But it is a deletion, right? You are not reverting something and >>>>> you are not... demoting it. Or are you? It almost seems like two >>>>> different, unrelated actions. I'm with Cliff... is sounds >>>>> "square-peggish". I'm not sure and am interested in other folks' >>>>> opinions. >>>>> >>>>> -todd >>>>> >>>>>>> Content -> Changesets -> Promotions / Deletions >>>>>>> Content -> ... -> ... >>>>>>> >>>>>>> thanks in advance, >>>>>>> Brad >>>>>>> >>>> I think I like "Changeset Management -> Promotions and Deletions" >>>> >>> what about just: >>> >>> Content -> Changesets >>> >>> why put the type in the title? >> YES! >> >>> that said, I do like the clarity of Promotions and Deletions because >>> it helps explain a bit to new users what changesets do. >> Shove "what changeset do" into contextual help? >> -todd >> > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mrao at redhat.com Fri Jul 20 17:57:33 2012 From: mrao at redhat.com (Malini Rao) Date: Fri, 20 Jul 2012 13:57:33 -0400 (EDT) Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <889d7c15-5503-4f23-a324-b79d541007fa@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <78330fd8-649d-452f-a51b-b8abc63e31b9@zmail12.collab.prod.int.phx2.redhat.com> Exactly! ----- Original Message ----- From: "Eric Helms" To: katello-devel at redhat.com Sent: Friday, July 20, 2012 1:32:07 PM Subject: Re: [katello-devel] Promotions UI - looking for input on naming +1 to Changeset Mangement -> Changesets I prefer that we keep our current convention of navigation pointing to entities and not actions. Let the actions come about once a user has landed on the entities page. - Eric ----- Original Message ----- From: "Brad Buckingham" To: katello-devel at redhat.com Sent: Friday, July 20, 2012 1:17:48 PM Subject: Re: [katello-devel] Promotions UI - looking for input on naming You all are awesome! Appreciate the quick feedback. I am going to let the thread go for additional inputs until early next week; however, I also lean towards the latest suggestion, which I believe captures most folks intent. i.e. Content -> Changeset Management -> Changesets Content -> Changeset Management -> Changesets History (This one also exists in the UI. It was not in my original email, but does show that we need to have the 3rd level). Cliff, To your earlier question on thread, the new feature is not a demotion of content but an actual deletion of the content from the current environment. Example scenario: - user goes to the Changesets page (aka Promotions today) - navigates to an environment (e.g. Dev) - creates a Deletion Changeset - adds content to the Changeset (e.g. products, repos, packages...etc) - user 'applies' the Changeset (and content in changeset is deleted from that environment) - any environment before or after that environment remain unchanged thanks, Brad On 07/20/2012 01:02 PM, Malini Rao wrote: > My suggestion would be - > Content -> Changeset Management -> Changesets > > & > > Content -> Changeset Management -> Changesets History > > > Thanks > Malini > > ----- Original Message ----- > From: "Todd Warner" > To: "Mike McCune" > Cc: katello-devel at redhat.com > Sent: Friday, July 20, 2012 12:51:05 PM > Subject: Re: [katello-devel] Promotions UI - looking for input on naming > > On 07/20/2012 12:45 PM, Mike McCune wrote: >> On 07/20/2012 09:21 AM, Jason Rist wrote: >>> On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >>>> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>>>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>>>> Hey Folks, >>>>>> >>>>>> In the Katello UI, we currently have the following navigation >>>>>> leading to >>>>>> the Promotions page: >>>>>> Content -> Changeset Promotions -> Promotions (page) >>>>>> >>>>>> The current promotions page allows users to create change sets and >>>>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>>>> environment. >>>>>> >>>>>> We are now in the process of developing functionality to allow >>>>>> users to >>>>>> also delete content from an environment. This functionality will be >>>>>> built in to the current promotions UI; therefore, the UI will now >>>>>> support 2 possible actions (deletions and promotions). As a >>>>>> result, it >>>>>> seems like we should consider the navigation and page. >>>>>> >>>>>> Any thoughts/opinions? >>>>>> >>>>>> Possible renames might be: >>>>>> Content -> Changeset Promotion / Deletion -> Promotions / >>>>>> Deletions >>>>>> Content -> Changeset Management -> Promotions / Deletions >>>>> I like this one the most ^^^^ >>>>> Content> Changeset Management> Promotions / Deletions >>>>> >>>>> >>>>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't sound >>>>> right to me - hurts my ears. >>>>> >>>>> Shouldn't it be demotion and promotion? >>>>> or Additions / Deletions >>>>> >>>>> or... Delta Sets :) >>>>> >>>>> or... Upgrade / Downgrade >>>>> >>>>> I'm sure you picked the word 'deletions' because that is what is >>>>> happening, without thinking does that term work well with the others >>>>> in play. >>>>> >>>>> Cliff >>>> Yeah. But it is a deletion, right? You are not reverting something and >>>> you are not... demoting it. Or are you? It almost seems like two >>>> different, unrelated actions. I'm with Cliff... is sounds >>>> "square-peggish". I'm not sure and am interested in other folks' >>>> opinions. >>>> >>>> -todd >>>> >>>>>> Content -> Changesets -> Promotions / Deletions >>>>>> Content -> ... -> ... >>>>>> >>>>>> thanks in advance, >>>>>> Brad >>>>>> >>> I think I like "Changeset Management -> Promotions and Deletions" >>> >> what about just: >> >> Content -> Changesets >> >> why put the type in the title? > YES! > >> that said, I do like the clarity of Promotions and Deletions because >> it helps explain a bit to new users what changesets do. > Shove "what changeset do" into contextual help? > -todd > _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From mrao at redhat.com Fri Jul 20 18:13:24 2012 From: mrao at redhat.com (Malini Rao) Date: Fri, 20 Jul 2012 14:13:24 -0400 (EDT) Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <5009973D.2000000@redhat.com> Message-ID: <39e0b11f-10f5-4d01-9b3a-bae671b15f85@zmail12.collab.prod.int.phx2.redhat.com> ----- Original Message ----- From: "Cliff Perry" To: "Brad Buckingham" Cc: katello-devel at redhat.com Sent: Friday, July 20, 2012 1:37:01 PM Subject: Re: [katello-devel] Promotions UI - looking for input on naming On 07/20/2012 12:17 PM, Brad Buckingham wrote: > You all are awesome! Appreciate the quick feedback. > > I am going to let the thread go for additional inputs until early next > week; however, I also lean > towards the latest suggestion, which I believe captures most folks intent. > > i.e. > > Content -> Changeset Management -> Changesets > > Content -> Changeset Management -> Changesets History (This one also > exists in the UI. It was not in my original email, but does show that we > need to have the 3rd level). > I like those ^^^ > > Cliff, > > To your earlier question on thread, the new feature is not a demotion of > content but an actual deletion of the content from the current > environment. Example scenario: > - user goes to the Changesets page (aka Promotions today) > - navigates to an environment (e.g. Dev) > - creates a Deletion Changeset > - adds content to the Changeset (e.g. products, repos, packages...etc) > - user 'applies' the Changeset (and content in changeset is deleted from > that environment) > - any environment before or after that environment remain unchanged I find it inconsistent that the package/content could be further up the environment path... but that is not what is being asked for here :) Well... Library holds all content, content in environments has to be in library. When you populate content into an environment, we call it today a 'promotion'. Well, that promotion today ADDs content, it is an addition, that we choose to give a fancier word, Promotion. So, when you delete the content from the 'DEV' environment, shouldn't we give it the same fancier word - demotion. It is the same net-effect, the package is removed (removed/deleted/demoted/foreclosed) . :) I'm not a UDX type guy. I just think the terminology should be consistent and won't argue the point further in this thread (I given the input which was asked ;) Cliff Malini ---> Cliff, I see your train of thought here and your input is valuable. The issue is about whether the term sets an expectation in the user that something is moved FROM somewhere TO somewhere when that may not be the case in the case of removing content from an environment. In the end, these will most likely end up as button labels and we can all see what term resonates best when we see it in the context of a mock-up. > thanks, > Brad > > On 07/20/2012 01:02 PM, Malini Rao wrote: >> My suggestion would be - >> Content -> Changeset Management -> Changesets >> >> & >> >> Content -> Changeset Management -> Changesets History >> >> >> Thanks >> Malini >> >> ----- Original Message ----- >> From: "Todd Warner" >> To: "Mike McCune" >> Cc: katello-devel at redhat.com >> Sent: Friday, July 20, 2012 12:51:05 PM >> Subject: Re: [katello-devel] Promotions UI - looking for input on naming >> >> On 07/20/2012 12:45 PM, Mike McCune wrote: >>> On 07/20/2012 09:21 AM, Jason Rist wrote: >>>> On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >>>>> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>>>>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>>>>> Hey Folks, >>>>>>> >>>>>>> In the Katello UI, we currently have the following navigation >>>>>>> leading to >>>>>>> the Promotions page: >>>>>>> Content -> Changeset Promotions -> Promotions (page) >>>>>>> >>>>>>> The current promotions page allows users to create change sets and >>>>>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>>>>> environment. >>>>>>> >>>>>>> We are now in the process of developing functionality to allow >>>>>>> users to >>>>>>> also delete content from an environment. This functionality will be >>>>>>> built in to the current promotions UI; therefore, the UI will now >>>>>>> support 2 possible actions (deletions and promotions). As a >>>>>>> result, it >>>>>>> seems like we should consider the navigation and page. >>>>>>> >>>>>>> Any thoughts/opinions? >>>>>>> >>>>>>> Possible renames might be: >>>>>>> Content -> Changeset Promotion / Deletion -> Promotions / >>>>>>> Deletions >>>>>>> Content -> Changeset Management -> Promotions / Deletions >>>>>> I like this one the most ^^^^ >>>>>> Content> Changeset Management> Promotions / Deletions >>>>>> >>>>>> >>>>>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't >>>>>> sound >>>>>> right to me - hurts my ears. >>>>>> >>>>>> Shouldn't it be demotion and promotion? >>>>>> or Additions / Deletions >>>>>> >>>>>> or... Delta Sets :) >>>>>> >>>>>> or... Upgrade / Downgrade >>>>>> >>>>>> I'm sure you picked the word 'deletions' because that is what is >>>>>> happening, without thinking does that term work well with the others >>>>>> in play. >>>>>> >>>>>> Cliff >>>>> Yeah. But it is a deletion, right? You are not reverting something and >>>>> you are not... demoting it. Or are you? It almost seems like two >>>>> different, unrelated actions. I'm with Cliff... is sounds >>>>> "square-peggish". I'm not sure and am interested in other folks' >>>>> opinions. >>>>> >>>>> -todd >>>>> >>>>>>> Content -> Changesets -> Promotions / Deletions >>>>>>> Content -> ... -> ... >>>>>>> >>>>>>> thanks in advance, >>>>>>> Brad >>>>>>> >>>> I think I like "Changeset Management -> Promotions and Deletions" >>>> >>> what about just: >>> >>> Content -> Changesets >>> >>> why put the type in the title? >> YES! >> >>> that said, I do like the clarity of Promotions and Deletions because >>> it helps explain a bit to new users what changesets do. >> Shove "what changeset do" into contextual help? >> -todd >> > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Fri Jul 20 18:30:37 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 20 Jul 2012 11:30:37 -0700 Subject: [katello-devel] RFE -> Promotion should show only unpromoted packages In-Reply-To: <53daddc5-3de8-4438-a238-2b243d89d3c0@zmail14.collab.prod.int.phx2.redhat.com> References: <53daddc5-3de8-4438-a238-2b243d89d3c0@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <5009A3CD.3070705@redhat.com> On 07/20/2012 08:52 AM, Partha Aji wrote: > > One of the annoyances with browsing contents in the promotions UI is that shows too many packages including those that have already been promoted. So example scenario is some one promotes a huge product and then want to selectively promote the updated packages, but for that they'll have to navigate through pages and pages to see the few packages that have not been promoted. > > Recently with some of the data model changes in content search, its now possible to only show packages that have not been promoted. I wonder if it makes sense to have that as the default filter in the promotions page. > > Another thing to consider here is with Content Deletion we'd want to see all the packages in the current environment, but OTOH with promotions we'd only want to see what has not been previously promoted . > > Any thoughts ? > > Partha > +1, but not in the near term. Lets add it to our backlog Mike From mrao at redhat.com Fri Jul 20 18:35:58 2012 From: mrao at redhat.com (Malini Rao) Date: Fri, 20 Jul 2012 14:35:58 -0400 (EDT) Subject: [katello-devel] RFE -> Promotion should show only unpromoted packages In-Reply-To: <5009A3CD.3070705@redhat.com> Message-ID: <71da84f6-758c-4c7d-9522-e55fa4c884d4@zmail12.collab.prod.int.phx2.redhat.com> +1 from a UX perspective ----- Original Message ----- From: "Mike McCune" To: "Partha Aji" Cc: katello-devel at redhat.com Sent: Friday, July 20, 2012 2:30:37 PM Subject: Re: [katello-devel] RFE -> Promotion should show only unpromoted packages On 07/20/2012 08:52 AM, Partha Aji wrote: > > One of the annoyances with browsing contents in the promotions UI is that shows too many packages including those that have already been promoted. So example scenario is some one promotes a huge product and then want to selectively promote the updated packages, but for that they'll have to navigate through pages and pages to see the few packages that have not been promoted. > > Recently with some of the data model changes in content search, its now possible to only show packages that have not been promoted. I wonder if it makes sense to have that as the default filter in the promotions page. > > Another thing to consider here is with Content Deletion we'd want to see all the packages in the current environment, but OTOH with promotions we'd only want to see what has not been previously promoted . > > Any thoughts ? > > Partha > +1, but not in the near term. Lets add it to our backlog Mike _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From jsherril at redhat.com Fri Jul 20 18:36:52 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Fri, 20 Jul 2012 14:36:52 -0400 Subject: [katello-devel] RFE -> Promotion should show only unpromoted packages In-Reply-To: <5009A3CD.3070705@redhat.com> References: <53daddc5-3de8-4438-a238-2b243d89d3c0@zmail14.collab.prod.int.phx2.redhat.com> <5009A3CD.3070705@redhat.com> Message-ID: <5009A544.6070806@redhat.com> On 07/20/2012 02:30 PM, Mike McCune wrote: > On 07/20/2012 08:52 AM, Partha Aji wrote: >> >> One of the annoyances with browsing contents in the promotions UI is >> that shows too many packages including those that have already been >> promoted. So example scenario is some one promotes a huge product and >> then want to selectively promote the updated packages, but for that >> they'll have to navigate through pages and pages to see the few >> packages that have not been promoted. >> >> Recently with some of the data model changes in content search, its >> now possible to only show packages that have not been promoted. I >> wonder if it makes sense to have that as the default filter in the >> promotions page. >> >> Another thing to consider here is with Content Deletion we'd want to >> see all the packages in the current environment, but OTOH with >> promotions we'd only want to see what has not been previously promoted . >> >> Any thoughts ? >> >> Partha >> > > +1, but not in the near term. Lets add it to our backlog +1 to this, but I feel like we need to tackle some issues with not being able to easily select unpromoted packages on that screen. Currently if you have ~6000 packages and 5 of them are not promoted, you may have to scroll through 5000 just to find some that aren't. Either some sort of filter to only show unpromoted, or simply just only show unpromoted if a 'promote' changeset is selected. We may not need to tackle the issue as part of content deletion, but I would argue its a serious enough of a problem to tackle in the more short-term. -Justin > > Mike > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From ehelms at redhat.com Fri Jul 20 18:47:23 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 20 Jul 2012 14:47:23 -0400 (EDT) Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: <39e0b11f-10f5-4d01-9b3a-bae671b15f85@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: Reading more I realized I wasn't sure about one thing which may effect my thoughts on the naming. Will a changeset continue to be a singular entity that alters the next environment or will there be two clearly distinct entities - a Promotion Changeset and a Deletion Changeset? - Eric ----- Original Message ----- From: "Malini Rao" To: "Cliff Perry" Cc: katello-devel at redhat.com Sent: Friday, July 20, 2012 2:13:24 PM Subject: Re: [katello-devel] Promotions UI - looking for input on naming ----- Original Message ----- From: "Cliff Perry" To: "Brad Buckingham" Cc: katello-devel at redhat.com Sent: Friday, July 20, 2012 1:37:01 PM Subject: Re: [katello-devel] Promotions UI - looking for input on naming On 07/20/2012 12:17 PM, Brad Buckingham wrote: > You all are awesome! Appreciate the quick feedback. > > I am going to let the thread go for additional inputs until early next > week; however, I also lean > towards the latest suggestion, which I believe captures most folks intent. > > i.e. > > Content -> Changeset Management -> Changesets > > Content -> Changeset Management -> Changesets History (This one also > exists in the UI. It was not in my original email, but does show that we > need to have the 3rd level). > I like those ^^^ > > Cliff, > > To your earlier question on thread, the new feature is not a demotion of > content but an actual deletion of the content from the current > environment. Example scenario: > - user goes to the Changesets page (aka Promotions today) > - navigates to an environment (e.g. Dev) > - creates a Deletion Changeset > - adds content to the Changeset (e.g. products, repos, packages...etc) > - user 'applies' the Changeset (and content in changeset is deleted from > that environment) > - any environment before or after that environment remain unchanged I find it inconsistent that the package/content could be further up the environment path... but that is not what is being asked for here :) Well... Library holds all content, content in environments has to be in library. When you populate content into an environment, we call it today a 'promotion'. Well, that promotion today ADDs content, it is an addition, that we choose to give a fancier word, Promotion. So, when you delete the content from the 'DEV' environment, shouldn't we give it the same fancier word - demotion. It is the same net-effect, the package is removed (removed/deleted/demoted/foreclosed) . :) I'm not a UDX type guy. I just think the terminology should be consistent and won't argue the point further in this thread (I given the input which was asked ;) Cliff Malini ---> Cliff, I see your train of thought here and your input is valuable. The issue is about whether the term sets an expectation in the user that something is moved FROM somewhere TO somewhere when that may not be the case in the case of removing content from an environment. In the end, these will most likely end up as button labels and we can all see what term resonates best when we see it in the context of a mock-up. > thanks, > Brad > > On 07/20/2012 01:02 PM, Malini Rao wrote: >> My suggestion would be - >> Content -> Changeset Management -> Changesets >> >> & >> >> Content -> Changeset Management -> Changesets History >> >> >> Thanks >> Malini >> >> ----- Original Message ----- >> From: "Todd Warner" >> To: "Mike McCune" >> Cc: katello-devel at redhat.com >> Sent: Friday, July 20, 2012 12:51:05 PM >> Subject: Re: [katello-devel] Promotions UI - looking for input on naming >> >> On 07/20/2012 12:45 PM, Mike McCune wrote: >>> On 07/20/2012 09:21 AM, Jason Rist wrote: >>>> On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >>>>> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>>>>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>>>>> Hey Folks, >>>>>>> >>>>>>> In the Katello UI, we currently have the following navigation >>>>>>> leading to >>>>>>> the Promotions page: >>>>>>> Content -> Changeset Promotions -> Promotions (page) >>>>>>> >>>>>>> The current promotions page allows users to create change sets and >>>>>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>>>>> environment. >>>>>>> >>>>>>> We are now in the process of developing functionality to allow >>>>>>> users to >>>>>>> also delete content from an environment. This functionality will be >>>>>>> built in to the current promotions UI; therefore, the UI will now >>>>>>> support 2 possible actions (deletions and promotions). As a >>>>>>> result, it >>>>>>> seems like we should consider the navigation and page. >>>>>>> >>>>>>> Any thoughts/opinions? >>>>>>> >>>>>>> Possible renames might be: >>>>>>> Content -> Changeset Promotion / Deletion -> Promotions / >>>>>>> Deletions >>>>>>> Content -> Changeset Management -> Promotions / Deletions >>>>>> I like this one the most ^^^^ >>>>>> Content> Changeset Management> Promotions / Deletions >>>>>> >>>>>> >>>>>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't >>>>>> sound >>>>>> right to me - hurts my ears. >>>>>> >>>>>> Shouldn't it be demotion and promotion? >>>>>> or Additions / Deletions >>>>>> >>>>>> or... Delta Sets :) >>>>>> >>>>>> or... Upgrade / Downgrade >>>>>> >>>>>> I'm sure you picked the word 'deletions' because that is what is >>>>>> happening, without thinking does that term work well with the others >>>>>> in play. >>>>>> >>>>>> Cliff >>>>> Yeah. But it is a deletion, right? You are not reverting something and >>>>> you are not... demoting it. Or are you? It almost seems like two >>>>> different, unrelated actions. I'm with Cliff... is sounds >>>>> "square-peggish". I'm not sure and am interested in other folks' >>>>> opinions. >>>>> >>>>> -todd >>>>> >>>>>>> Content -> Changesets -> Promotions / Deletions >>>>>>> Content -> ... -> ... >>>>>>> >>>>>>> thanks in advance, >>>>>>> Brad >>>>>>> >>>> I think I like "Changeset Management -> Promotions and Deletions" >>>> >>> what about just: >>> >>> Content -> Changesets >>> >>> why put the type in the title? >> YES! >> >>> that said, I do like the clarity of Promotions and Deletions because >>> it helps explain a bit to new users what changesets do. >> Shove "what changeset do" into contextual help? >> -todd >> > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From bbuckingham at redhat.com Fri Jul 20 18:54:02 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Fri, 20 Jul 2012 14:54:02 -0400 Subject: [katello-devel] Promotions UI - looking for input on naming In-Reply-To: References: Message-ID: <5009A94A.5000401@redhat.com> Based on the discussions thus far, the plan is to associate a 'type' with each changeset. As a result, each change set will only perform a single type of action: deletion (from current env) or promotion (to next env). Brad On 07/20/2012 02:47 PM, Eric Helms wrote: > Reading more I realized I wasn't sure about one thing which may effect my thoughts on the naming. > > Will a changeset continue to be a singular entity that alters the next environment or will there be two clearly distinct entities - a Promotion Changeset and a Deletion Changeset? > > - Eric > > ----- Original Message ----- > From: "Malini Rao" > To: "Cliff Perry" > Cc: katello-devel at redhat.com > Sent: Friday, July 20, 2012 2:13:24 PM > Subject: Re: [katello-devel] Promotions UI - looking for input on naming > > > > ----- Original Message ----- > From: "Cliff Perry" > To: "Brad Buckingham" > Cc: katello-devel at redhat.com > Sent: Friday, July 20, 2012 1:37:01 PM > Subject: Re: [katello-devel] Promotions UI - looking for input on naming > > On 07/20/2012 12:17 PM, Brad Buckingham wrote: >> You all are awesome! Appreciate the quick feedback. >> >> I am going to let the thread go for additional inputs until early next >> week; however, I also lean >> towards the latest suggestion, which I believe captures most folks intent. >> >> i.e. >> >> Content -> Changeset Management -> Changesets >> >> Content -> Changeset Management -> Changesets History (This one also >> exists in the UI. It was not in my original email, but does show that we >> need to have the 3rd level). >> > I like those ^^^ > >> Cliff, >> >> To your earlier question on thread, the new feature is not a demotion of >> content but an actual deletion of the content from the current >> environment. Example scenario: >> - user goes to the Changesets page (aka Promotions today) >> - navigates to an environment (e.g. Dev) >> - creates a Deletion Changeset >> - adds content to the Changeset (e.g. products, repos, packages...etc) >> - user 'applies' the Changeset (and content in changeset is deleted from >> that environment) >> - any environment before or after that environment remain unchanged > I find it inconsistent that the package/content could be further up the > environment path... but that is not what is being asked for here :) > > > Well... > Library holds all content, content in environments has to be in library. > When you populate content into an environment, we call it today a > 'promotion'. Well, that promotion today ADDs content, it is an addition, > that we choose to give a fancier word, Promotion. So, when you delete > the content from the 'DEV' environment, shouldn't we give it the same > fancier word - demotion. It is the same net-effect, the package is > removed (removed/deleted/demoted/foreclosed) . :) > > I'm not a UDX type guy. I just think the terminology should be > consistent and won't argue the point further in this thread (I given the > input which was asked ;) > > Cliff > > Malini ---> Cliff, I see your train of thought here and your input is valuable. The issue is about whether the term sets an expectation in the user that something is moved FROM somewhere TO somewhere when that may not be the case in the case of removing content from an environment. In the end, these will most likely end up as button labels and we can all see what term resonates best when we see it in the context of a mock-up. > > >> thanks, >> Brad >> >> On 07/20/2012 01:02 PM, Malini Rao wrote: >>> My suggestion would be - >>> Content -> Changeset Management -> Changesets >>> >>> & >>> >>> Content -> Changeset Management -> Changesets History >>> >>> >>> Thanks >>> Malini >>> >>> ----- Original Message ----- >>> From: "Todd Warner" >>> To: "Mike McCune" >>> Cc: katello-devel at redhat.com >>> Sent: Friday, July 20, 2012 12:51:05 PM >>> Subject: Re: [katello-devel] Promotions UI - looking for input on naming >>> >>> On 07/20/2012 12:45 PM, Mike McCune wrote: >>>> On 07/20/2012 09:21 AM, Jason Rist wrote: >>>>> On Fri 20 Jul 2012 09:59:57 AM MDT, Todd Warner wrote: >>>>>> On 07/20/2012 11:55 AM, Cliff Perry wrote: >>>>>>> On 07/20/2012 10:49 AM, Brad Buckingham wrote: >>>>>>>> Hey Folks, >>>>>>>> >>>>>>>> In the Katello UI, we currently have the following navigation >>>>>>>> leading to >>>>>>>> the Promotions page: >>>>>>>> Content -> Changeset Promotions -> Promotions (page) >>>>>>>> >>>>>>>> The current promotions page allows users to create change sets and >>>>>>>> promote content from the current (e.g. Dev) to next (e.g. Test) >>>>>>>> environment. >>>>>>>> >>>>>>>> We are now in the process of developing functionality to allow >>>>>>>> users to >>>>>>>> also delete content from an environment. This functionality will be >>>>>>>> built in to the current promotions UI; therefore, the UI will now >>>>>>>> support 2 possible actions (deletions and promotions). As a >>>>>>>> result, it >>>>>>>> seems like we should consider the navigation and page. >>>>>>>> >>>>>>>> Any thoughts/opinions? >>>>>>>> >>>>>>>> Possible renames might be: >>>>>>>> Content -> Changeset Promotion / Deletion -> Promotions / >>>>>>>> Deletions >>>>>>>> Content -> Changeset Management -> Promotions / Deletions >>>>>>> I like this one the most ^^^^ >>>>>>> Content> Changeset Management> Promotions / Deletions >>>>>>> >>>>>>> >>>>>>> Though 'Promotions / Deletions' seems wrongly worded, it doesn't >>>>>>> sound >>>>>>> right to me - hurts my ears. >>>>>>> >>>>>>> Shouldn't it be demotion and promotion? >>>>>>> or Additions / Deletions >>>>>>> >>>>>>> or... Delta Sets :) >>>>>>> >>>>>>> or... Upgrade / Downgrade >>>>>>> >>>>>>> I'm sure you picked the word 'deletions' because that is what is >>>>>>> happening, without thinking does that term work well with the others >>>>>>> in play. >>>>>>> >>>>>>> Cliff >>>>>> Yeah. But it is a deletion, right? You are not reverting something and >>>>>> you are not... demoting it. Or are you? It almost seems like two >>>>>> different, unrelated actions. I'm with Cliff... is sounds >>>>>> "square-peggish". I'm not sure and am interested in other folks' >>>>>> opinions. >>>>>> >>>>>> -todd >>>>>> >>>>>>>> Content -> Changesets -> Promotions / Deletions >>>>>>>> Content -> ... -> ... >>>>>>>> >>>>>>>> thanks in advance, >>>>>>>> Brad >>>>>>>> >>>>> I think I like "Changeset Management -> Promotions and Deletions" >>>>> >>>> what about just: >>>> >>>> Content -> Changesets >>>> >>>> why put the type in the title? >>> YES! >>> >>>> that said, I do like the clarity of Promotions and Deletions because >>>> it helps explain a bit to new users what changesets do. >>> Shove "what changeset do" into contextual help? >>> -todd >>> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Fri Jul 20 22:13:54 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 20 Jul 2012 15:13:54 -0700 Subject: [katello-devel] design top level page Message-ID: <5009D822.1070707@redhat.com> If you are working on a design for a feature just add a link here and finish your page name with *Design https://fedorahosted.org/katello/wiki/Design eg: https://fedorahosted.org/katello/wiki/CustomCertsDesign https://fedorahosted.org/katello/wiki/ContentDeletionDesign ... Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From inecas at redhat.com Mon Jul 23 06:25:10 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 23 Jul 2012 08:25:10 +0200 Subject: [katello-devel] RFE -> Promotion should show only unpromoted packages In-Reply-To: <53daddc5-3de8-4438-a238-2b243d89d3c0@zmail14.collab.prod.int.phx2.redhat.com> References: <53daddc5-3de8-4438-a238-2b243d89d3c0@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <500CEE46.4070902@redhat.com> On 07/20/2012 05:52 PM, Partha Aji wrote: > Another thing to consider here is with Content Deletion we'd want to see all the packages in the current environment, but OTOH with promotions we'd only want to see what has not been previously promoted . Talking about content deletion, is there a already a plan how to display this? What about this: on the left side are the packages/repos/products not promoted to the next env - one can hit (+) to add them to next env on the right side are the packages/repos/products promoted to the next env - on can hit (-) to delete them from the env the changeset is displayed below the two panes, allowing to undo some (undo adding/deleting) -- Ivan > Any thoughts ? > > Partha > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From lzap at redhat.com Mon Jul 23 08:14:36 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 23 Jul 2012 10:14:36 +0200 Subject: [katello-devel] Content Search Merged to master In-Reply-To: <50087B5C.7050600@redhat.com> References: <50086081.3090603@redhat.com> <3176A0A9-AE67-49FF-8F19-B3F73603256A@redhat.com> <50086471.9090409@redhat.com> <50087B5C.7050600@redhat.com> Message-ID: <20120723081435.GB4631@lzapx.brq.redhat.com> On Thu, Jul 19, 2012 at 05:25:48PM -0400, Justin Sherrill wrote: > I'm working on fixing this and noticed that the katello migration > script is run BEFORE the pulp and candlepin migration scripts in > katello-upgrade. This seems backwards to me. Is there a reason > for this? Good point, I guess we would need both. We should made a change that would allow us injecting scripts before and after migration (default) scripts. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Mon Jul 23 08:18:24 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 23 Jul 2012 10:18:24 +0200 Subject: [katello-devel] Blog? In-Reply-To: <50096A3A.1080105@redhat.com> References: <5007F735.8070002@redhat.com> <5009114A.6080207@redhat.com> <50096A3A.1080105@redhat.com> Message-ID: <20120723081823.GC4631@lzapx.brq.redhat.com> On Fri, Jul 20, 2012 at 08:24:58AM -0600, Jason Rist wrote: > >[1] https://github.com/mojombo/jekyll/ > >[2] https://help.github.com/categories/20/articles > This is a great idea. I think we were talking about using "our own > dog food" via OpenShift + Wordpress. > I was playing over the weekend with Jekyll and I like it. Pretty straightforward to configure. Almost good as http://nanoblogger.sourceforge.net/ ;-) No seriously, it's fine. +1 -- Later, Lukas "lzap" Zapletal #katello #systemengine From ohadlevy at redhat.com Mon Jul 23 08:32:16 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Mon, 23 Jul 2012 11:32:16 +0300 Subject: [katello-devel] Blog? In-Reply-To: <20120723081823.GC4631@lzapx.brq.redhat.com> References: <5007F735.8070002@redhat.com> <5009114A.6080207@redhat.com> <50096A3A.1080105@redhat.com> <20120723081823.GC4631@lzapx.brq.redhat.com> Message-ID: <500D0C10.50203@redhat.com> On 07/23/2012 11:18 AM, Lukas Zapletal wrote: > On Fri, Jul 20, 2012 at 08:24:58AM -0600, Jason Rist wrote: >>> [1] https://github.com/mojombo/jekyll/ >>> [2] https://help.github.com/categories/20/articles >> This is a great idea. I think we were talking about using "our own >> dog food" via OpenShift + Wordpress. >> > > I was playing over the weekend with Jekyll and I like it. Pretty > straightforward to configure. Almost good as > > http://nanoblogger.sourceforge.net/ > > ;-) No seriously, it's fine. +1 > > +1 to jekyll, I'm about to deploy some static pages for foreman using it as well. Ohad From bkearney at redhat.com Mon Jul 23 12:47:43 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 23 Jul 2012 08:47:43 -0400 Subject: [katello-devel] Fwd: [foreman-dev] Foreman 1.0 released! In-Reply-To: References: Message-ID: <500D47EF.4090208@redhat.com> Cross Posting -- bk -------- Original Message -------- Subject: [foreman-dev] Foreman 1.0 released! Date: Sun, 22 Jul 2012 16:02:06 +0300 From: Ohad Levy Hello, I'm very excited and pleased to share the release of Foreman 1.0 Since the change log is quite extensive, I would simply refer you to the change log [1] and would highly suggest to read it if you are upgrading. About Foreman: Foreman is an opensource management tool, design to help you to manage your infrastructure. Foreman takes over provisioning(bare metal, virtual or in the cloud)[2], interfacing with puppet to configure your servers, and provides an easy to use UI / API to control and review your server state. I'm also very happy to see that Foreman users, contributes (thanks guys!!) and ecosystem is growing, that includes a mobile app [3] and a CLI that was contributed by our community. I'm assuming packages would be available shortly. have fun, Ohad [1] http://theforeman.org/projects/foreman/wiki/ReleaseNotes#Release-Notes-for-10 [2] http://theforeman.org/projects/foreman/wiki/Screencasts [3] http://www.remoteadmin.co From lzap at redhat.com Mon Jul 23 13:31:47 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 23 Jul 2012 15:31:47 +0200 Subject: [katello-devel] Installer review (allow to run katello-configure multiple times) Message-ID: <20120723133147.GE4631@lzapx.brq.redhat.com> Guys. We have been working hard on katello-configure to improve the way it works. Since the installer is Puppet based, our main goal was to allow users to run it multiple times. Like Puppet does, installer do check everything and correct all deviations from what you configured using parameters. This was not possible since some dependency issues and usage of idempotent scripts like cpsetup. Lots of changes were incorporated - various workarounds were removed and installer was tested with various scenarios. From now on, if you provision a clean installation or if you have existing one, you can always run katello-configure to make sure everything is okay. Please note all the katello-configure options are stored in the /etc/katello/katello-configure.conf so you can use it as an answer file: katello-configure --answer-file=/etc/katello/katello-configure.conf You can also provide different parameters and installer will re-configure everything. Please check logs carefully when changing options and report errors if you encouter any. Also note that changing org-name, user-name, user-pass and user-email will require resetting database. And this also means you can easily switch between katello and headpin. Yes, this is possible and as easy as installing thumbslug plus: katello-configure --deployment=headpin katello ping katello-configure --deployment=katello katello ping There is a new option --reset-data which drops all databases: katello, candlepin, pulp (also repos which were generated), elasticsearch and then starts initial configuration again. Since this is dangerous option, you need to provide case-sensitive "YES" to get the desired behavior. Additional second option --reset-cache just removes all pulp downloaded RPMs from /var/lib/pulp/packages. If you provide them both, katello instance should be completly "clean". Please note all --reset-* options are not stored in the answer file for obvious reasons. Example of full reset of a katello installation: katello-configure --answer-file=/etc/katello/katello-configure.conf --reset-data=YES --reset-cache=YES Basically this does the very same as katello-reset-dbs, but also makes sure all configuration values are correct. We will keep katello-reset-dbs script in git since it can be easily used for development setups. Katello-configure will also work for upgrades. To upgrade existing installation, use katello-upgrade script first which will do all data migrations which are needed and THEN you can run katello-configure as many times as you want to re-configure stuff, because it always should describe correct state of an installation. It is not recommended to run katello-configure BEFORE katello-upgrade. IMPORTANT: Since there are big changes in the installer, you need to do clean installation for the first time. If you try to upgrade to the new version of the installer, it will likely fail with a puppet error. Please report all katello-configure failures along with katello-debug output. It creates nice tarball with all the important logs there (passwords are removed). We recommend to attach it as private comments into bugzilla. Before you report, please try to restart all backend engines and then katello to see if it helps and provide this information. There are also two more options -b and -d. The first one turns off progress bars logging puppet also on the standard output and the second enables debug messages to be avaiable also on stdout (hidden by default). New version also strips out annoying color codes in the katello-configure log files. As a side effect, I created a page describing installation of katello via puppet itself (without katello-configure script which only collects params and runs puppet): https://fedorahosted.org/katello/wiki/InstallViaPuppet Git pull request is here: https://github.com/Katello/katello/pull/345 List of things that has been changed should be obvious from commit messages. It should be roughly this list: * remove reconfiguration message * remove /var/log/katello permission mangling * make sure certs and tomcat conf are not regenerated during rounds * parametrize hardcoded elasticsearch heap sizes * do not generate candlepin.conf in the cpsetup anymore * make tomcat password file to survive multiple runs * add warning header to all puppet-controlled config files * remove hardcoded values from seeds.rb * secure "hacky" initdb password handover * tomcat keystore_password_file fix * fix and test puppet when initial pg superuser password is set * do not regenerate oauth_secret every puppet run * notify services when changing config files (review them all) * get rid of cpsetup and use dpdb directly * remove generated string from all config headers * do not rewrite pulp user pass everytime * use refreshonly for cert generation * implement --reset-data and --reset-cache options * test with deploy arguments: katello, headpin, cfse, sam * handle upgrades correctly Feel free to review, I am currently testing it with Fedoras and I would maybe get rid of reseting oauth in the post RPM section. (Why do we actually do it here?) Comments appreciated. This was on my TODO for a long time. -- Later, Lukas "lzap" Zapletal #katello #systemengine From pblaho at redhat.com Mon Jul 23 14:04:25 2012 From: pblaho at redhat.com (Petr Blaho) Date: Mon, 23 Jul 2012 16:04:25 +0200 Subject: [katello-devel] Interesting alternative to curl In-Reply-To: <5006F3E6.5080502@redhat.com> References: <5006F3E6.5080502@redhat.com> Message-ID: <17914057.PHkbb6JpvQ@dhcp-30-137.brq.redhat.com> On Wednesday, July 18, 2012 01:35:34 PM Justin Sherrill wrote: > https://github.com/jkbr/httpie/#readme > > Looks really neat! > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I sometimes use https://github.com/yaks/kronk ... -- With regards Petr Blaho From mrao at redhat.com Mon Jul 23 14:05:14 2012 From: mrao at redhat.com (Malini Rao) Date: Mon, 23 Jul 2012 10:05:14 -0400 (EDT) Subject: [katello-devel] RFE -> Promotion should show only unpromoted packages In-Reply-To: <500CEE46.4070902@redhat.com> Message-ID: <1522275078.405615.1343052314528.JavaMail.root@redhat.com> Sounds reasonable Ivan. We'll keep this in mind as we come up with the initial design for sharing on this. Thanks Malini ----- Original Message ----- From: "Ivan Ne?as" To: katello-devel at redhat.com Sent: Monday, July 23, 2012 2:25:10 AM Subject: Re: [katello-devel] RFE -> Promotion should show only unpromoted packages On 07/20/2012 05:52 PM, Partha Aji wrote: > Another thing to consider here is with Content Deletion we'd want to see all the packages in the current environment, but OTOH with promotions we'd only want to see what has not been previously promoted . Talking about content deletion, is there a already a plan how to display this? What about this: on the left side are the packages/repos/products not promoted to the next env - one can hit (+) to add them to next env on the right side are the packages/repos/products promoted to the next env - on can hit (-) to delete them from the env the changeset is displayed below the two panes, allowing to undo some (undo adding/deleting) -- Ivan > Any thoughts ? > > Partha > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From matt.wagner at redhat.com Mon Jul 23 15:03:27 2012 From: matt.wagner at redhat.com (Matt Wagner) Date: Mon, 23 Jul 2012 11:03:27 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <20120716224300.GB19456@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> <20120716224300.GB19456@redhat.com> Message-ID: <20120723150327.GC16914@mawagner-desktop.usersys.redhat.com> On Mon, Jul 16, 2012 at 06:43:01PM -0400, Hugh O. Brock wrote: > On Mon, Jul 16, 2012 at 05:57:04PM +0200, Petr Chalupa wrote: > > I am the osx user so I have to speak out ;) > > > > I think this is not just my issue. Not everybody is running on > > fedora, this affects all debian-based distributions as well. I think > > it should be solved satisfactory not to discourage potential > > contributors. Amen to this sentiment. I think we're greatly limiting the number of people who can use our project if we only support RPM-based distros. > > I think they like theirs tweaked machines, they are used to theirs > > tools and They want to use them as I do. To do so you need run > > katello app locally against a VM with services (db, pulp, > > candlepin). We have various non-Ruby tools as well, which are not necessarily terribly portable. But there's no reason that the core Ruby parts of our app shouldn't be able to run on Debian, a Mac, or OpenBSD. > > I may have a compromise: > > - If all gems are in rpm repos, with the .gem files actualized. > > - Then a developer can do 'bundle package' on the VM to get > > vendor/cache with all needed gems including theirs CVE patches. > > - Then he can run 'bundle install --locally' on any development > > machine and he is good to go. > > > > We can later decide to add a repo with vendor/cache to make it even easier. > > > > To sumarize: I think the main issue for non fedora development > > machines are not updated .gem files in rubygem rpms. I'm not sure I understand this 100%. For RPM-based distros, can't we simply keep the RPMs reasonably up-to-date? (It seems like a good part of the process can be automated, as well.) And for non-RPM distros, we should just use "real" gems. Though honestly, the whole notion of packaging gems as RPMs seems weird to me, but I guess there's precedent with other systems (e.g., CPAN). It just feels like we're trying to encapsulate one package management system inside another, which sounds like insanity. > However, my view, and the view of most of the folks I've talked to on > the Aeolus team, is that RPM packaging and installing from RPM or > using any other distro tools is an unnatural act for a ruby > developer and that it is (one of the many things) impeding our > progress with building an upstream community. +1 > One way we could minimize the inevitable package proliferation pain > we'll incur by doing this is by pitching in to maintain a shared gem > repo across projects. I had even thought about a rubygems.org fork > that would provide a bit more of a gate than straight upstream, I > don't know what others would think of this. It sounds like Petr has > suggested something similar above, but I would skip the RPM step > even. Wouldn't it be better to just push updates to rubygems.org directly? Forking it feels a bit like we're declaring it so broken that it's beyond repair, and that we aren't interested in sharing our enhancements. If we really need to have certain blessed versions, can't we just require those exact versions, versus carrying them ourselves? > Anyway, obviously Katello upstream is free to do what it wants, but I > believe Aeolus is going to move away from knee-jerk RPM packaging and > instead plan to package our upstream releases as tarball + gems + > Gemfile, as you would expect a Ruby project to do. That would be terrific! :) From hbrock at redhat.com Mon Jul 23 15:25:40 2012 From: hbrock at redhat.com (Hugh O. Brock) Date: Mon, 23 Jul 2012 11:25:40 -0400 Subject: [katello-devel] where to get required katello gems In-Reply-To: <0F403CC4-BCCE-4696-A482-61944774D5A1@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> <20120716224300.GB19456@redhat.com> <20120723150327.GC16914@mawagner-desktop.usersys.redhat.com> <0F403CC4-BCCE-4696-A482-61944774D5A1@redhat.com> Message-ID: <20120723152540.GO1780@redhat.com> On Tue, Jul 24, 2012 at 01:09:39AM +1000, Justin Clift wrote: > On 24/07/2012, at 1:03 AM, Matt Wagner wrote: > > >>> To sumarize: I think the main issue for non fedora development > >>> machines are not updated .gem files in rubygem rpms. > > > > I'm not sure I understand this 100%. For RPM-based distros, can't we > > simply keep the RPMs reasonably up-to-date? (It seems like a good part > > of the process can be automated, as well.) And for non-RPM distros, we > > should just use "real" gems. > > > > Though honestly, the whole notion of packaging gems as RPMs seems weird > > to me, but I guess there's precedent with other systems (e.g., CPAN). It > > just feels like we're trying to encapsulate one package management > > system inside another, which sounds like insanity. > > > As a data point, this came through another mailing list: > > https://plus.google.com/u/0/116044105212961820435/posts/3H9BBynrfDf > > It looks like OpenSuSE's equivalent to yum, called zypper, has added > native support for Ruby gem's and Python's things (eggs?) and similar. > > Maybe adding gem support to yum would be the go? It would be a great idea, but I've tried to convince the Fedora folks of that and been... well, unsuccessful is much too polite a term. Maybe we should just use zypper? --H -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From omaciel at redhat.com Mon Jul 23 18:54:54 2012 From: omaciel at redhat.com (Og Maciel) Date: Mon, 23 Jul 2012 14:54:54 -0400 (EDT) Subject: [katello-devel] Using katello client remember with username and password Message-ID: <1194714803.973288.1343069694625.JavaMail.root@redhat.com> Wondering if I'm missing something or perhaps misunderstood what the client remember options really do: [root at qetello02 ~]# katello client remember --option=username --value=admin Successfully overwrote option [ username ] [root at qetello02 ~]# katello client remember --option=password --value=admin Successfully overwrote option [ password ] [root at qetello02 ~]# katello user list Invalid credentials or unable to authenticate -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From ohadlevy at redhat.com Mon Jul 23 19:14:17 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Mon, 23 Jul 2012 22:14:17 +0300 Subject: [katello-devel] Installer review (allow to run katello-configure multiple times) In-Reply-To: <20120723133147.GE4631@lzapx.brq.redhat.com> References: <20120723133147.GE4631@lzapx.brq.redhat.com> Message-ID: <500DA289.9040205@redhat.com> On 07/23/2012 04:31 PM, Lukas Zapletal wrote: > Guys. > > We have been working hard on katello-configure to improve the way it > works. Since the installer is Puppet based, our main goal was to allow > users to run it multiple times. Like Puppet does, installer do check > everything and correct all deviations from what you configured using > parameters. This was not possible since some dependency issues and usage > of idempotent scripts like cpsetup. > > Lots of changes were incorporated - various workarounds were removed and > installer was tested with various scenarios. From now on, if you > provision a clean installation or if you have existing one, you can > always run katello-configure to make sure everything is okay. Please > note all the katello-configure options are stored in the > /etc/katello/katello-configure.conf so you can use it as an answer file: > > katello-configure --answer-file=/etc/katello/katello-configure.conf > > You can also provide different parameters and installer will > re-configure everything. Please check logs carefully when changing > options and report errors if you encouter any. Also note that changing > org-name, user-name, user-pass and user-email will require resetting > database. > > And this also means you can easily switch between katello and headpin. > Yes, this is possible and as easy as installing thumbslug plus: > > katello-configure --deployment=headpin > katello ping > katello-configure --deployment=katello > katello ping > > There is a new option --reset-data which drops all databases: katello, > candlepin, pulp (also repos which were generated), elasticsearch and > then starts initial configuration again. Since this is dangerous option, > you need to provide case-sensitive "YES" to get the desired behavior. > > Additional second option --reset-cache just removes all pulp downloaded > RPMs from /var/lib/pulp/packages. If you provide them both, katello > instance should be completly "clean". Please note all --reset-* options > are not stored in the answer file for obvious reasons. > > Example of full reset of a katello installation: > > katello-configure --answer-file=/etc/katello/katello-configure.conf > --reset-data=YES --reset-cache=YES > > Basically this does the very same as katello-reset-dbs, but also makes > sure all configuration values are correct. We will keep > katello-reset-dbs script in git since it can be easily used for > development setups. > > Katello-configure will also work for upgrades. To upgrade existing > installation, use katello-upgrade script first which will do all data > migrations which are needed and THEN you can run katello-configure as > many times as you want to re-configure stuff, because it always should > describe correct state of an installation. It is not recommended to run > katello-configure BEFORE katello-upgrade. > > IMPORTANT: Since there are big changes in the installer, you need to do > clean installation for the first time. If you try to upgrade to the new > version of the installer, it will likely fail with a puppet error. > > Please report all katello-configure failures along with katello-debug > output. It creates nice tarball with all the important logs there > (passwords are removed). We recommend to attach it as private comments > into bugzilla. Before you report, please try to restart all backend > engines and then katello to see if it helps and provide this > information. > > There are also two more options -b and -d. The first one turns off > progress bars logging puppet also on the standard output and the second > enables debug messages to be avaiable also on stdout (hidden by > default). New version also strips out annoying color codes in the > katello-configure log files. > > As a side effect, I created a page describing installation of katello > via puppet itself (without katello-configure script which only collects > params and runs puppet): > > https://fedorahosted.org/katello/wiki/InstallViaPuppet > > Git pull request is here: https://github.com/Katello/katello/pull/345 > > List of things that has been changed should be obvious from commit > messages. It should be roughly this list: > > * remove reconfiguration message > * remove /var/log/katello permission mangling > * make sure certs and tomcat conf are not regenerated during rounds > * parametrize hardcoded elasticsearch heap sizes > * do not generate candlepin.conf in the cpsetup anymore > * make tomcat password file to survive multiple runs > * add warning header to all puppet-controlled config files > * remove hardcoded values from seeds.rb > * secure "hacky" initdb password handover > * tomcat keystore_password_file fix > * fix and test puppet when initial pg superuser password is set > * do not regenerate oauth_secret every puppet run > * notify services when changing config files (review them all) > * get rid of cpsetup and use dpdb directly > * remove generated string from all config headers > * do not rewrite pulp user pass everytime > * use refreshonly for cert generation > * implement --reset-data and --reset-cache options > * test with deploy arguments: katello, headpin, cfse, sam > * handle upgrades correctly > > Feel free to review, I am currently testing it with Fedoras and I would > maybe get rid of reseting oauth in the post RPM section. (Why do we > actually do it here?) > > Comments appreciated. This was on my TODO for a long time. > +10000 From msuchy at redhat.com Mon Jul 23 19:35:36 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Mon, 23 Jul 2012 21:35:36 +0200 Subject: [katello-devel] Why #!/usr/bin/env ? Message-ID: <500DA788.5060209@redhat.com> Why do you guys prefer #!/usr/bin/env ? I seen it twice in today pull requests and git grep show me it is used several times in our code. I understand it may put in game e.g /usr/local/bin/ with locally compiled python/ruby. But is it what we want? Do we guarantee, that our code will work with locally modified version of python/ruby? I always used plain #!/usr/bin/python or #!/usr/bin/ruby as it gives me more control and less bug reports. Mirek From jomara at redhat.com Mon Jul 23 19:37:43 2012 From: jomara at redhat.com (Jordan OMara) Date: Mon, 23 Jul 2012 15:37:43 -0400 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <500DA788.5060209@redhat.com> References: <500DA788.5060209@redhat.com> Message-ID: <20120723193743.GE12706@redhat.com> On 23/07/12 21:35 +0200, Miroslav Suchy wrote: >Why do you guys prefer #!/usr/bin/env ? > >I seen it twice in today pull requests and git grep show me it is >used several times in our code. > >I understand it may put in game e.g /usr/local/bin/ with locally >compiled python/ruby. But is it what we want? Do we guarantee, that >our code will work with locally modified version of python/ruby? > >I always used plain #!/usr/bin/python or #!/usr/bin/ruby as it gives >me more control and less bug reports. > >Mirek > I actually had a stranger from the internet make a pull request on one of my random github projects and correct a ruby script from #!/usr/bin/ruby -> #!/usr/bin/env ruby ; the same way we have it in our scripts. I'm curious as well -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From esammons at redhat.com Mon Jul 23 19:48:23 2012 From: esammons at redhat.com (Eric Sammons) Date: Mon, 23 Jul 2012 15:48:23 -0400 (EDT) Subject: [katello-devel] Why #!/usr/bin/env ? Message-ID: <3i9r05t7n44jypqmi4tsdbhn.1343072892105@email.android.com> An HTML attachment was scrubbed... URL: From esammons at redhat.com Mon Jul 23 19:48:52 2012 From: esammons at redhat.com (Eric Sammons) Date: Mon, 23 Jul 2012 15:48:52 -0400 (EDT) Subject: [katello-devel] Why #!/usr/bin/env ? Message-ID: An HTML attachment was scrubbed... URL: From ewoud+katello at kohlvanwijngaarden.nl Mon Jul 23 20:06:31 2012 From: ewoud+katello at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Mon, 23 Jul 2012 22:06:31 +0200 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <20120723193743.GE12706@redhat.com> References: <500DA788.5060209@redhat.com> <20120723193743.GE12706@redhat.com> Message-ID: <20120723195205.GB3793@bogey.xentower.nl> On Mon, Jul 23, 2012 at 03:37:43PM -0400, Jordan OMara wrote: > On 23/07/12 21:35 +0200, Miroslav Suchy wrote: > >Why do you guys prefer #!/usr/bin/env ? > > > >I seen it twice in today pull requests and git grep show me it is > >used several times in our code. > > > >I understand it may put in game e.g /usr/local/bin/ with locally > >compiled python/ruby. But is it what we want? Do we guarantee, > >that our code will work with locally modified version of > >python/ruby? > > > >I always used plain #!/usr/bin/python or #!/usr/bin/ruby as it > >gives me more control and less bug reports. > > > >Mirek > > > > I actually had a stranger from the internet make a pull request on one > of my random github projects and correct a ruby script from > #!/usr/bin/ruby -> #!/usr/bin/env ruby ; the same way we have it in > our scripts. I'm curious as well Can't speak for ruby, but in the python world virtualenv[1] is popular among developers. Then python can live in ~/myenv/bin/python as well as many dependencies under ~/myenv/lib/python2.X/site-packages which /usr/bin/python will never find, or worse, different versions. I imagine something similar may exist in the ruby world. Btw, those who like virtualenv will also like virtualenvwrapper which makes it easy to manage many environments. [1]: http://pypi.python.org/pypi/virtualenv/ [2]: http://www.doughellmann.com/projects/virtualenvwrapper/ From alikins at redhat.com Mon Jul 23 20:46:54 2012 From: alikins at redhat.com (Adrian Likins) Date: Mon, 23 Jul 2012 16:46:54 -0400 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <20120723195205.GB3793@bogey.xentower.nl> References: <500DA788.5060209@redhat.com> <20120723193743.GE12706@redhat.com> <20120723195205.GB3793@bogey.xentower.nl> Message-ID: <500DB83E.8000709@redhat.com> On 07/23/2012 04:06 PM, Ewoud Kohl van Wijngaarden wrote: > On Mon, Jul 23, 2012 at 03:37:43PM -0400, Jordan OMara wrote: >> On 23/07/12 21:35 +0200, Miroslav Suchy wrote: >>> Why do you guys prefer #!/usr/bin/env ? >>> >>> I seen it twice in today pull requests and git grep show me it is >>> used several times in our code. >>> >>> I understand it may put in game e.g /usr/local/bin/ with locally >>> compiled python/ruby. But is it what we want? Do we guarantee, >>> that our code will work with locally modified version of >>> python/ruby? >>> >>> I always used plain #!/usr/bin/python or #!/usr/bin/ruby as it >>> gives me more control and less bug reports. >>> >>> Mirek >>> >> I actually had a stranger from the internet make a pull request on one >> of my random github projects and correct a ruby script from >> #!/usr/bin/ruby -> #!/usr/bin/env ruby ; the same way we have it in >> our scripts. I'm curious as well > Can't speak for ruby, but in the python world virtualenv[1] is popular > among developers. Then python can live in ~/myenv/bin/python as well as > many dependencies under ~/myenv/lib/python2.X/site-packages which > /usr/bin/python will never find, or worse, different versions. I imagine > something similar may exist in the ruby world. Shouldn't distutils do the right thing in this case? http://docs.python.org/distutils/setupscript.html#installing-scripts Adrian From esammons at redhat.com Mon Jul 23 21:05:49 2012 From: esammons at redhat.com (Eric Sammons) Date: Mon, 23 Jul 2012 17:05:49 -0400 (EDT) Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <500DB83E.8000709@redhat.com> Message-ID: <1773869948.1549753.1343077549975.JavaMail.root@redhat.com> ----- Original Message ----- > On 07/23/2012 04:06 PM, Ewoud Kohl van Wijngaarden wrote: > > On Mon, Jul 23, 2012 at 03:37:43PM -0400, Jordan OMara wrote: > >> On 23/07/12 21:35 +0200, Miroslav Suchy wrote: > >>> Why do you guys prefer #!/usr/bin/env ? > >>> > >>> I seen it twice in today pull requests and git grep show me it is > >>> used several times in our code. > >>> > >>> I understand it may put in game e.g /usr/local/bin/ with locally > >>> compiled python/ruby. But is it what we want? Do we guarantee, > >>> that our code will work with locally modified version of > >>> python/ruby? > >>> > >>> I always used plain #!/usr/bin/python or #!/usr/bin/ruby as it > >>> gives me more control and less bug reports. > >>> > >>> Mirek > >>> > >> I actually had a stranger from the internet make a pull request on > >> one > >> of my random github projects and correct a ruby script from > >> #!/usr/bin/ruby -> #!/usr/bin/env ruby ; the same way we have it > >> in > >> our scripts. I'm curious as well > > Can't speak for ruby, but in the python world virtualenv[1] is > > popular > > among developers. Then python can live in ~/myenv/bin/python as > > well as > > many dependencies under ~/myenv/lib/python2.X/site-packages which > > /usr/bin/python will never find, or worse, different versions. I > > imagine > > something similar may exist in the ruby world. > > Shouldn't distutils do the right thing in this case? > http://docs.python.org/distutils/setupscript.html#installing-scripts > > Adrian I may be mis-understanding here or perhaps I am not familiar with all the cool features of distutils, but I was under the impression that this was related to the setup and packaging (for distribution) of pypi packages. Again, unless I am missing something, this is not necessarily related to the use of #!/usr/bin/python v. #!/usr/bin/env python. Again, WRT /usr/bin/python v. /usr/bin/env python, as I mentioned for me this is habit. However, there are a number of discussion threads on the topic; http://stackoverflow.com/questions/2429511/why-do-people-write-usr-bin-env-python-on-the-first-line-of-a-python-script for example. I will continue to use /usr/bin/env python as it is habit and I have been in environments where the default PATH is altered to ensure the use of the "in-house" preferred binaries, usually stored in /opt/$pkg/bin or /usr/local/bin. Again wrt virtualenv, here is an example: $ virtualenv testme $ cd testme $ source bin/activate $ which python ~/testme/bin/python Note, if you were using /usr/bin/python you would _not_ be testing the python binary in "testme". --Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From msuchy at redhat.com Mon Jul 23 21:11:40 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Mon, 23 Jul 2012 23:11:40 +0200 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <1773869948.1549753.1343077549975.JavaMail.root@redhat.com> References: <1773869948.1549753.1343077549975.JavaMail.root@redhat.com> Message-ID: <500DBE0C.1040606@redhat.com> On 23.7.2012 23:05, Eric Sammons wrote: >>> among developers. Then python can live in ~/myenv/bin/python as >>> > > well as >>> > > many dependencies under ~/myenv/lib/python2.X/site-packages which >>> > > /usr/bin/python will never find, or worse, different versions. I >>> > > imagine >>> > > something similar may exist in the ruby world. And that ~/myenv/bin/python is python 2.4, 2.6, or 3.0? All of them behave *very* differently. > Again wrt virtualenv, here is an example: > > $ virtualenv testme > $ cd testme > $ source bin/activate > $ which python > ~/testme/bin/python > > Note, if you were using /usr/bin/python you would_not_ be testing the python binary in "testme". That can be ok for quick'n'dirty code, where you want fast alternation without too much work. But who would do such thing in production? Mirek From esammons at redhat.com Mon Jul 23 21:22:38 2012 From: esammons at redhat.com (Eric Sammons) Date: Mon, 23 Jul 2012 17:22:38 -0400 (EDT) Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <500DBE0C.1040606@redhat.com> Message-ID: <1215965795.1555517.1343078558502.JavaMail.root@redhat.com> ----- Original Message ----- > On 23.7.2012 23:05, Eric Sammons wrote: > >>> among developers. Then python can live in ~/myenv/bin/python as > >>> > > well as > >>> > > many dependencies under ~/myenv/lib/python2.X/site-packages > >>> > > which > >>> > > /usr/bin/python will never find, or worse, different > >>> > > versions. I > >>> > > imagine > >>> > > something similar may exist in the ruby world. > > And that ~/myenv/bin/python is python 2.4, 2.6, or 3.0? All of them > behave *very* differently. > > > Again wrt virtualenv, here is an example: > > > > $ virtualenv testme > > $ cd testme > > $ source bin/activate > > $ which python > > ~/testme/bin/python > > > > Note, if you were using /usr/bin/python you would_not_ be testing > > the python binary in "testme". > > That can be ok for quick'n'dirty code, where you want fast > alternation > without too much work. But who would do such thing in production? > > Mirek I actually do know IT shops that only run python code this way as it ensures that no stray libraries are in use or installed. But yes primarily used for Dev and Test (I use only for test, honestly). However, I still fall back to the use where shops actually do override the default $PATH to ensure they are using their in house compiled "GOLD" version of python. Many (many) customers feel that our interpreters are always behind and the versioning.release stuff confuses them so to be sure they are getting (for example) pure python-2.7 they will install python-2.7 into /usr/local/ and then change path to reference /usr/local/bin first. Again, in this manner /usr/bin/python breaks. --Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From sam at kottlerdevelopment.com Mon Jul 23 21:28:59 2012 From: sam at kottlerdevelopment.com (Sam Kottler) Date: Mon, 23 Jul 2012 17:28:59 -0400 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <1215965795.1555517.1343078558502.JavaMail.root@redhat.com> References: <500DBE0C.1040606@redhat.com> <1215965795.1555517.1343078558502.JavaMail.root@redhat.com> Message-ID: > > I actually do know IT shops that only run python code this way as it > ensures that no stray libraries are in use or installed. But yes primarily > used for Dev and Test (I use only for test, honestly). However, I still > fall back to the use where shops actually do override the default $PATH to > ensure they are using their in house compiled "GOLD" version of python. Yes, this is a really standard practice. I've worked on a few large Python-based projects that used this model because it makes rebuilding the environment easy since it's not so intermingled with the system Python. I'm not sure that this is the best model, but it's certainly prevalent, at least in the Python and Ruby world (RVM does this too). On Mon, Jul 23, 2012 at 5:22 PM, Eric Sammons wrote: > > > ----- Original Message ----- > > On 23.7.2012 23:05, Eric Sammons wrote: > > >>> among developers. Then python can live in ~/myenv/bin/python as > > >>> > > well as > > >>> > > many dependencies under ~/myenv/lib/python2.X/site-packages > > >>> > > which > > >>> > > /usr/bin/python will never find, or worse, different > > >>> > > versions. I > > >>> > > imagine > > >>> > > something similar may exist in the ruby world. > > > > And that ~/myenv/bin/python is python 2.4, 2.6, or 3.0? All of them > > behave *very* differently. > > > > > Again wrt virtualenv, here is an example: > > > > > > $ virtualenv testme > > > $ cd testme > > > $ source bin/activate > > > $ which python > > > ~/testme/bin/python > > > > > > Note, if you were using /usr/bin/python you would_not_ be testing > > > the python binary in "testme". > > > > That can be ok for quick'n'dirty code, where you want fast > > alternation > > without too much work. But who would do such thing in production? > > > > Mirek > > I actually do know IT shops that only run python code this way as it > ensures that no stray libraries are in use or installed. But yes primarily > used for Dev and Test (I use only for test, honestly). However, I still > fall back to the use where shops actually do override the default $PATH to > ensure they are using their in house compiled "GOLD" version of python. > > Many (many) customers feel that our interpreters are always behind and the > versioning.release stuff confuses them so to be sure they are getting (for > example) pure python-2.7 they will install python-2.7 into /usr/local/ and > then change path to reference /usr/local/bin first. Again, in this manner > /usr/bin/python breaks. > > --Eric > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmccune at redhat.com Mon Jul 23 23:59:42 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 23 Jul 2012 16:59:42 -0700 Subject: [katello-devel] merged github guide pages Message-ID: <500DE56E.2070707@redhat.com> merged the existing git pages we had into: https://fedorahosted.org/katello/wiki/GitGuide updated the old: https://fedorahosted.org/katello/wiki/GitHubPullRequestProcess to point to the above page -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From ewoud+katello at kohlvanwijngaarden.nl Tue Jul 24 10:29:04 2012 From: ewoud+katello at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Tue, 24 Jul 2012 12:29:04 +0200 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <500DBE0C.1040606@redhat.com> References: <1773869948.1549753.1343077549975.JavaMail.root@redhat.com> <500DBE0C.1040606@redhat.com> Message-ID: <20120724101528.GC3793@bogey.xentower.nl> On Mon, Jul 23, 2012 at 11:11:40PM +0200, Miroslav Suchy wrote: > On 23.7.2012 23:05, Eric Sammons wrote: > >>>among developers. Then python can live in ~/myenv/bin/python as > >>>> > well as > >>>> > many dependencies under ~/myenv/lib/python2.X/site-packages which > >>>> > /usr/bin/python will never find, or worse, different versions. I > >>>> > imagine > >>>> > something similar may exist in the ruby world. > > And that ~/myenv/bin/python is python 2.4, 2.6, or 3.0? All of them > behave *very* differently. If you take a look at tox[1] you will see that it heavily uses this. It makes it easy to test your software under 2.6, 2.7 and 3.0 for example. A common use case is test your django application under python 2.6 & 2.7 and django 1.3 & 1.4 (so 4 environments). [1]: http://tox.readthedocs.org/en/latest/index.html From jbowes at redhat.com Tue Jul 24 10:45:02 2012 From: jbowes at redhat.com (James Bowes) Date: Tue, 24 Jul 2012 07:45:02 -0300 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <500DBE0C.1040606@redhat.com> References: <1773869948.1549753.1343077549975.JavaMail.root@redhat.com> <500DBE0C.1040606@redhat.com> Message-ID: <20120724104501.GF7489@pipboy.redhat.com> On Mon, Jul 23, 2012 at 11:11:40PM +0200, Miroslav Suchy wrote: > On 23.7.2012 23:05, Eric Sammons wrote: > >>>among developers. Then python can live in ~/myenv/bin/python as > >>>> > well as > >>>> > many dependencies under ~/myenv/lib/python2.X/site-packages which > >>>> > /usr/bin/python will never find, or worse, different versions. I > >>>> > imagine > >>>> > something similar may exist in the ruby world. > > And that ~/myenv/bin/python is python 2.4, 2.6, or 3.0? All of them > behave *very* differently. > You can't ensure that /usr/bin/python is a particular version, either. Unless you use a versioned rpm dep pinned at some particular version, as '>=' will likely break you down the road, anyways. I've always enjoyed simply supporting as many python versions as possible from a single code base. It makes for a delightful intellectual exercise. > >Again wrt virtualenv, here is an example: > > > >$ virtualenv testme > >$ cd testme > >$ source bin/activate > >$ which python > >~/testme/bin/python > > > >Note, if you were using /usr/bin/python you would_not_ be testing the python binary in "testme". > > That can be ok for quick'n'dirty code, where you want fast > alternation without too much work. But who would do such thing in > production? > > Mirek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -James -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From lzap at redhat.com Tue Jul 24 12:24:57 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 24 Jul 2012 14:24:57 +0200 Subject: [katello-devel] Using katello client remember with username and password In-Reply-To: <1194714803.973288.1343069694625.JavaMail.root@redhat.com> References: <1194714803.973288.1343069694625.JavaMail.root@redhat.com> Message-ID: <20120724122457.GA6546@lzapx.brq.redhat.com> It should work with all possible options except username/password. We should maybe update the man page. LZ On Mon, Jul 23, 2012 at 02:54:54PM -0400, Og Maciel wrote: > Wondering if I'm missing something or perhaps misunderstood what the client remember options really do: > > [root at qetello02 ~]# katello client remember --option=username --value=admin > Successfully overwrote option [ username ] > [root at qetello02 ~]# katello client remember --option=password --value=admin > Successfully overwrote option [ password ] > [root at qetello02 ~]# katello user list > Invalid credentials or unable to authenticate > > > -- > Og Maciel > > Senior QA Engineer > Red Hat, Inc. > +1.919.754.4782 > irc: omaciel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From esammons at redhat.com Tue Jul 24 12:27:01 2012 From: esammons at redhat.com (Eric Sammons) Date: Tue, 24 Jul 2012 08:27:01 -0400 (EDT) Subject: [katello-devel] Using katello client remember with username and password In-Reply-To: <20120724122457.GA6546@lzapx.brq.redhat.com> Message-ID: <1476488615.1935672.1343132821096.JavaMail.root@redhat.com> ----- Original Message ----- > It should work with all possible options except username/password. We > should maybe update the man page. > > LZ And create a warning or error message that username and password are not supported. --Eric > > On Mon, Jul 23, 2012 at 02:54:54PM -0400, Og Maciel wrote: > > Wondering if I'm missing something or perhaps misunderstood what > > the client remember options really do: > > > > [root at qetello02 ~]# katello client remember --option=username > > --value=admin > > Successfully overwrote option [ username ] > > [root at qetello02 ~]# katello client remember --option=password > > --value=admin > > Successfully overwrote option [ password ] > > [root at qetello02 ~]# katello user list > > Invalid credentials or unable to authenticate > > > > > > -- > > Og Maciel > > > > Senior QA Engineer > > Red Hat, Inc. > > +1.919.754.4782 > > irc: omaciel > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jomara at redhat.com Tue Jul 24 13:27:05 2012 From: jomara at redhat.com (Jordan OMara) Date: Tue, 24 Jul 2012 09:27:05 -0400 Subject: [katello-devel] katello-upgrade restarting services Message-ID: <20120724132705.GG12706@redhat.com> eric filed this bug: https://bugzilla.redhat.com/show_bug.cgi?id=820280 og filed a similar one: https://bugzilla.redhat.com/show_bug.cgi?id=837866 a pull request: https://github.com/Katello/katello/pull/331 However, lzap & msuchy have brought up that this might be poor behavior or very confusing to a sysadmin and that they would want to almost always stop services themselves before starting the upgrade process. I don't have enough sysadmin experience to make a good decision so I wanted to bring it up to the list. tl;dr: katello-upgrade currently fails if you haven't stopped your services. the pull requests makes the script stop them for you my uninformed 2c: the patch is fairly innocuous because you can decline to have the script stop anything and exit DISCUSS -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From sam at kottlerdevelopment.com Tue Jul 24 13:36:22 2012 From: sam at kottlerdevelopment.com (Sam Kottler) Date: Tue, 24 Jul 2012 09:36:22 -0400 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <20120724132705.GG12706@redhat.com> References: <20120724132705.GG12706@redhat.com> Message-ID: How about checking if the service is running and then reacting based on that. If the service is running then katello-upgrade command will exit and alert the sysadmin that he/she should stop the service. If not, then upgrade can continue. Thoughts? On Tue, Jul 24, 2012 at 9:27 AM, Jordan OMara wrote: > eric filed this bug: https://bugzilla.redhat.com/**show_bug.cgi?id=820280 > og filed a similar one: https://bugzilla.redhat.com/** > show_bug.cgi?id=837866 > a pull request: https://github.com/Katello/**katello/pull/331 > > However, lzap & msuchy have brought up that this might be poor > behavior or very confusing to a sysadmin and that they would want to > almost always stop services themselves before starting the upgrade > process. I don't have enough sysadmin experience to make a good > decision so I wanted to bring it up to the list. > > tl;dr: katello-upgrade currently fails if you haven't stopped your > services. the pull requests makes the script stop them for you > > my uninformed 2c: the patch is fairly innocuous because you can > decline to have the script stop anything and exit > > DISCUSS > -- > Jordan O'Mara > Red Hat Engineering, Raleigh > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrist at redhat.com Tue Jul 24 13:41:25 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 24 Jul 2012 07:41:25 -0600 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: References: <20120724132705.GG12706@redhat.com> Message-ID: <500EA605.4010009@redhat.com> On Tue 24 Jul 2012 07:36:22 AM MDT, Sam Kottler wrote: > How about checking if the service is running and then reacting based on > that. If the service is running then katello-upgrade command will exit and > alert the sysadmin that he/she should stop the service. If not, then > upgrade can continue. > > Thoughts? > > On Tue, Jul 24, 2012 at 9:27 AM, Jordan OMara wrote: > >> eric filed this bug: https://bugzilla.redhat.com/**show_bug.cgi?id=820280 >> og filed a similar one: https://bugzilla.redhat.com/** >> show_bug.cgi?id=837866 >> a pull request: https://github.com/Katello/**katello/pull/331 >> >> However, lzap& msuchy have brought up that this might be poor >> behavior or very confusing to a sysadmin and that they would want to >> almost always stop services themselves before starting the upgrade >> process. I don't have enough sysadmin experience to make a good >> decision so I wanted to bring it up to the list. >> >> tl;dr: katello-upgrade currently fails if you haven't stopped your >> services. the pull requests makes the script stop them for you >> >> my uninformed 2c: the patch is fairly innocuous because you can >> decline to have the script stop anything and exit >> >> DISCUSS >> -- >> Jordan O'Mara >> Red Hat Engineering, Raleigh >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> >> > > Seems obvious when you put it that way... -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jomara at redhat.com Tue Jul 24 13:42:53 2012 From: jomara at redhat.com (Jordan OMara) Date: Tue, 24 Jul 2012 09:42:53 -0400 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: References: <20120724132705.GG12706@redhat.com> Message-ID: <20120724134253.GH12706@redhat.com> On 24/07/12 09:36 -0400, Sam Kottler wrote: >How about checking if the service is running and then reacting based on >that. If the service is running then katello-upgrade command will exit and >alert the sysadmin that he/she should stop the service. If not, then >upgrade can continue. > >Thoughts? > This is exactly the current (pre-pull request) behavior The patched behavior is to check, notify and then ask if they want the script to stop the services for them. If they select N, it exits -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From sam at kottlerdevelopment.com Tue Jul 24 13:43:46 2012 From: sam at kottlerdevelopment.com (Sam Kottler) Date: Tue, 24 Jul 2012 09:43:46 -0400 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <20120724132705.GG12706@redhat.com> References: <20120724132705.GG12706@redhat.com> Message-ID: Ha! I should have read it. Cool, well I like that :) On Tue, Jul 24, 2012 at 9:27 AM, Jordan OMara wrote: > eric filed this bug: https://bugzilla.redhat.com/**show_bug.cgi?id=820280 > og filed a similar one: https://bugzilla.redhat.com/** > show_bug.cgi?id=837866 > a pull request: https://github.com/Katello/**katello/pull/331 > > However, lzap & msuchy have brought up that this might be poor > behavior or very confusing to a sysadmin and that they would want to > almost always stop services themselves before starting the upgrade > process. I don't have enough sysadmin experience to make a good > decision so I wanted to bring it up to the list. > > tl;dr: katello-upgrade currently fails if you haven't stopped your > services. the pull requests makes the script stop them for you > > my uninformed 2c: the patch is fairly innocuous because you can > decline to have the script stop anything and exit > > DISCUSS > -- > Jordan O'Mara > Red Hat Engineering, Raleigh > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From esammons at redhat.com Tue Jul 24 13:48:21 2012 From: esammons at redhat.com (Eric Sammons) Date: Tue, 24 Jul 2012 09:48:21 -0400 (EDT) Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <500EA605.4010009@redhat.com> Message-ID: <1745343611.2002644.1343137701623.JavaMail.root@redhat.com> ----- Original Message ----- > On Tue 24 Jul 2012 07:36:22 AM MDT, Sam Kottler wrote: > > How about checking if the service is running and then reacting > > based on > > that. If the service is running then katello-upgrade command will > > exit and > > alert the sysadmin that he/she should stop the service. If not, > > then > > upgrade can continue. > > > > Thoughts? > > > > On Tue, Jul 24, 2012 at 9:27 AM, Jordan OMara > > wrote: > > > >> eric filed this bug: > >> https://bugzilla.redhat.com/**show_bug.cgi?id=820280 > >> og filed a similar one: https://bugzilla.redhat.com/** > >> show_bug.cgi?id=837866 I opened the bug because unfortunately SAM and CFSE have not just one rc script but many and the order may be a factor here, to protect the databases (I'm not sure). I feel like, for this to feel like a finished product, that it should stop the services correctly. As a safety measure though I do not think that a simple [Y/N] will suffice, it should be a [Yes/No] and it should be very clear what is about to happen, perhaps even a second confirmation to be sure. i.e. when you run rpm -Uhv on any thing you never ask the sysadmin to stop / start any daemons. So to remain consistent with that expectation the script should handle this. It also protects the companies that try to automate the upgrade task (and yes there are customers that will do that) and it also protects sysadmins that are in a hurry to get the job done. Keep in mind, if we don't include stopping the services in the script the sysadmin will simply write a script that does it for them. They seek to have the least amount of down time, and typing out long commands == downtime. My $0.02. -- Eric > >> a pull request: > >> https://github.com/Katello/**katello/pull/331 > >> > >> However, lzap& msuchy have brought up that this might be poor > >> behavior or very confusing to a sysadmin and that they would want > >> to > >> almost always stop services themselves before starting the upgrade > >> process. I don't have enough sysadmin experience to make a good > >> decision so I wanted to bring it up to the list. > >> > >> tl;dr: katello-upgrade currently fails if you haven't stopped your > >> services. the pull requests makes the script stop them for you > >> > >> my uninformed 2c: the patch is fairly innocuous because you can > >> decline to have the script stop anything and exit > >> > >> DISCUSS > >> -- > >> Jordan O'Mara > >> Red Hat Engineering, Raleigh > >> _______________________________________________ > >> katello-devel mailing list > >> katello-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/katello-devel > >> > >> > > > > > > > Seems obvious when you put it that way... > From jsherril at redhat.com Tue Jul 24 13:57:31 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 24 Jul 2012 09:57:31 -0400 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <20120724134253.GH12706@redhat.com> References: <20120724132705.GG12706@redhat.com> <20120724134253.GH12706@redhat.com> Message-ID: <500EA9CB.70506@redhat.com> On 07/24/2012 09:42 AM, Jordan OMara wrote: > On 24/07/12 09:36 -0400, Sam Kottler wrote: >> How about checking if the service is running and then reacting based on >> that. If the service is running then katello-upgrade command will >> exit and >> alert the sysadmin that he/she should stop the service. If not, then >> upgrade can continue. >> >> Thoughts? >> > > This is exactly the current (pre-pull request) behavior > > The patched behavior is to check, notify and then ask if they want the > script to stop the services for them. If they select N, it exits > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I wasn't a big fan of the behaviour (actually i thought it stunk). I like the script asking to stop the services and doing it for you, but if we don't like that I would at least ask for the following: a) Have the script print out ALL services that are still running. Currently it would just print out one until you stopped that one, and then would print out the 2nd, etc... When you have 5+ init scripts this is extremely annoying. b) Have the script print out the commands to stop the running services. Something like: The following services are running and need to be stopped: tomcat6 katello-jobs Please run the following commands to stop them: service tomcat6 stop service katello-jobs stop To me that would go a long way to fixing the annoyances without having to have the script reliably stop all the services. -Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: From tstrachota at redhat.com Tue Jul 24 14:29:58 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Tue, 24 Jul 2012 16:29:58 +0200 Subject: [katello-devel] Foreman skin design spike Message-ID: <500EB166.609@redhat.com> Team, I've finished a design spike to make Foreman look like Katello. So far it seems that we can make most of the skinning without bigger problems just by creating new styles for the bootstrap css & js library. You can checkout summary of the investigation and some screenshots on our wiki https://fedorahosted.org/katello/wiki/ForemanSkinDesign Please note that not everything has been styled. Eg. most of the buttons have still it's original look. I didn't want to loose much time with it since there's a fair chance that we will just throw it away. Questions and ideas are welcome. Tomas From omaciel at redhat.com Tue Jul 24 14:46:03 2012 From: omaciel at redhat.com (Og Maciel) Date: Tue, 24 Jul 2012 10:46:03 -0400 (EDT) Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <1745343611.2002644.1343137701623.JavaMail.root@redhat.com> Message-ID: <474503674.2064286.1343141163623.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eric Sammons" > To: jrist at redhat.com > Cc: katello-devel at redhat.com > Sent: Tuesday, July 24, 2012 9:48:21 AM > Subject: Re: [katello-devel] katello-upgrade restarting services > > [...] I feel like, for this to feel like a > finished product, that it should stop the services correctly. As a > safety measure though I do not think that a simple [Y/N] will > suffice, it should be a [Yes/No] and it should be very clear what is > about to happen, perhaps even a second confirmation to be sure. This is exactly how I feel as well. It's about making the whole experience as smooth as possible. -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From omaciel at redhat.com Tue Jul 24 14:48:39 2012 From: omaciel at redhat.com (Og Maciel) Date: Tue, 24 Jul 2012 10:48:39 -0400 (EDT) Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <500EA9CB.70506@redhat.com> Message-ID: <145919292.2066352.1343141319334.JavaMail.root@redhat.com> > I wasn't a big > fan of the behaviour (actually i thought it stunk). I like the > script asking to stop the services and doing it for you, but if we > don't like that I would at least ask for the following: > > a) Have the script print out ALL services that are still running. > Currently it would just print out one until you stopped that one, > and then would print out the 2nd, etc... When you have 5+ init > scripts this is extremely annoying. > > b) Have the script print out the commands to stop the running > services. Something like: > > The following services are running and need to be stopped: tomcat6 > katello-jobs > Please run the following commands to stop them: > service tomcat6 stop > service katello-jobs stop > > > To me that would go a long way to fixing the annoyances without > having to have the script reliably stop all the services. What Justin said: +1 -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From hbrock at redhat.com Tue Jul 24 14:54:17 2012 From: hbrock at redhat.com (Hugh O. Brock) Date: Tue, 24 Jul 2012 10:54:17 -0400 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <145919292.2066352.1343141319334.JavaMail.root@redhat.com> References: <500EA9CB.70506@redhat.com> <145919292.2066352.1343141319334.JavaMail.root@redhat.com> Message-ID: <20120724145416.GY1780@redhat.com> On Tue, Jul 24, 2012 at 10:48:39AM -0400, Og Maciel wrote: > > I wasn't a big > > fan of the behaviour (actually i thought it stunk). I like the > > script asking to stop the services and doing it for you, but if we > > don't like that I would at least ask for the following: > > > > a) Have the script print out ALL services that are still running. > > Currently it would just print out one until you stopped that one, > > and then would print out the 2nd, etc... When you have 5+ init > > scripts this is extremely annoying. > > > > b) Have the script print out the commands to stop the running > > services. Something like: > > > > The following services are running and need to be stopped: tomcat6 > > katello-jobs > > Please run the following commands to stop them: > > service tomcat6 stop > > service katello-jobs stop > > > > > > To me that would go a long way to fixing the annoyances without > > having to have the script reliably stop all the services. > > What Justin said: +1 > -- > Og Maciel > Good advice from the guy who actually has to use the script, over and over again... --H -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From msuchy at redhat.com Tue Jul 24 15:11:05 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Tue, 24 Jul 2012 17:11:05 +0200 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <1745343611.2002644.1343137701623.JavaMail.root@redhat.com> References: <1745343611.2002644.1343137701623.JavaMail.root@redhat.com> Message-ID: <500EBB09.6020409@redhat.com> On 07/24/2012 03:48 PM, Eric Sammons wrote: > Keep in mind, if we don't include stopping the services in the script the sysadmin will simply write a script that does it for them. They seek to have the least amount of down time, and typing out long commands == downtime. They do not need to write such script. We already provide this script: katello-services -- Miroslav Suchy Red Hat Systems Management Engineering From hbrock at redhat.com Tue Jul 24 15:13:15 2012 From: hbrock at redhat.com (Hugh O. Brock) Date: Tue, 24 Jul 2012 11:13:15 -0400 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <500447E4.1030509@redhat.com> References: <500440E6.5060707@redhat.com> <500447E4.1030509@redhat.com> Message-ID: <20120724151315.GA1780@redhat.com> On Mon, Jul 16, 2012 at 06:57:08PM +0200, Ivan Ne?as wrote: > > With funzo, we're trying to figure out how the Aeolus + Katello could > better integrate together. > > The templates in Katello are going to be replaced with component outlines. In > discussion about Foreman integration, it was not mentioned, that the > Compontent Outline will contain the list of packages (System Template > like we know it today has it). This is not required by Foreman (Foreman > solves it with Puppet), but Aeolus is able to take the list of > packages and install it into the built image, if I understand it > correctly. Was it meant to be this way, or we just skipped it when > talking about Foreman. It seems quite valuable Aeolus feature to me. Yeah, users do want to be able to do image based provisioning, in some cases with quite complex images. In fact I was discussing with Ian Mcleod the other day the idea that Factory might need to grow the ability to invoke Puppet after it finishes running the native installer when building the image (or running scripts on a pre-build JEOS). Another option, quite seriously, would be to look at having Factory use Puppet to resolve package requirements just as Foreman does. Historically we have shied away from this approach because RPM should take care of packaging requirements... but if we want to build something that isn't RPM based, well, that won't work. Factory guys, any thoughts? > Another thing to solve is how to call back to Katello after the > instance was deployed by Aeolus (if we're not satisfied with the > current status of setting the script manually in deployable, which I > guess we're not). It seems for now that Audrey is the only way how to > run some scripts after the image was deployed. Will there we some other > way for running scripts after deployment in Cloud Engine. If not, it > seems that we will need to run Audrey and Puppet side by side. Maybe > it's ok, just asking, if its acceptable to have two config servers run > against the same machine? There's some interesting work going on with cloud-init that may eliminate the Audrey requirement. Joe Vlcek is driving that, we might check with him. --Hugh > Ohad: > > How does Foreman solve the EC2 deployment against Foreman? > > -- > Ivan > > > > -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From jlabocki at redhat.com Tue Jul 24 15:31:58 2012 From: jlabocki at redhat.com (James Labocki) Date: Tue, 24 Jul 2012 11:31:58 -0400 (EDT) Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <20120724151315.GA1780@redhat.com> Message-ID: <1049727789.5933950.1343143918982.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Hugh O. Brock" > To: "Ivan Ne?as" > Cc: aeolus-devel at fedorahosted.org, katello-devel at redhat.com > Sent: Tuesday, July 24, 2012 11:13:15 AM > Subject: Re: Improving Aeolus + Katello integration > > On Mon, Jul 16, 2012 at 06:57:08PM +0200, Ivan Ne?as wrote: > > > > With funzo, we're trying to figure out how the Aeolus + Katello > > could > > better integrate together. > > > > The templates in Katello are going to be replaced with component > > outlines. In > > discussion about Foreman integration, it was not mentioned, that > > the > > Compontent Outline will contain the list of packages (System > > Template > > like we know it today has it). This is not required by Foreman > > (Foreman > > solves it with Puppet), but Aeolus is able to take the list of > > packages and install it into the built image, if I understand it > > correctly. Was it meant to be this way, or we just skipped it when > > talking about Foreman. It seems quite valuable Aeolus feature to > > me. > > Yeah, users do want to be able to do image based provisioning, in > some > cases with quite complex images. In fact I was discussing with Ian > Mcleod the other day the idea that Factory might need to grow the > ability to invoke Puppet after it finishes running the native > installer when building the image (or running scripts on a pre-build > JEOS). > > Another option, quite seriously, would be to look at having Factory > use Puppet to resolve package requirements just as Foreman > does. Historically we have shied away from this approach because RPM > should take care of packaging requirements... but if we want to build > something that isn't RPM based, well, that won't work. Factory guys, > any thoughts? > > > Another thing to solve is how to call back to Katello after the > > instance was deployed by Aeolus (if we're not satisfied with the > > current status of setting the script manually in deployable, which > > I > > guess we're not). It seems for now that Audrey is the only way how > > to > > run some scripts after the image was deployed. Will there we some > > other > > way for running scripts after deployment in Cloud Engine. If not, > > it > > seems that we will need to run Audrey and Puppet side by side. > > Maybe > > it's ok, just asking, if its acceptable to have two config servers > > run > > against the same machine? I think we are close to solving an important problem that has plagued IT ops. The ability to make changes to a running system (in dev, for example) and then bring those changes back into the system description to then promote to other environment seamlessly (QA, prod for example). From my point of view we have the following technologies. Provisioning build based (katello) - component outlines in katello image based (imagefactory) - images built from component outline Run-time configuration audrey - used for boot time config foreman/puppet - after boot, used for ongoing configuration management cloud-init - not sure where this fits exactly yet, but I guess it might replace audrey The real value to end users would be if we could take changes in an image and rectify them to the build description (component outline) and then systematically update the images if a user desired. The key is having workflow and ties between imagefactory/foreman/puppet. Also, I would also submit it's important to keep our eyes on the horizon and understand the openshift cartridge framework and how it fits into the story as well. https://bugzilla.redhat.com/show_bug.cgi?id=842755 -James > > There's some interesting work going on with cloud-init that may > eliminate the Audrey requirement. Joe Vlcek is driving that, we might > check with him. > > --Hugh > > > Ohad: > > > > How does Foreman solve the EC2 deployment against Foreman? > > > > -- > > Ivan > > > > > > > > > > -- > == Hugh Brock, hbrock at redhat.com == > == Engineering Manager, Cloud BU == > == Aeolus Project: Manage virtual infrastructure across clouds. == > == http://aeolusproject.org == > > "I know that you believe you understand what you think I said, but > I?m > not sure you realize that what you heard is not what I meant." > --Robert McCloskey > From vvaldez at redhat.com Tue Jul 24 16:12:51 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Tue, 24 Jul 2012 11:12:51 -0500 Subject: [katello-devel] katello-devel Digest, Vol 15, Issue 26 In-Reply-To: References: Message-ID: <51968BF4-2142-43E2-856E-6757E6F436AC@redhat.com> On Jul 19, 2012, at 6:42 AM, katello-devel-request at redhat.com wrote: > Date: Thu, 19 Jul 2012 12:36:10 +0200 > From: Lukas Zapletal > To: katello-devel at redhat.com > Subject: Re: [katello-devel] Do you want to be a movie star? > Message-ID: <20120719103610.GG4554 at lzapx.brq.redhat.com> > Content-Type: text/plain; charset=us-ascii > > Nice, but why 30 fps? That's too much. Five to ten is way enough saving > bandwidth so image is ultra-sharp. Here is my recordmydesktop script > (kudos to Jeff Weiss and google.com): > > https://gist.github.com/3142880 > > The only drawback is it always records whole screen (if you have > multiple monitors then both screens) when using Gnome Shell and other > modern desktops (it has only one screen from the X11 perspective). > So the hack is to uncomment that RESOLUTION variable and set it > properly, so it will only record the first screen (left one in my case). > You need this only if you have multi-monitor setup! > > Just run it in an empty folder and file will be recorded and encoded > properly for YouTube. I like this approach very much, it's easy and it > gives the best possible quality. > > I have added the link on the page. If no one has signed up to work on these, I'll take the lead on them. I've actually done quite a bit of testing with different screencasting software, and I will say that using ffmpeg directly is the most flexible. RecordMyDesktop is fast, simple, and easy. However, the encoded .ogv is difficult to edit, if you want to add transitions, insert additional graphics, and so forth, you really need to render the video out to individual frames first. This is where 30 fps is fantastic. Then you'd want to re-render it back to a movie after editing. If you just want to capture your screen and are not plagued with perfectionism, RMD is all you need. I posted a very lengthy (all FOSS) method for screencasting here: http://vinnyvaldez.blogspot.com/2011/09/screencasting-and-video-production-with.html Using ffmpeg isn't too difficult (these are similar to what Lukas posted, but without sound). First, determine X11 settings to use for capture: $ xwininfo | grep -e Width -e Height -e Absolute Then click on the target window to record. Output will look like this for a single-monitor system: Absolute upper-left X: 0 Absolute upper-left Y: 0 Width: 1920 Then start ffmpeg with these options: $ ffmpeg -f x11grab -s hd1080 -r 30 -i :0.0+nomouse -vcodec libx264 -vpre lossless_ultrafast output.mp4 If you have a two-monitor setup, here is an example of using nthe 2nd monitor to record: $ ffmpeg -f x11grab -s hd1080 -r 30 -i :0.0+1920,0+nomouse -vcodec libx264 -vpre lossless_ultrafast output.mp4 The advantage is the encoded output is directly editable in every software I've tried, with almost no quality loss. With RMD I tended to end up with dirty frames when editing it. You can always specify a different codec, or even use something like ffmpeg2theora when editing is done if you want open formats. For editing, I prefer Blender, but it comes with a steep learning curve if you just want to use it for editing. OpenShot is a great alternative. If you have a Mac, I've found ScreenFlow is a dream and does everything: http://www.telestream.net/screen-flow/ I prefer editing the videos to near completion, then adding a narration track afterwards using Audacity. In any case, I'll start on these soon unless work is already underway. Vinny Valdez, RHCA, RHCSS, RHCVA (110-119-187) Principal Architect Global Solutions & Strategy Office +1 (650) 260-4846 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ohadlevy at redhat.com Wed Jul 25 07:07:06 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 25 Jul 2012 10:07:06 +0300 Subject: [katello-devel] katello-devel Digest, Vol 15, Issue 26 In-Reply-To: <51968BF4-2142-43E2-856E-6757E6F436AC@redhat.com> References: <51968BF4-2142-43E2-856E-6757E6F436AC@redhat.com> Message-ID: <500F9B1A.3040004@redhat.com> On 07/24/2012 07:12 PM, Vinny Valdez wrote: > On Jul 19, 2012, at 6:42 AM, katello-devel-request at redhat.com > wrote: > >> Date: Thu, 19 Jul 2012 12:36:10 +0200 >> From: Lukas Zapletal > >> To:katello-devel at redhat.com >> Subject: Re: [katello-devel] Do you want to be a movie star? >> Message-ID: <20120719103610.GG4554 at lzapx.brq.redhat.com >> > >> Content-Type: text/plain; charset=us-ascii >> >> Nice, but why 30 fps? That's too much. Five to ten is way enough saving >> bandwidth so image is ultra-sharp. Here is my recordmydesktop script >> (kudos to Jeff Weiss andgoogle.com ): >> >> https://gist.github.com/3142880 >> >> The only drawback is it always records whole screen (if you have >> multiple monitors then both screens) when using Gnome Shell and other >> modern desktops (it has only one screen from the X11 perspective). >> So the hack is to uncomment that RESOLUTION variable and set it >> properly, so it will only record the first screen (left one in my case). >> You need this only if you have multi-monitor setup! >> >> Just run it in an empty folder and file will be recorded and encoded >> properly for YouTube. I like this approach very much, it's easy and it >> gives the best possible quality. >> >> I have added the link on the page. > > If no one has signed up to work on these, I'll take the lead on them. > I've actually done quite a bit of testing with different screencasting > software, and I will say that using ffmpeg directly is the most > flexible. RecordMyDesktop is fast, simple, and easy. However, the > encoded .ogv is difficult to edit, if you want to add transitions, > insert additional graphics, and so forth, you really need to render the > video out to individual frames first. This is where 30 fps is fantastic. > Then you'd want to re-render it back to a movie after editing. If you > just want to capture your screen and are not plagued with perfectionism, > RMD is all you need. I posted a very lengthy (all FOSS) method for > screencasting here: > http://vinnyvaldez.blogspot.com/2011/09/screencasting-and-video-production-with.html > > Using ffmpeg isn't too difficult (these are similar to what Lukas > posted, but without sound). First, determine X11 settings to use for > capture: > $ xwininfo | grep -e Width -e Height -e Absolute > > Then click on the target window to record. Output will look like this > for a single-monitor system: > Absolute upper-left X: 0 > Absolute upper-left Y: 0 > Width: 1920 > > Then start ffmpeg with these options: > $ ffmpeg -f x11grab -s hd1080 -r 30 -i :0.0+nomouse -vcodec libx264 > -vpre lossless_ultrafast output.mp4 > > If you have a two-monitor setup, here is an example of using nthe 2nd > monitor to record: > $ ffmpeg -f x11grab -s hd1080 -r 30 -i :0.0+1920,0+nomouse -vcodec > libx264 -vpre lossless_ultrafast output.mp4 > > The advantage is the encoded output is directly editable in every > software I've tried, with almost no quality loss. With RMD I tended to > end up with dirty frames when editing it. You can always specify a > different codec, or even use something like ffmpeg2theora when editing > is done if you want open formats. > > For editing, I prefer Blender, but it comes with a steep learning curve > if you just want to use it for editing. OpenShot is a great alternative. > If you have a Mac, I've found ScreenFlow is a dream and does everything: > http://www.telestream.net/screen-flow/ > > I prefer editing the videos to near completion, then adding a narration > track afterwards using Audacity. > > In any case, I'll start on these soon unless work is already underway. Vinny - great stuff! thanks for sharing, Ohad > > Vinny Valdez, RHCA, RHCSS, RHCVA (110-119-187) > Principal Architect > Global Solutions & Strategy Office > +1 (650) 260-4846 > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From inecas at redhat.com Wed Jul 25 09:56:06 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 25 Jul 2012 11:56:06 +0200 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <1049727789.5933950.1343143918982.JavaMail.root@redhat.com> References: <1049727789.5933950.1343143918982.JavaMail.root@redhat.com> Message-ID: <500FC2B6.9030303@redhat.com> On 07/24/2012 05:31 PM, James Labocki wrote: > > ----- Original Message ----- >> From: "Hugh O. Brock" >> To: "Ivan Ne?as" >> Cc: aeolus-devel at fedorahosted.org, katello-devel at redhat.com >> Sent: Tuesday, July 24, 2012 11:13:15 AM >> Subject: Re: Improving Aeolus + Katello integration >> >> On Mon, Jul 16, 2012 at 06:57:08PM +0200, Ivan Ne?as wrote: >>> With funzo, we're trying to figure out how the Aeolus + Katello >>> could >>> better integrate together. >>> >>> The templates in Katello are going to be replaced with component >>> outlines. In >>> discussion about Foreman integration, it was not mentioned, that >>> the >>> Compontent Outline will contain the list of packages (System >>> Template >>> like we know it today has it). This is not required by Foreman >>> (Foreman >>> solves it with Puppet), but Aeolus is able to take the list of >>> packages and install it into the built image, if I understand it >>> correctly. Was it meant to be this way, or we just skipped it when >>> talking about Foreman. It seems quite valuable Aeolus feature to >>> me. >> Yeah, users do want to be able to do image based provisioning, in >> some >> cases with quite complex images. In fact I was discussing with Ian >> Mcleod the other day the idea that Factory might need to grow the >> ability to invoke Puppet after it finishes running the native >> installer when building the image (or running scripts on a pre-build >> JEOS). >> >> Another option, quite seriously, would be to look at having Factory >> use Puppet to resolve package requirements just as Foreman >> does. Historically we have shied away from this approach because RPM >> should take care of packaging requirements... but if we want to build >> something that isn't RPM based, well, that won't work. Factory guys, >> any thoughts? >> >>> Another thing to solve is how to call back to Katello after the >>> instance was deployed by Aeolus (if we're not satisfied with the >>> current status of setting the script manually in deployable, which >>> I >>> guess we're not). It seems for now that Audrey is the only way how >>> to >>> run some scripts after the image was deployed. Will there we some >>> other >>> way for running scripts after deployment in Cloud Engine. If not, >>> it >>> seems that we will need to run Audrey and Puppet side by side. >>> Maybe >>> it's ok, just asking, if its acceptable to have two config servers >>> run >>> against the same machine? > I think we are close to solving an important problem that has plagued IT ops. The ability to make changes to a running system (in dev, for example) and then bring those changes back into the system description to then promote to other environment seamlessly (QA, prod for example). From my point of view we have the following technologies. > > Provisioning > build based (katello) - component outlines in katello > image based (imagefactory) - images built from component outline > > Run-time configuration > audrey - used for boot time config > foreman/puppet - after boot, used for ongoing configuration management > cloud-init - not sure where this fits exactly yet, but I guess it might replace audrey > > The real value to end users would be if we could take changes in an image and rectify them to the build description (component outline) and then systematically update the images if a user desired. The key is having workflow and ties between imagefactory/foreman/puppet. Also, I would also submit it's important to keep our eyes on the horizon and understand the openshift cartridge framework and how it fits into the story as well. If puppet (or other config framework supported by Katello/Foreman) could by applied in the image build time, I think many of this features would be covered. IMO it's important to keep the configuration on one place, no matter if it's before or after the instance is running. Otherwise it makes for users quite hard to maintain two independent configurations for the same machine. For the OpenShift, after quick going through the concept of cartridges, it seems it would require to create an image with OpenShift node and configure it (maybe also with puppet in case of using Katello/Foreman). The packages for the cartridge are installed directly on the node. Only the config files are placed on different location. And additionaly hooks are separated as well. -- Ivan > > https://bugzilla.redhat.com/show_bug.cgi?id=842755 > > -James > > >> There's some interesting work going on with cloud-init that may >> eliminate the Audrey requirement. Joe Vlcek is driving that, we might >> check with him. >> >> --Hugh >> >>> Ohad: >>> >>> How does Foreman solve the EC2 deployment against Foreman? >>> >>> -- >>> Ivan >>> >>> >>> >>> >> -- >> == Hugh Brock, hbrock at redhat.com == >> == Engineering Manager, Cloud BU == >> == Aeolus Project: Manage virtual infrastructure across clouds. == >> == http://aeolusproject.org == >> >> "I know that you believe you understand what you think I said, but >> I?m >> not sure you realize that what you heard is not what I meant." >> --Robert McCloskey >> -- Ivan From lzap at redhat.com Wed Jul 25 10:09:10 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 Jul 2012 12:09:10 +0200 Subject: [katello-devel] Info: rubygem-popen incompatibility Message-ID: <20120725100910.GA3588@lzapx.brq.redhat.com> Hello, if you are not using Katello on RHEL (or clones), please disregard. The following is meant for developers who rebuild Katello on RHEL 6.2. Today I have discovered there is some incompatibility between our dependency rubygem-popen which we provide in our repos. Due to some ABI change between RHEL 6.2 and RHEL 6.3 binary packages cannot be moved from one system to other. If you try *rebuild* Katello on RHEL 6.2, you will get a SEGFAULT during "jammit" step due to wrong ABI of the POpen4 function. Please note you can still *install* and run Katello on RHEL 6.2. The issue is during build phase, runtime does not use POpen4 function as far as I know. Our new koji builder builds on RHEL 6.3, so it is recommended to use Katello on RHEL 6.3+. -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Wed Jul 25 12:08:39 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 25 Jul 2012 08:08:39 -0400 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <500FC2B6.9030303@redhat.com> References: <1049727789.5933950.1343143918982.JavaMail.root@redhat.com> <500FC2B6.9030303@redhat.com> Message-ID: <500FE1C7.10801@redhat.com> On 07/25/2012 05:56 AM, Ivan Ne?as wrote: > On 07/24/2012 05:31 PM, James Labocki wrote: >> >> ----- Original Message ----- >>> From: "Hugh O. Brock" >>> To: "Ivan Ne?as" >>> Cc: aeolus-devel at fedorahosted.org, katello-devel at redhat.com >>> Sent: Tuesday, July 24, 2012 11:13:15 AM >>> Subject: Re: Improving Aeolus + Katello integration >>> >>> On Mon, Jul 16, 2012 at 06:57:08PM +0200, Ivan Ne?as wrote: >>>> With funzo, we're trying to figure out how the Aeolus + Katello >>>> could >>>> better integrate together. >>>> >>>> The templates in Katello are going to be replaced with component >>>> outlines. In >>>> discussion about Foreman integration, it was not mentioned, that >>>> the >>>> Compontent Outline will contain the list of packages (System >>>> Template >>>> like we know it today has it). This is not required by Foreman >>>> (Foreman >>>> solves it with Puppet), but Aeolus is able to take the list of >>>> packages and install it into the built image, if I understand it >>>> correctly. Was it meant to be this way, or we just skipped it when >>>> talking about Foreman. It seems quite valuable Aeolus feature to >>>> me. >>> Yeah, users do want to be able to do image based provisioning, in >>> some >>> cases with quite complex images. In fact I was discussing with Ian >>> Mcleod the other day the idea that Factory might need to grow the >>> ability to invoke Puppet after it finishes running the native >>> installer when building the image (or running scripts on a pre-build >>> JEOS). >>> >>> Another option, quite seriously, would be to look at having Factory >>> use Puppet to resolve package requirements just as Foreman >>> does. Historically we have shied away from this approach because RPM >>> should take care of packaging requirements... but if we want to build >>> something that isn't RPM based, well, that won't work. Factory guys, >>> any thoughts? >>> >>>> Another thing to solve is how to call back to Katello after the >>>> instance was deployed by Aeolus (if we're not satisfied with the >>>> current status of setting the script manually in deployable, which >>>> I >>>> guess we're not). It seems for now that Audrey is the only way how >>>> to >>>> run some scripts after the image was deployed. Will there we some >>>> other >>>> way for running scripts after deployment in Cloud Engine. If not, >>>> it >>>> seems that we will need to run Audrey and Puppet side by side. >>>> Maybe >>>> it's ok, just asking, if its acceptable to have two config servers >>>> run >>>> against the same machine? >> I think we are close to solving an important problem that has plagued >> IT ops. The ability to make changes to a running system (in dev, for >> example) and then bring those changes back into the system description >> to then promote to other environment seamlessly (QA, prod for >> example). From my point of view we have the following technologies. >> >> Provisioning >> build based (katello) - component outlines in katello >> image based (imagefactory) - images built from component outline >> >> Run-time configuration >> audrey - used for boot time config >> foreman/puppet - after boot, used for ongoing configuration management >> cloud-init - not sure where this fits exactly yet, but I guess >> it might replace audrey I jhad assumed that we would use TDl for build time config, and cloud-init / audrey for initial boot "Find your katello" and then use puppet for initial build time config and ongoing drift. Granted you could do more config via TDL but what I described would be best practice. I had not assmed puppet at buld time would be a high priority. -- bk From lzap at redhat.com Wed Jul 25 12:10:03 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 Jul 2012 14:10:03 +0200 Subject: [katello-devel] Foreman skin design spike In-Reply-To: <500EB166.609@redhat.com> References: <500EB166.609@redhat.com> Message-ID: <20120725121003.GC3588@lzapx.brq.redhat.com> Heh, it really looks like CFSE. Nice work! :-) LZ On Tue, Jul 24, 2012 at 04:29:58PM +0200, Tomas Strachota wrote: > Team, > I've finished a design spike to make Foreman look like Katello. So > far it seems that we can make most of the skinning without bigger > problems just by creating new styles for the bootstrap css & js > library. > > You can checkout summary of the investigation and some screenshots > on our wiki > https://fedorahosted.org/katello/wiki/ForemanSkinDesign > > Please note that not everything has been styled. Eg. most of the > buttons have still it's original look. I didn't want to loose much > time with it since there's a fair chance that we will just throw it > away. > > Questions and ideas are welcome. > > Tomas > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Jul 25 12:19:25 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 Jul 2012 14:19:25 +0200 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <1745343611.2002644.1343137701623.JavaMail.root@redhat.com> References: <500EA605.4010009@redhat.com> <1745343611.2002644.1343137701623.JavaMail.root@redhat.com> Message-ID: <20120725121925.GD3588@lzapx.brq.redhat.com> On Tue, Jul 24, 2012 at 09:48:21AM -0400, Eric Sammons wrote: > I opened the bug because unfortunately SAM and CFSE have not just one rc script but many and the order may be a factor here, to protect the databases (I'm not sure). I feel like, for this to feel like a finished product, that it should stop the services correctly. As a safety measure though I do not think that a simple [Y/N] will suffice, it should be a [Yes/No] and it should be very clear what is about to happen, perhaps even a second confirmation to be sure. > > i.e. when you run rpm -Uhv on any thing you never ask the sysadmin to stop / start any daemons. So to remain consistent with that expectation the script should handle this. It also protects the companies that try to automate the upgrade task (and yes there are customers that will do that) and it also protects sysadmins that are in a hurry to get the job done. Keep in mind, if we don't include stopping the services in the script the sysadmin will simply write a script that does it for them. They seek to have the least amount of down time, and typing out long commands == downtime. > > My $0.02. Let me throw in my two cents. In the original request/bug there was no mention of interactivity. At least I did not see it. I am totally fine with a script that would report required services should be down, just like Justin said. I just don't like the idea of script shutting down any services. If you ever did production upgrade of anything, you know that the sysadmin want to have everything under his control. Specifically he wants to minimize the outage time frame if possible. If there is an interactivity, that is another story. You can always say No if you don't feel while we provide seamless experience for those who want upgrade fast. Together with --assume-yes / -y options this would give you what you want. My personal opinion would be to stop if services are still up printing some info about what to do to successfully continue without any interactivity. But that is my opinion, I can live with yes/no questions. -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Wed Jul 25 12:24:41 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 25 Jul 2012 14:24:41 +0200 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <20120724104501.GF7489@pipboy.redhat.com> References: <1773869948.1549753.1343077549975.JavaMail.root@redhat.com> <500DBE0C.1040606@redhat.com> <20120724104501.GF7489@pipboy.redhat.com> Message-ID: <500FE589.5040400@redhat.com> On 07/24/2012 12:45 PM, James Bowes wrote: > I've always enjoyed simply supporting as many python versions as > possible from a single code base. It makes for a delightful intellectual > exercise. Tell that to GSS. -- Miroslav Suchy Red Hat Systems Management Engineering From jpazdziora at redhat.com Wed Jul 25 12:49:11 2012 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 25 Jul 2012 14:49:11 +0200 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <500FE589.5040400@redhat.com> References: <1773869948.1549753.1343077549975.JavaMail.root@redhat.com> <500DBE0C.1040606@redhat.com> <20120724104501.GF7489@pipboy.redhat.com> <500FE589.5040400@redhat.com> Message-ID: <20120725124911.GA12192@redhat.com> On Wed, Jul 25, 2012 at 02:24:41PM +0200, Miroslav Such? wrote: > On 07/24/2012 12:45 PM, James Bowes wrote: > >I've always enjoyed simply supporting as many python versions as > >possible from a single code base. It makes for a delightful intellectual > >exercise. > > Tell that to GSS. Clearly, the upstream should be runnable on any combination of anything, for the purpose of developer setup games, but once you start building packages for particular distribution, be it RHEL or Fedora, those packages should have a clear dependency on other things in that OS distribution. The best solution seems to be to s%^#!/usr/bin/env\s(\S+)%#!/usr/bin/$1% in rpm build time so that in rpm-based installations, you know what ruby / python / whatever you are using and there are no nasty surprises. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat From jfenal at redhat.com Wed Jul 25 12:57:45 2012 From: jfenal at redhat.com (=?ISO-8859-1?Q?J=E9r=F4me?= Fenal) Date: Wed, 25 Jul 2012 14:57:45 +0200 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <500DA788.5060209@redhat.com> References: <500DA788.5060209@redhat.com> Message-ID: <1343221065.2665.50.camel@localhost.localdomain> Le lundi 23 juillet 2012 ? 21:35 +0200, Miroslav Suchy a ?crit : > Why do you guys prefer #!/usr/bin/env ? > > I seen it twice in today pull requests and git grep show me it is used > several times in our code. > > I understand it may put in game e.g /usr/local/bin/ with locally > compiled python/ruby. But is it what we want? Do we guarantee, that our > code will work with locally modified version of python/ruby? > > I always used plain #!/usr/bin/python or #!/usr/bin/ruby as it gives me > more control and less bug reports. See perlrun(1). -- J?r?me Fenal, RHCE Tel.: +33 1 41 91 23 37 Senior Solutions Architect Mob.: +33 6 88 06 51 15 Comptes strat?giques Finance et Public Fax.: +33 1 41 91 23 32 http://www.fr.redhat.com/ jfenal at redhat.com Red Hat France SARL Siret n? 421 199 464 00064 Le Linea, 1 rue du G?n?ral Leclerc 92047 Paris La D?fense Cedex Red Hat Summit, JBoss World 2012 http://www.redhat.com/summit/ From jomara at redhat.com Wed Jul 25 13:22:58 2012 From: jomara at redhat.com (Jordan OMara) Date: Wed, 25 Jul 2012 09:22:58 -0400 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <20120725121925.GD3588@lzapx.brq.redhat.com> References: <500EA605.4010009@redhat.com> <1745343611.2002644.1343137701623.JavaMail.root@redhat.com> <20120725121925.GD3588@lzapx.brq.redhat.com> Message-ID: <20120725132258.GE18878@redhat.com> On 25/07/12 14:19 +0200, Lukas Zapletal wrote: >On Tue, Jul 24, 2012 at 09:48:21AM -0400, Eric Sammons wrote: >In the original request/bug there was no mention of interactivity. At >least I did not see it. I am totally fine with a script that would >report required services should be down, just like Justin said. > >I just don't like the idea of script shutting down any services. If you >ever did production upgrade of anything, you know that the sysadmin want >to have everything under his control. Specifically he wants to minimize >the outage time frame if possible. > >If there is an interactivity, that is another story. You can always say >No if you don't feel while we provide seamless experience for those who >want upgrade fast. Together with --assume-yes / -y options this would >give you what you want. > >My personal opinion would be to stop if services are still up printing >some info about what to do to successfully continue without any >interactivity. But that is my opinion, I can live with yes/no questions. > I think, lzap, you would be OK with this behavior katello-upgrade (no arguments) ------------------------------ Upgrade stopped! Please stop the following services before continuing: katello tomcat6 postgresql katello-upgrade --auto-stop ----------------------------- The following services are being stopped for the upgrade process: katello tomcat6 postgresql Everyone else like that? It provides an automatic option if you want it but defaults to a more expected behavior for sysadmins -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From esammons at redhat.com Wed Jul 25 13:30:37 2012 From: esammons at redhat.com (Eric Sammons) Date: Wed, 25 Jul 2012 09:30:37 -0400 (EDT) Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <20120725132258.GE18878@redhat.com> Message-ID: <749294452.2753100.1343223037377.JavaMail.root@redhat.com> > I think, lzap, you would be OK with this behavior > > katello-upgrade (no arguments) > ------------------------------ > Upgrade stopped! Please stop the following services before > continuing: > katello > tomcat6 > postgresql > > katello-upgrade --auto-stop > ----------------------------- > The following services are being stopped for the upgrade process: > katello > tomcat6 > postgresql > > Everyone else like that? It provides an automatic option if you want > it but defaults to a more expected behavior for sysadmins +1 I like this solution, that way we give the power to the sysadmins which is truly where it belongs. --Eric From jrist at redhat.com Wed Jul 25 13:36:18 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 25 Jul 2012 07:36:18 -0600 Subject: [katello-devel] Info: rubygem-popen incompatibility In-Reply-To: <20120725100910.GA3588@lzapx.brq.redhat.com> References: <20120725100910.GA3588@lzapx.brq.redhat.com> Message-ID: <500FF652.6060409@redhat.com> On Wed 25 Jul 2012 04:09:10 AM MDT, Lukas Zapletal wrote: > Hello, > > if you are not using Katello on RHEL (or clones), please disregard. The > following is meant for developers who rebuild Katello on RHEL 6.2. > > Today I have discovered there is some incompatibility between our > dependency rubygem-popen which we provide in our repos. Due to some ABI > change between RHEL 6.2 and RHEL 6.3 binary packages cannot be moved > from one system to other. If you try *rebuild* Katello on RHEL 6.2, you > will get a SEGFAULT during "jammit" step due to wrong ABI of the POpen4 > function. > > Please note you can still *install* and run Katello on RHEL 6.2. The > issue is during build phase, runtime does not use POpen4 function as far > as I know. > > Our new koji builder builds on RHEL 6.3, so it is recommended to use > Katello on RHEL 6.3+. Forgive my ignorance, but what is an ABI change? -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jrist at redhat.com Wed Jul 25 13:40:45 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 25 Jul 2012 07:40:45 -0600 Subject: [katello-devel] Foreman skin design spike In-Reply-To: <500EB166.609@redhat.com> References: <500EB166.609@redhat.com> Message-ID: <500FF75D.2030605@redhat.com> On 07/24/2012 08:29 AM, Tomas Strachota wrote: > Team, > I've finished a design spike to make Foreman look like Katello. So far > it seems that we can make most of the skinning without bigger problems > just by creating new styles for the bootstrap css & js library. > > You can checkout summary of the investigation and some screenshots on > our wiki > https://fedorahosted.org/katello/wiki/ForemanSkinDesign > > Please note that not everything has been styled. Eg. most of the buttons > have still it's original look. I didn't want to loose much time with it > since there's a fair chance that we will just throw it away. > > Questions and ideas are welcome. > > Tomas > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Looks very nice. I think some Foreman pages might benefit from Tupane. So what's the next step? Is it worth doing additional work for upstream Foreman to look like another Red Hat CloudForms upstream related product? -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jrist at redhat.com Wed Jul 25 13:44:02 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 25 Jul 2012 07:44:02 -0600 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <20120725132258.GE18878@redhat.com> References: <500EA605.4010009@redhat.com> <1745343611.2002644.1343137701623.JavaMail.root@redhat.com> <20120725121925.GD3588@lzapx.brq.redhat.com> <20120725132258.GE18878@redhat.com> Message-ID: <500FF822.5090301@redhat.com> On 07/25/2012 07:22 AM, Jordan OMara wrote: > On 25/07/12 14:19 +0200, Lukas Zapletal wrote: >> On Tue, Jul 24, 2012 at 09:48:21AM -0400, Eric Sammons wrote: >> In the original request/bug there was no mention of interactivity. At >> least I did not see it. I am totally fine with a script that would >> report required services should be down, just like Justin said. >> >> I just don't like the idea of script shutting down any services. If you >> ever did production upgrade of anything, you know that the sysadmin want >> to have everything under his control. Specifically he wants to minimize >> the outage time frame if possible. >> >> If there is an interactivity, that is another story. You can always say >> No if you don't feel while we provide seamless experience for those who >> want upgrade fast. Together with --assume-yes / -y options this would >> give you what you want. >> >> My personal opinion would be to stop if services are still up printing >> some info about what to do to successfully continue without any >> interactivity. But that is my opinion, I can live with yes/no questions. >> > > I think, lzap, you would be OK with this behavior > > katello-upgrade (no arguments) > ------------------------------ > Upgrade stopped! Please stop the following services before continuing: > katello > tomcat6 > postgresql > > katello-upgrade --auto-stop > ----------------------------- > The following services are being stopped for the upgrade process: > katello > tomcat6 > postgresql > > Everyone else like that? It provides an automatic option if you want > it but defaults to a more expected behavior for sysadmins > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel +1 again -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From omaciel at redhat.com Wed Jul 25 13:59:35 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 25 Jul 2012 09:59:35 -0400 (EDT) Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FEB1903.8070300@redhat.com> Message-ID: <551901893.2770458.1343224775628.JavaMail.root@redhat.com> Sooo... Katello master now uses pulp-1.1.11-1.el6.noarch and we can no longer create i18n names repos... this *is* a change from previous behavior. What are you we going to do about it? Here's the start of the thread: https://www.redhat.com/archives/katello-devel/2012-June/msg00084.html -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From cwelton at redhat.com Wed Jul 25 14:28:23 2012 From: cwelton at redhat.com (corey welton) Date: Wed, 25 Jul 2012 10:28:23 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <551901893.2770458.1343224775628.JavaMail.root@redhat.com> References: <4FEB1903.8070300@redhat.com> <551901893.2770458.1343224775628.JavaMail.root@redhat.com> Message-ID: <20120725102823.002c6b34@huajiao.usersys.redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 25 Jul 2012 09:59:35 -0400 (EDT) Og Maciel wrote: > Sooo... Katello master now uses pulp-1.1.11-1.el6.noarch and we can > no longer create i18n names repos... this *is* a change from previous > behavior. What are you we going to do about it? Here's the start of > the thread: > https://www.redhat.com/archives/katello-devel/2012-June/msg00084.html My 2c on all this: If there's a requirement that something be "user-readable", there needs to be consideration whether such a requirement can be universally applied. Attempting to otherwise implement such a requirement in a manner that can only be applied piecemeal will inevitably lead to difficulty maintaining/fixing it later on down the road. In this case, it appears that due to limitations of yum, multibyte characters cannot be used in repos. At the same time, we have an apparent requirement that repos be "user-readable". If multibyte characters cannot be used in repos, repos cannot, in all cases, be considered "user-readable". Ergo, we have a flaw in the requirement. In the meantime, no longer supporting this results/will result in regressions (initially in terms of bugs and subsequently in end-user functionality) for products like katello which implement pulp -- particularly when, from a user's perspective, the front end should be fully usable with little to no consideration as to how the data looks on the backend. While I agree with the notion of having a user friendly repo URL, I also note the apparent (unfortunate) inability of yum to handle such scenarios. As such, I think the requirement needs to be reconsidered. If user-friendly repo names are desired, we could look into other solutions. A mapping script, perhaps? Who knows. It's 2012, and globalization is a fact of life. The inability to handle multibyte data in any app written in this era should be considered a serious flaw. To be hamstrung by a requirement of "user-readable" when such a requirement cannot be applied universally seems to me to be a misstep. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlAQAooACgkQQISRiYQQweyN1gCeIkFM5BYvNSacO15djeIsbau4 BM8Anjd3vtCnL5MAFkj2plbQerWpcjzk =ZAEc -----END PGP SIGNATURE----- From mrao at redhat.com Wed Jul 25 14:29:22 2012 From: mrao at redhat.com (Malini Rao) Date: Wed, 25 Jul 2012 10:29:22 -0400 (EDT) Subject: [katello-devel] Foreman skin design spike In-Reply-To: <500FF75D.2030605@redhat.com> Message-ID: <1330291060.2513004.1343226562517.JavaMail.root@redhat.com> ----- Original Message ----- From: "Jason Rist" To: katello-devel at redhat.com Sent: Wednesday, July 25, 2012 9:40:45 AM Subject: Re: [katello-devel] Foreman skin design spike On 07/24/2012 08:29 AM, Tomas Strachota wrote: > Team, > I've finished a design spike to make Foreman look like Katello. So far > it seems that we can make most of the skinning without bigger problems > just by creating new styles for the bootstrap css & js library. > > You can checkout summary of the investigation and some screenshots on > our wiki > https://fedorahosted.org/katello/wiki/ForemanSkinDesign Is there an instance that we could see these changes in? The screenshots are useful and the initial changes are looking good but I would like to see a bit more and provide you some feedback from the UX consistency perspective. For instance, in the Environments list screen, if we cannot do a 2-pane, then the location of the 'New Environment' button/ link seems a little odd. > > Please note that not everything has been styled. Eg. most of the buttons > have still it's original look. I didn't want to loose much time with it > since there's a fair chance that we will just throw it away. So what is the plan? Are we going to be hopping on to Foreman that kinda looks like Katello at certain points in the workflow and then jump back into Katello? Is this a short term strategy before we have a more seamless integration? Either way, I think we should have some UX discussions around how these switches happen so that the overall UX is not impacted severely. The fact that Foreman is made to look more like Katello increases the expectation that the overall navigation and UI paradigms will be the same. This is why, I would like to see a demo if possible on a workflow that involves this switch so we can evaluate the usability impact. > > Questions and ideas are welcome. > > Tomas > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Looks very nice. I think some Foreman pages might benefit from Tupane. So what's the next step? Is it worth doing additional work for upstream Foreman to look like another Red Hat CloudForms upstream related product? -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From hbrock at redhat.com Wed Jul 25 14:52:30 2012 From: hbrock at redhat.com (Hugh O. Brock) Date: Wed, 25 Jul 2012 10:52:30 -0400 Subject: [katello-devel] Foreman skin design spike In-Reply-To: <1330291060.2513004.1343226562517.JavaMail.root@redhat.com> References: <500FF75D.2030605@redhat.com> <1330291060.2513004.1343226562517.JavaMail.root@redhat.com> Message-ID: <20120725145229.GG1780@redhat.com> On Wed, Jul 25, 2012 at 10:29:22AM -0400, Malini Rao wrote: > > > ----- Original Message ----- > From: "Jason Rist" > To: katello-devel at redhat.com > Sent: Wednesday, July 25, 2012 9:40:45 AM > Subject: Re: [katello-devel] Foreman skin design spike > > On 07/24/2012 08:29 AM, Tomas Strachota wrote: > > Team, > > I've finished a design spike to make Foreman look like Katello. So far > > it seems that we can make most of the skinning without bigger problems > > just by creating new styles for the bootstrap css & js library. > > > > You can checkout summary of the investigation and some screenshots on > > our wiki > > https://fedorahosted.org/katello/wiki/ForemanSkinDesign > > Is there an instance that we could see these changes in? The screenshots are useful and the initial changes are looking good but I would like to see a bit more and provide you some feedback from the UX consistency perspective. For instance, in the Environments list screen, if we cannot do a 2-pane, then the location of the 'New Environment' button/ link seems a little odd. > > > > Please note that not everything has been styled. Eg. most of the buttons > > have still it's original look. I didn't want to loose much time with it > > since there's a fair chance that we will just throw it away. > > So what is the plan? Are we going to be hopping on to Foreman that kinda looks like Katello at certain points in the workflow and then jump back into Katello? Is this a short term strategy before we have a more seamless integration? Either way, I think we should have some UX discussions around how these switches happen so that the overall UX is not impacted severely. The fact that Foreman is made to look more like Katello increases the expectation that the overall navigation and UI paradigms will be the same. This is why, I would like to see a demo if possible on a workflow that involves this switch so we can evaluate the usability impact. I love the idea of having a Foreman UI skin that makes it look like Cloudforms, that is good stuff. Having said that, I'm fairly certain that we're going to want to be able to build workflows in Katello that touch Foreman objects and we probably want not to force the user to a *third* different webapp, no matter how similar we make it look. This means there is going to have to be some work done in Katello UI to represent Foreman objects, one way or another... --H > > > > > Questions and ideas are welcome. > > > > Tomas > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > Looks very nice. I think some Foreman pages might benefit from Tupane. > > So what's the next step? Is it worth doing additional work for upstream > Foreman to look like another Red Hat CloudForms upstream related product? > > -J > > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From msuchy at redhat.com Wed Jul 25 15:03:49 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 25 Jul 2012 17:03:49 +0200 Subject: [katello-devel] Info: rubygem-popen incompatibility In-Reply-To: <500FF652.6060409@redhat.com> References: <20120725100910.GA3588@lzapx.brq.redhat.com> <500FF652.6060409@redhat.com> Message-ID: <50100AD5.5010708@redhat.com> On 07/25/2012 03:36 PM, Jason Rist wrote: > Forgive my ignorance, but what is an ABI change? http://en.wikipedia.org/wiki/Application_binary_interface -- Miroslav Suchy Red Hat Systems Management Engineering From bbuckingham at redhat.com Wed Jul 25 15:08:45 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Wed, 25 Jul 2012 11:08:45 -0400 Subject: [katello-devel] Foreman skin design spike In-Reply-To: <20120725145229.GG1780@redhat.com> References: <500FF75D.2030605@redhat.com> <1330291060.2513004.1343226562517.JavaMail.root@redhat.com> <20120725145229.GG1780@redhat.com> Message-ID: <50100BFD.8090209@redhat.com> On 07/25/2012 10:52 AM, Hugh O. Brock wrote: > On Wed, Jul 25, 2012 at 10:29:22AM -0400, Malini Rao wrote: >> >> ----- Original Message ----- >> From: "Jason Rist" >> To: katello-devel at redhat.com >> Sent: Wednesday, July 25, 2012 9:40:45 AM >> Subject: Re: [katello-devel] Foreman skin design spike >> >> On 07/24/2012 08:29 AM, Tomas Strachota wrote: >>> Team, >>> I've finished a design spike to make Foreman look like Katello. So far >>> it seems that we can make most of the skinning without bigger problems >>> just by creating new styles for the bootstrap css& js library. >>> >>> You can checkout summary of the investigation and some screenshots on >>> our wiki >>> https://fedorahosted.org/katello/wiki/ForemanSkinDesign >> Is there an instance that we could see these changes in? The screenshots are useful and the initial changes are looking good but I would like to see a bit more and provide you some feedback from the UX consistency perspective. For instance, in the Environments list screen, if we cannot do a 2-pane, then the location of the 'New Environment' button/ link seems a little odd. >>> Please note that not everything has been styled. Eg. most of the buttons >>> have still it's original look. I didn't want to loose much time with it >>> since there's a fair chance that we will just throw it away. >> So what is the plan? Are we going to be hopping on to Foreman that kinda looks like Katello at certain points in the workflow and then jump back into Katello? Is this a short term strategy before we have a more seamless integration? Either way, I think we should have some UX discussions around how these switches happen so that the overall UX is not impacted severely. The fact that Foreman is made to look more like Katello increases the expectation that the overall navigation and UI paradigms will be the same. This is why, I would like to see a demo if possible on a workflow that involves this switch so we can evaluate the usability impact. > I love the idea of having a Foreman UI skin that makes it look like > Cloudforms, that is good stuff. > > Having said that, I'm fairly certain that we're going to want to be > able to build workflows in Katello that touch Foreman objects and we > probably want not to force the user to a *third* different webapp, no > matter how similar we make it look. This means there is going to have > to be some work done in Katello UI to represent Foreman objects, one > way or another... > > --H [brad] This effort is just one of the design spikes that was created. One of the intents was to understand the effort and feasibility of applying the Katello L&F to Foreman. It does not imply a decision to introduce a third webapp to the overall solution. That said, it is good to hear folks feedback as it reinforces some of the discussions the team has been having. Another design spike was to perform a similar exercise where the page is exposed from Katello UI but using the Foreman APIs. This approach would be more consistent with how Katello interfaces with Candlepin and Pulp. >>> Questions and ideas are welcome. >>> >>> Tomas >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> Looks very nice. I think some Foreman pages might benefit from Tupane. >> >> So what's the next step? Is it worth doing additional work for upstream >> Foreman to look like another Red Hat CloudForms upstream related product? >> >> -J >> >> -- >> Jason E. Rist >> Senior Software Engineer >> Systems Management and Cloud Enablement >> Red Hat, Inc. >> +1.919.754.4048 >> Freenode: jrist >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Wed Jul 25 15:17:24 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 Jul 2012 17:17:24 +0200 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <20120725124911.GA12192@redhat.com> References: <1773869948.1549753.1343077549975.JavaMail.root@redhat.com> <500DBE0C.1040606@redhat.com> <20120724104501.GF7489@pipboy.redhat.com> <500FE589.5040400@redhat.com> <20120725124911.GA12192@redhat.com> Message-ID: <20120725151724.GI3588@lzapx.brq.redhat.com> On Wed, Jul 25, 2012 at 02:49:11PM +0200, Jan Pazdziora wrote: > Clearly, the upstream should be runnable on any combination of > anything, for the purpose of developer setup games, but once you > start building packages for particular distribution, be it RHEL > or Fedora, those packages should have a clear dependency on other > things in that OS distribution. > > The best solution seems to be to > > s%^#!/usr/bin/env\s(\S+)%#!/usr/bin/$1% > > in rpm build time so that in rpm-based installations, you know what > ruby / python / whatever you are using and there are no nasty > surprises. +1 By the way this is recommended by default in Fedora 16+: http://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython I guess I would be able to find it in packaging guidelines somewhere. I am pretty sure I have been fixing those at least two times for my (few) fedora packages. Even rpmlint warns about it I believe! Therefore: Do not use env, use direct path. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Jul 25 15:20:21 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 Jul 2012 17:20:21 +0200 Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <1343221065.2665.50.camel@localhost.localdomain> References: <500DA788.5060209@redhat.com> <1343221065.2665.50.camel@localhost.localdomain> Message-ID: <20120725152021.GJ3588@lzapx.brq.redhat.com> On Wed, Jul 25, 2012 at 02:57:45PM +0200, Jerome Fenal wrote: > See perlrun(1). That information is meant for upstream and is not valid for Fedora and RHEL. I believe rpmlint puts a warning if you dont use /usr/bin/perl. http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Add_shebang -- Later, Lukas "lzap" Zapletal #katello #systemengine From hbrock at redhat.com Wed Jul 25 15:21:11 2012 From: hbrock at redhat.com (Hugh O. Brock) Date: Wed, 25 Jul 2012 11:21:11 -0400 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <500FE1C7.10801@redhat.com> References: <1049727789.5933950.1343143918982.JavaMail.root@redhat.com> <500FC2B6.9030303@redhat.com> <500FE1C7.10801@redhat.com> Message-ID: <20120725152111.GI1780@redhat.com> On Wed, Jul 25, 2012 at 08:08:39AM -0400, Bryan Kearney wrote: > On 07/25/2012 05:56 AM, Ivan Ne?as wrote: > >On 07/24/2012 05:31 PM, James Labocki wrote: > >> > >>----- Original Message ----- > >>>From: "Hugh O. Brock" > >>>To: "Ivan Ne?as" > >>>Cc: aeolus-devel at fedorahosted.org, katello-devel at redhat.com > >>>Sent: Tuesday, July 24, 2012 11:13:15 AM > >>>Subject: Re: Improving Aeolus + Katello integration > >>> > >>>On Mon, Jul 16, 2012 at 06:57:08PM +0200, Ivan Ne?as wrote: > >>>>With funzo, we're trying to figure out how the Aeolus + Katello > >>>>could > >>>>better integrate together. > >>>> > >>>>The templates in Katello are going to be replaced with component > >>>>outlines. In > >>>>discussion about Foreman integration, it was not mentioned, that > >>>>the > >>>>Compontent Outline will contain the list of packages (System > >>>>Template > >>>>like we know it today has it). This is not required by Foreman > >>>>(Foreman > >>>>solves it with Puppet), but Aeolus is able to take the list of > >>>>packages and install it into the built image, if I understand it > >>>>correctly. Was it meant to be this way, or we just skipped it when > >>>>talking about Foreman. It seems quite valuable Aeolus feature to > >>>>me. > >>>Yeah, users do want to be able to do image based provisioning, in > >>>some > >>>cases with quite complex images. In fact I was discussing with Ian > >>>Mcleod the other day the idea that Factory might need to grow the > >>>ability to invoke Puppet after it finishes running the native > >>>installer when building the image (or running scripts on a pre-build > >>>JEOS). > >>> > >>>Another option, quite seriously, would be to look at having Factory > >>>use Puppet to resolve package requirements just as Foreman > >>>does. Historically we have shied away from this approach because RPM > >>>should take care of packaging requirements... but if we want to build > >>>something that isn't RPM based, well, that won't work. Factory guys, > >>>any thoughts? > >>> > >>>>Another thing to solve is how to call back to Katello after the > >>>>instance was deployed by Aeolus (if we're not satisfied with the > >>>>current status of setting the script manually in deployable, which > >>>>I > >>>>guess we're not). It seems for now that Audrey is the only way how > >>>>to > >>>>run some scripts after the image was deployed. Will there we some > >>>>other > >>>>way for running scripts after deployment in Cloud Engine. If not, > >>>>it > >>>>seems that we will need to run Audrey and Puppet side by side. > >>>>Maybe > >>>>it's ok, just asking, if its acceptable to have two config servers > >>>>run > >>>>against the same machine? > >>I think we are close to solving an important problem that has plagued > >>IT ops. The ability to make changes to a running system (in dev, for > >>example) and then bring those changes back into the system description > >>to then promote to other environment seamlessly (QA, prod for > >>example). From my point of view we have the following technologies. > >> > >>Provisioning > >> build based (katello) - component outlines in katello > >> image based (imagefactory) - images built from component outline > >> > >>Run-time configuration > >> audrey - used for boot time config > >> foreman/puppet - after boot, used for ongoing configuration management > >> cloud-init - not sure where this fits exactly yet, but I guess > >>it might replace audrey > > I jhad assumed that we would use TDl for build time config, and > cloud-init / audrey for initial boot "Find your katello" and then > use puppet for initial build time config and ongoing drift. Granted > you could do more config via TDL but what I described would be best > practice. I had not assmed puppet at buld time would be a high > priority. I think you're right about this being the "best practice" workflow and the one we should try to solve *first*. Having said that, I have frequently heard from users who are committed to doing the opposite for whatever reason -- it doesn't seem to be an uncommon case at all. So I would like to support it at some point. If that means that the Factory should learn to do more config during the image build, then that seems like a worthwhile goal. Take care, --Hugh -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From lzap at redhat.com Wed Jul 25 15:21:09 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 Jul 2012 17:21:09 +0200 Subject: [katello-devel] katello-upgrade restarting services In-Reply-To: <20120725132258.GE18878@redhat.com> References: <500EA605.4010009@redhat.com> <1745343611.2002644.1343137701623.JavaMail.root@redhat.com> <20120725121925.GD3588@lzapx.brq.redhat.com> <20120725132258.GE18878@redhat.com> Message-ID: <20120725152109.GK3588@lzapx.brq.redhat.com> On Wed, Jul 25, 2012 at 09:22:58AM -0400, Jordan O'Mara wrote: > I think, lzap, you would be OK with this behavior > > katello-upgrade (no arguments) > ------------------------------ > Upgrade stopped! Please stop the following services before continuing: > katello > tomcat6 > postgresql > > katello-upgrade --auto-stop > ----------------------------- > The following services are being stopped for the upgrade process: > katello > tomcat6 > postgresql +1 I think its the best approach and I love it :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Jul 25 15:44:43 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 Jul 2012 17:44:43 +0200 Subject: [katello-devel] Info: rubygem-popen incompatibility In-Reply-To: <50100AD5.5010708@redhat.com> References: <20120725100910.GA3588@lzapx.brq.redhat.com> <500FF652.6060409@redhat.com> <50100AD5.5010708@redhat.com> Message-ID: <20120725154443.GL3588@lzapx.brq.redhat.com> On Wed, Jul 25, 2012 at 05:03:49PM +0200, Miroslav Suchy wrote: > On 07/25/2012 03:36 PM, Jason Rist wrote: > >Forgive my ignorance, but what is an ABI change? > > > http://en.wikipedia.org/wiki/Application_binary_interface Short answer: We (Red Hat) are making sure you can compile program X on RHEL 6.1 and run it on RHEL 6.8 without any issues. If there is any, it's a RHBZ ;-) But in this case it's probably not, because we are doing RHEL 6.3->6.2 which is I believe not supported at least. But something changed, apparently. -- Later, Lukas "lzap" Zapletal #katello #systemengine From esammons at redhat.com Wed Jul 25 15:51:04 2012 From: esammons at redhat.com (Eric Sammons) Date: Wed, 25 Jul 2012 11:51:04 -0400 (EDT) Subject: [katello-devel] Why #!/usr/bin/env ? In-Reply-To: <20120725151724.GI3588@lzapx.brq.redhat.com> Message-ID: <284447362.2868005.1343231464635.JavaMail.root@redhat.com> > > +1 > > By the way this is recommended by default in Fedora 16+: > > http://fedoraproject.org/wiki/Features/SystemPythonExecutablesUseSystemPython > > I guess I would be able to find it in packaging guidelines somewhere. > I > am pretty sure I have been fixing those at least two times for my > (few) > fedora packages. Even rpmlint warns about it I believe! > > Therefore: Do not use env, use direct path. That document makes sense for Fedora and testing where you want to test the shipped version of python; however, it is also important to note that the document contradicts itself. ''' System executables written in Python now use a shebang line that explicitly references the system version of Python. Remove the "#!/usr/bin/env python" shebang line from python executables, replacing with "#!/usr/bin/python" ''' Tells you in Fedora for testing of /usr/bin/python you should replace the #!/usr/bin/env python line in your code. _HOWEVER_ if you read the Detailed description and Benefit to Fedora it seems they are arguing for the continued use of #!/usr/bin/env python. ''' Benefit to Fedora Users will be able to parallel-install local copies of older and newer releases of Python on the system and add them to the front of their PATH without breaking these executables. (e.g. Python 2.4 for Zope, or Python 3) ''' Unless I missed something, the above statement is _only_ true if you are using #!/usr/bin/env python. As installing multiple python binaries and then prepending your $PATH, will have no impact on a python program using #!/usr/bin/python. With that being said, I'll continue using #!/usr/bin/env python. http://docs.python.org/using/unix.html#miscellaneous Section 2.4. Miscellaneous From ohadlevy at redhat.com Wed Jul 25 18:42:08 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 25 Jul 2012 21:42:08 +0300 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <20120725152111.GI1780@redhat.com> References: <1049727789.5933950.1343143918982.JavaMail.root@redhat.com> <500FC2B6.9030303@redhat.com> <500FE1C7.10801@redhat.com> <20120725152111.GI1780@redhat.com> Message-ID: <50103E00.2090900@redhat.com> On 07/25/2012 06:21 PM, Hugh O. Brock wrote: > On Wed, Jul 25, 2012 at 08:08:39AM -0400, Bryan Kearney wrote: >> On 07/25/2012 05:56 AM, Ivan Ne?as wrote: >>> On 07/24/2012 05:31 PM, James Labocki wrote: >>>> >>>> ----- Original Message ----- >>>>> From: "Hugh O. Brock" >>>>> To: "Ivan Ne?as" >>>>> Cc: aeolus-devel at fedorahosted.org, katello-devel at redhat.com >>>>> Sent: Tuesday, July 24, 2012 11:13:15 AM >>>>> Subject: Re: Improving Aeolus + Katello integration >>>>> >>>>> On Mon, Jul 16, 2012 at 06:57:08PM +0200, Ivan Ne?as wrote: >>>>>> With funzo, we're trying to figure out how the Aeolus + Katello >>>>>> could >>>>>> better integrate together. >>>>>> >>>>>> The templates in Katello are going to be replaced with component >>>>>> outlines. In >>>>>> discussion about Foreman integration, it was not mentioned, that >>>>>> the >>>>>> Compontent Outline will contain the list of packages (System >>>>>> Template >>>>>> like we know it today has it). This is not required by Foreman >>>>>> (Foreman >>>>>> solves it with Puppet), but Aeolus is able to take the list of >>>>>> packages and install it into the built image, if I understand it >>>>>> correctly. Was it meant to be this way, or we just skipped it when >>>>>> talking about Foreman. It seems quite valuable Aeolus feature to >>>>>> me. >>>>> Yeah, users do want to be able to do image based provisioning, in >>>>> some >>>>> cases with quite complex images. In fact I was discussing with Ian >>>>> Mcleod the other day the idea that Factory might need to grow the >>>>> ability to invoke Puppet after it finishes running the native >>>>> installer when building the image (or running scripts on a pre-build >>>>> JEOS). >>>>> >>>>> Another option, quite seriously, would be to look at having Factory >>>>> use Puppet to resolve package requirements just as Foreman >>>>> does. Historically we have shied away from this approach because RPM >>>>> should take care of packaging requirements... but if we want to build >>>>> something that isn't RPM based, well, that won't work. Factory guys, >>>>> any thoughts? >>>>> >>>>>> Another thing to solve is how to call back to Katello after the >>>>>> instance was deployed by Aeolus (if we're not satisfied with the >>>>>> current status of setting the script manually in deployable, which >>>>>> I >>>>>> guess we're not). It seems for now that Audrey is the only way how >>>>>> to >>>>>> run some scripts after the image was deployed. Will there we some >>>>>> other >>>>>> way for running scripts after deployment in Cloud Engine. If not, >>>>>> it >>>>>> seems that we will need to run Audrey and Puppet side by side. >>>>>> Maybe >>>>>> it's ok, just asking, if its acceptable to have two config servers >>>>>> run >>>>>> against the same machine? >>>> I think we are close to solving an important problem that has plagued >>>> IT ops. The ability to make changes to a running system (in dev, for >>>> example) and then bring those changes back into the system description >>>> to then promote to other environment seamlessly (QA, prod for >>>> example). From my point of view we have the following technologies. >>>> >>>> Provisioning >>>> build based (katello) - component outlines in katello >>>> image based (imagefactory) - images built from component outline >>>> >>>> Run-time configuration >>>> audrey - used for boot time config >>>> foreman/puppet - after boot, used for ongoing configuration management >>>> cloud-init - not sure where this fits exactly yet, but I guess >>>> it might replace audrey >> >> I jhad assumed that we would use TDl for build time config, and >> cloud-init / audrey for initial boot "Find your katello" and then >> use puppet for initial build time config and ongoing drift. Granted >> you could do more config via TDL but what I described would be best >> practice. I had not assmed puppet at buld time would be a high >> priority. > > I think you're right about this being the "best practice" workflow and > the one we should try to solve *first*. > > Having said that, I have frequently heard from users who are committed > to doing the opposite for whatever reason -- it doesn't seem to be an > uncommon case at all. So I would like to support it at some point. If > that means that the Factory should learn to do more config during the > image build, then that seems like a worthwhile goal. I'm still not clear of why not telling foreman to create an instance and pull that as an image. you would get 90% of the job done for free and you would only need to take care for cleaning up the instance from host specific stuff. Ohad > > Take care, > --Hugh > From calfonso at redhat.com Wed Jul 25 18:59:07 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Wed, 25 Jul 2012 14:59:07 -0400 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <50103E00.2090900@redhat.com> References: <1049727789.5933950.1343143918982.JavaMail.root@redhat.com> <500FC2B6.9030303@redhat.com> <500FE1C7.10801@redhat.com> <20120725152111.GI1780@redhat.com> <50103E00.2090900@redhat.com> Message-ID: <20120725185906.GA29979@dhcp-230-220.rdu.redhat.com> On 25/07/12 21:42 +0300, Ohad Levy wrote: -- snip -- > >I'm still not clear of why not telling foreman to create an instance >and pull that as an image. you would get 90% of the job done for free >and you would only need to take care for cleaning up the instance >from host specific stuff. > >Ohad Just want to clarify what you're suggesting. We have an application and set of dependencies specifically built for image creation, launching, and management (the aeolus suite). The images are built, launched in multiple cloud providers via deltacloud api. The images are also configured via audrey and config server. Users are either managed in conductor, or authenticated via externa ldap and a VM quota is allocated to a user. I may have read into your comment too far, but are you suggesting we just do all that with foreman? Are you suggesting we throw out the features that are currently in aeolus and just go with what foreman can do? Are you saying we should develop those features into foreman? Or are you saying something entirely different that I missed? -- Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From ohadlevy at redhat.com Wed Jul 25 19:29:00 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 25 Jul 2012 22:29:00 +0300 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <20120725185906.GA29979@dhcp-230-220.rdu.redhat.com> References: <1049727789.5933950.1343143918982.JavaMail.root@redhat.com> <500FC2B6.9030303@redhat.com> <500FE1C7.10801@redhat.com> <20120725152111.GI1780@redhat.com> <50103E00.2090900@redhat.com> <20120725185906.GA29979@dhcp-230-220.rdu.redhat.com> Message-ID: <501048FC.2080607@redhat.com> On 07/25/2012 09:59 PM, Chris Alfonso wrote: > Just want to clarify what you're suggesting. We have an application and > set > of dependencies specifically built for image creation, launching, and > management (the aeolus suite). The images are built, launched in multiple > cloud providers via deltacloud api. The images are also configured via > audrey and config server. Users are either managed in conductor, or > authenticated via externa ldap and a VM quota is allocated to a user. > > I may have read into your comment too far, but are you suggesting we > just do > all that with foreman? Are you suggesting we throw out the features that > are currently in aeolus and just go with what foreman can do? Are you > saying > we should develop those features into foreman? Or are you saying something > entirely different that I missed? I was talking about Image creations (the part that you need to pass TDL in order to build a new image based on oz). I did not at any point in time said we need to throw out aeolus, nor did i try to imply it between the lines. Ohad From hbrock at redhat.com Wed Jul 25 19:44:14 2012 From: hbrock at redhat.com (Hugh O. Brock) Date: Wed, 25 Jul 2012 15:44:14 -0400 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <501048FC.2080607@redhat.com> References: <1049727789.5933950.1343143918982.JavaMail.root@redhat.com> <500FC2B6.9030303@redhat.com> <500FE1C7.10801@redhat.com> <20120725152111.GI1780@redhat.com> <50103E00.2090900@redhat.com> <20120725185906.GA29979@dhcp-230-220.rdu.redhat.com> <501048FC.2080607@redhat.com> Message-ID: <20120725194414.GL1780@redhat.com> On Wed, Jul 25, 2012 at 10:29:00PM +0300, Ohad Levy wrote: > On 07/25/2012 09:59 PM, Chris Alfonso wrote: > >Just want to clarify what you're suggesting. We have an application and > >set > >of dependencies specifically built for image creation, launching, and > >management (the aeolus suite). The images are built, launched in multiple > >cloud providers via deltacloud api. The images are also configured via > >audrey and config server. Users are either managed in conductor, or > >authenticated via externa ldap and a VM quota is allocated to a user. > > > >I may have read into your comment too far, but are you suggesting we > >just do > >all that with foreman? Are you suggesting we throw out the features that > >are currently in aeolus and just go with what foreman can do? Are you > >saying > >we should develop those features into foreman? Or are you saying something > >entirely different that I missed? > > I was talking about Image creations (the part that you need to pass > TDL in order to build a new image based on oz). > > I did not at any point in time said we need to throw out aeolus, nor > did i try to imply it between the lines. So to do image creation in Foreman, we would have to pull most of Factory into the Foreman app, would we not? Or am I missing something? There's a fair amount of logic in Factory that the Conductor app depends on. --Hugh -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From calfonso at redhat.com Wed Jul 25 20:39:27 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Wed, 25 Jul 2012 16:39:27 -0400 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <501048FC.2080607@redhat.com> References: <1049727789.5933950.1343143918982.JavaMail.root@redhat.com> <500FC2B6.9030303@redhat.com> <500FE1C7.10801@redhat.com> <20120725152111.GI1780@redhat.com> <50103E00.2090900@redhat.com> <20120725185906.GA29979@dhcp-230-220.rdu.redhat.com> <501048FC.2080607@redhat.com> Message-ID: <20120725203927.GA30010@dhcp-230-220.rdu.redhat.com> On 25/07/12 22:29 +0300, Ohad Levy wrote: >On 07/25/2012 09:59 PM, Chris Alfonso wrote: >>Just want to clarify what you're suggesting. We have an application and >>set >>of dependencies specifically built for image creation, launching, and >>management (the aeolus suite). The images are built, launched in multiple >>cloud providers via deltacloud api. The images are also configured via >>audrey and config server. Users are either managed in conductor, or >>authenticated via externa ldap and a VM quota is allocated to a user. >> >>I may have read into your comment too far, but are you suggesting we >>just do >>all that with foreman? Are you suggesting we throw out the features that >>are currently in aeolus and just go with what foreman can do? Are you >>saying >>we should develop those features into foreman? Or are you saying something >>entirely different that I missed? > >I was talking about Image creations (the part that you need to pass >TDL in order to build a new image based on oz). > >I did not at any point in time said we need to throw out aeolus, nor >did i try to imply it between the lines. > >Ohad Thanks for the clarification Ohad, I wanted to be sure I was wrong. When you said create the instance, I thought you meant the instantiation of images that were already built, much like conductor does. -- Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From ehelms at redhat.com Thu Jul 26 02:29:43 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 25 Jul 2012 22:29:43 -0400 (EDT) Subject: [katello-devel] Katello Community Update Planning In-Reply-To: <93076231.9764583.1343267446675.JavaMail.root@redhat.com> Message-ID: <2036405451.9804514.1343269783250.JavaMail.root@redhat.com> Howdy Ya'll, In lieu of recent discussions, and as we approach our first community release, I decided to do some research and reading and put together the start of a plan for updating our Community presence. The major areas of focus are: Updated Community Site wtih a focus on Community elements Addition of a Project Blog Social and Video Media Presence Documentation Updates Since this is about the community, and we are the community, your input is needed to ensure I have not fallen off the wagon and to fill the gaps! The whole of the document is a bit large for email, and can thus be found on the following public Etherpad: http://pad-katello.rhcloud.com/p/community-planning Discussion is encouraged inline within the Etherpad in a manner that is easy to decipher or within the context of this email chain. As new ideas and information accumulate, the Etherpad will be updated appropriately. Lastly, if anyone would like to take ownership of any particular area, speak up! Thanks, Eric From tstrachota at redhat.com Thu Jul 26 07:31:18 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Thu, 26 Jul 2012 09:31:18 +0200 Subject: [katello-devel] Foreman skin design spike In-Reply-To: <50100BFD.8090209@redhat.com> References: <500FF75D.2030605@redhat.com> <1330291060.2513004.1343226562517.JavaMail.root@redhat.com> <20120725145229.GG1780@redhat.com> <50100BFD.8090209@redhat.com> Message-ID: <5010F246.8080301@redhat.com> On 07/25/2012 05:08 PM, Brad Buckingham wrote: > On 07/25/2012 10:52 AM, Hugh O. Brock wrote: >> On Wed, Jul 25, 2012 at 10:29:22AM -0400, Malini Rao wrote: >>> >>> ----- Original Message ----- >>> From: "Jason Rist" >>> To: katello-devel at redhat.com >>> Sent: Wednesday, July 25, 2012 9:40:45 AM >>> Subject: Re: [katello-devel] Foreman skin design spike >>> >>> On 07/24/2012 08:29 AM, Tomas Strachota wrote: >>>> Team, >>>> I've finished a design spike to make Foreman look like Katello. So far >>>> it seems that we can make most of the skinning without bigger problems >>>> just by creating new styles for the bootstrap css& js library. >>>> >>>> You can checkout summary of the investigation and some screenshots on >>>> our wiki >>>> https://fedorahosted.org/katello/wiki/ForemanSkinDesign >>> Is there an instance that we could see these changes in? The >>> screenshots are useful and the initial changes are looking good but I >>> would like to see a bit more and provide you some feedback from the >>> UX consistency perspective. For instance, in the Environments list >>> screen, if we cannot do a 2-pane, then the location of the 'New >>> Environment' button/ link seems a little odd. >>>> Please note that not everything has been styled. Eg. most of the >>>> buttons >>>> have still it's original look. I didn't want to loose much time with it >>>> since there's a fair chance that we will just throw it away. >>> So what is the plan? Are we going to be hopping on to Foreman that >>> kinda looks like Katello at certain points in the workflow and then >>> jump back into Katello? Is this a short term strategy before we have >>> a more seamless integration? Either way, I think we should have some >>> UX discussions around how these switches happen so that the overall >>> UX is not impacted severely. The fact that Foreman is made to look >>> more like Katello increases the expectation that the overall >>> navigation and UI paradigms will be the same. This is why, I would >>> like to see a demo if possible on a workflow that involves this >>> switch so we can evaluate the usability impact. >> I love the idea of having a Foreman UI skin that makes it look like >> Cloudforms, that is good stuff. >> >> Having said that, I'm fairly certain that we're going to want to be >> able to build workflows in Katello that touch Foreman objects and we >> probably want not to force the user to a *third* different webapp, no >> matter how similar we make it look. This means there is going to have >> to be some work done in Katello UI to represent Foreman objects, one >> way or another... >> >> --H > [brad] This effort is just one of the design spikes that was created. > One of the intents was to understand the effort and feasibility of > applying the Katello L&F to Foreman. It does not imply a decision to > introduce a third webapp to the overall solution. That said, it is good > to hear folks feedback as it reinforces some of the discussions the team > has been having. > > Another design spike was to perform a similar exercise where the page is > exposed from Katello UI but using the Foreman APIs. This approach would > be more consistent with how Katello interfaces with Candlepin and Pulp. > As Brad has said, this is just one piece of the puzzle that should give us some background for the decision. I don't have any public foreman instance with this skin but I'll demonstrate that live it on Tuesday. T. >>>> Questions and ideas are welcome. >>>> >>>> Tomas >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> Looks very nice. I think some Foreman pages might benefit from Tupane. >>> >>> So what's the next step? Is it worth doing additional work for upstream >>> Foreman to look like another Red Hat CloudForms upstream related >>> product? >>> >>> -J >>> >>> -- >>> Jason E. Rist >>> Senior Software Engineer >>> Systems Management and Cloud Enablement >>> Red Hat, Inc. >>> +1.919.754.4048 >>> Freenode: jrist >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From inecas at redhat.com Thu Jul 26 07:46:31 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 26 Jul 2012 09:46:31 +0200 Subject: [katello-devel] Foreman skin design spike In-Reply-To: <20120725145229.GG1780@redhat.com> References: <500FF75D.2030605@redhat.com> <1330291060.2513004.1343226562517.JavaMail.root@redhat.com> <20120725145229.GG1780@redhat.com> Message-ID: <5010F5D7.9000307@redhat.com> On 07/25/2012 04:52 PM, Hugh O. Brock wrote: > On Wed, Jul 25, 2012 at 10:29:22AM -0400, Malini Rao wrote: >> >> ----- Original Message ----- >> From: "Jason Rist" >> To: katello-devel at redhat.com >> Sent: Wednesday, July 25, 2012 9:40:45 AM >> Subject: Re: [katello-devel] Foreman skin design spike >> >> On 07/24/2012 08:29 AM, Tomas Strachota wrote: >>> Team, >>> I've finished a design spike to make Foreman look like Katello. So far >>> it seems that we can make most of the skinning without bigger problems >>> just by creating new styles for the bootstrap css & js library. >>> >>> You can checkout summary of the investigation and some screenshots on >>> our wiki >>> https://fedorahosted.org/katello/wiki/ForemanSkinDesign >> Is there an instance that we could see these changes in? The screenshots are useful and the initial changes are looking good but I would like to see a bit more and provide you some feedback from the UX consistency perspective. For instance, in the Environments list screen, if we cannot do a 2-pane, then the location of the 'New Environment' button/ link seems a little odd. >>> Please note that not everything has been styled. Eg. most of the buttons >>> have still it's original look. I didn't want to loose much time with it >>> since there's a fair chance that we will just throw it away. >> So what is the plan? Are we going to be hopping on to Foreman that kinda looks like Katello at certain points in the workflow and then jump back into Katello? Is this a short term strategy before we have a more seamless integration? Either way, I think we should have some UX discussions around how these switches happen so that the overall UX is not impacted severely. The fact that Foreman is made to look more like Katello increases the expectation that the overall navigation and UI paradigms will be the same. This is why, I would like to see a demo if possible on a workflow that involves this switch so we can evaluate the usability impact. > I love the idea of having a Foreman UI skin that makes it look like > Cloudforms, that is good stuff. > > Having said that, I'm fairly certain that we're going to want to be > able to build workflows in Katello that touch Foreman objects and we > probably want not to force the user to a *third* different webapp, no > matter how similar we make it look. This means there is going to have > to be some work done in Katello UI to represent Foreman objects, one > way or another... Certainly not force to use it, but enable to use it, and give a feeling that it's a part of the whole solution. I agree that the basic workflow should be supported in Katello without needing to log into the Foreman. OTOH, I believe that there are some advanced features in Foreman (like reporting, custom templates, maybe VNC console etc.) that probably won't be available from Katello UI, but still it would be nice to make it available for the users (without fear that they might do something in Foreman that would break the integration). From Foreman community point of view, I think it would be beneficial as well to let them use Katello and Foreman together, without forcing them to leave the Foreman UI completely. So if it would be possible for basic use-cases use only Katello and for advanced ones let users safely go into Foreman UI, it would be great. -- Ivan > > --H > >>> Questions and ideas are welcome. >>> >>> Tomas >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> Looks very nice. I think some Foreman pages might benefit from Tupane. >> >> So what's the next step? Is it worth doing additional work for upstream >> Foreman to look like another Red Hat CloudForms upstream related product? >> >> -J >> >> -- >> Jason E. Rist >> Senior Software Engineer >> Systems Management and Cloud Enablement >> Red Hat, Inc. >> +1.919.754.4048 >> Freenode: jrist >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From lzap at redhat.com Thu Jul 26 08:17:21 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 26 Jul 2012 10:17:21 +0200 Subject: [katello-devel] Katello Community Update Planning In-Reply-To: <2036405451.9804514.1343269783250.JavaMail.root@redhat.com> References: <93076231.9764583.1343267446675.JavaMail.root@redhat.com> <2036405451.9804514.1343269783250.JavaMail.root@redhat.com> Message-ID: <20120726081721.GA6023@lzapx.brq.redhat.com> > Discussion is encouraged inline within the Etherpad in a manner that is easy to decipher or within the context of this email chain. As new ideas and information accumulate, the Etherpad will be updated appropriately. Lastly, if anyone would like to take ownership of any particular area, speak up! > Thanks Eric, I have added few points on the etherpad, but it seems you covered everything. I just want to do small planning follow up. Mirek has been working hard to get us koji builds, he is basically done and we are testing it. We have few issues we need to solve and hopefully this week we can switch over to new repositories. After that, we are ready to go with our first community release. With koji the process will be pretty straightforward. Meantime, please think of features or bugs that should go into community release. If you have some big feature/change and it is possible to hold pull request a bit, do it. We are very close. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Thu Jul 26 08:20:39 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 26 Jul 2012 10:20:39 +0200 Subject: [katello-devel] Foreman skin design spike In-Reply-To: <20120725145229.GG1780@redhat.com> References: <500FF75D.2030605@redhat.com> <1330291060.2513004.1343226562517.JavaMail.root@redhat.com> <20120725145229.GG1780@redhat.com> Message-ID: <20120726082039.GB6023@lzapx.brq.redhat.com> On Wed, Jul 25, 2012 at 10:52:30AM -0400, Hugh Brock wrote: > Having said that, I'm fairly certain that we're going to want to be > able to build workflows in Katello that touch Foreman objects and we > probably want not to force the user to a *third* different webapp, no > matter how similar we make it look. This means there is going to have > to be some work done in Katello UI to represent Foreman objects, one > way or another... > I agree with that, but the reason why we actually think about an option of having 3rd app avaiable to the user is to avoid re-writing many screens. So by not forcing I understand to do everything what is possible from Katello. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Thu Jul 26 09:08:57 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 26 Jul 2012 11:08:57 +0200 Subject: [katello-devel] Katello-configure changes finished Message-ID: <20120726090857.GC6023@lzapx.brq.redhat.com> Hello, I finished with testing katello-configure on Fedoras. I have implemented new script called service-wait which corrects some bad behavior of tomcat and postgresql services. Now it also works with systemd. To test it, you need to build katello-* packages (src/ and puppet/ spec files) and install it on a clean machine. Then you can test various options, re-running k-c, changing options and resetting databases. Please comment: https://github.com/Katello/katello/pull/345 -- Later, Lukas "lzap" Zapletal #katello #systemengine From ohadlevy at redhat.com Thu Jul 26 11:02:14 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Thu, 26 Jul 2012 14:02:14 +0300 Subject: [katello-devel] Foreman skin design spike In-Reply-To: <20120726082039.GB6023@lzapx.brq.redhat.com> References: <500FF75D.2030605@redhat.com> <1330291060.2513004.1343226562517.JavaMail.root@redhat.com> <20120725145229.GG1780@redhat.com> <20120726082039.GB6023@lzapx.brq.redhat.com> Message-ID: <501123B6.8050003@redhat.com> On 07/26/2012 11:20 AM, Lukas Zapletal wrote: > On Wed, Jul 25, 2012 at 10:52:30AM -0400, Hugh Brock wrote: >> Having said that, I'm fairly certain that we're going to want to be >> able to build workflows in Katello that touch Foreman objects and we >> probably want not to force the user to a *third* different webapp, no >> matter how similar we make it look. This means there is going to have >> to be some work done in Katello UI to represent Foreman objects, one >> way or another... >> > > I agree with that, but the reason why we actually think about an option > of having 3rd app avaiable to the user is to avoid re-writing many > screens. So by not forcing I understand to do everything what is > possible from Katello. > There is another question that needs to be answered, and that if the 'admin user' which logs into Katello is the same 'admin / operator / self service(?) user' that logs into foreman. if they are not the same users, then it might not be that huge of a UI issue. Ohad From msuchy at redhat.com Thu Jul 26 12:15:46 2012 From: msuchy at redhat.com (=?ISO-8859-2?Q?Miroslav_Such=FD?=) Date: Thu, 26 Jul 2012 14:15:46 +0200 Subject: [katello-devel] New location of yum repo Message-ID: <501134F2.9070905@redhat.com> Hi Katello users and developers, I'm pleased to announce new location of our yum repos: http://fedorapeople.org/groups/katello/releases/ Install wiki: https://fedorahosted.org/katello/wiki/Install is updated to point to this new location. Those packages are build using our new Koji instance. Unfortunately it does not have public interface, but we are working to make this Koji public. Those repositories even contains Katello for Fedora17, but it is not working and it is intended only for developers for testing. Right now there is mainly repository "nightly" which is - contradictory to its name - updated 4 times per day. If you are developer and your contribution is merged, just run: tito tag && git push && git push --tags and within several hours your new package will land in nightly repo. This step will be hopefully soon followed by first community release of Katello. Enjoy and stay tuned. -- Miroslav Suchy Red Hat Systems Management Engineering From lzap+pub at redhat.com Thu Jul 26 12:28:39 2012 From: lzap+pub at redhat.com (Lukas Zapletal) Date: Thu, 26 Jul 2012 14:28:39 +0200 Subject: [katello-devel] New location of yum repo In-Reply-To: <501134F2.9070905@redhat.com> References: <501134F2.9070905@redhat.com> Message-ID: <20120726122839.GE6023@lzapx.brq.redhat.com> This is good news. We are now able to deliver fixes much more efficiently in the nightly build, also releasing process will be more smooth. We have been also working on handling upgrades, once one patch is accepted, it will be more easier to stay on nightly repo and upgrade every day. I will post an update soon. LZ On Thu, Jul 26, 2012 at 02:15:46PM +0200, Miroslav Suchy wrote: > Hi Katello users and developers, > I'm pleased to announce new location of our yum repos: > http://fedorapeople.org/groups/katello/releases/ > > Install wiki: > https://fedorahosted.org/katello/wiki/Install > is updated to point to this new location. > > Those packages are build using our new Koji instance. Unfortunately > it does not have public interface, but we are working to make this > Koji public. > > Those repositories even contains Katello for Fedora17, but it is not > working and it is intended only for developers for testing. > > Right now there is mainly repository "nightly" which is - > contradictory to its name - updated 4 times per day. If you are > developer and your contribution is merged, just run: > tito tag && git push && git push --tags > and within several hours your new package will land in nightly repo. > > This step will be hopefully soon followed by first community release > of Katello. > > Enjoy and stay tuned. > > -- > Miroslav Suchy > Red Hat Systems Management Engineering > _______________________________________________ > katello mailing list > katello at lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/katello -- Later, Lukas "lzap" Zapletal #katello #systemengine From jsherril at redhat.com Thu Jul 26 13:22:59 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 26 Jul 2012 09:22:59 -0400 Subject: [katello-devel] Foreman skin design spike In-Reply-To: <5010F5D7.9000307@redhat.com> References: <500FF75D.2030605@redhat.com> <1330291060.2513004.1343226562517.JavaMail.root@redhat.com> <20120725145229.GG1780@redhat.com> <5010F5D7.9000307@redhat.com> Message-ID: <501144B3.9060301@redhat.com> On 07/26/2012 03:46 AM, Ivan Ne?as wrote: > On 07/25/2012 04:52 PM, Hugh O. Brock wrote: >> On Wed, Jul 25, 2012 at 10:29:22AM -0400, Malini Rao wrote: >>> >>> ----- Original Message ----- >>> From: "Jason Rist" >>> To: katello-devel at redhat.com >>> Sent: Wednesday, July 25, 2012 9:40:45 AM >>> Subject: Re: [katello-devel] Foreman skin design spike >>> >>> On 07/24/2012 08:29 AM, Tomas Strachota wrote: >>>> Team, >>>> I've finished a design spike to make Foreman look like Katello. So far >>>> it seems that we can make most of the skinning without bigger problems >>>> just by creating new styles for the bootstrap css & js library. >>>> >>>> You can checkout summary of the investigation and some screenshots on >>>> our wiki >>>> https://fedorahosted.org/katello/wiki/ForemanSkinDesign >>> Is there an instance that we could see these changes in? The >>> screenshots are useful and the initial changes are looking good but >>> I would like to see a bit more and provide you some feedback from >>> the UX consistency perspective. For instance, in the Environments >>> list screen, if we cannot do a 2-pane, then the location of the 'New >>> Environment' button/ link seems a little odd. >>>> Please note that not everything has been styled. Eg. most of the >>>> buttons >>>> have still it's original look. I didn't want to loose much time >>>> with it >>>> since there's a fair chance that we will just throw it away. >>> So what is the plan? Are we going to be hopping on to Foreman that >>> kinda looks like Katello at certain points in the workflow and then >>> jump back into Katello? Is this a short term strategy before we have >>> a more seamless integration? Either way, I think we should have some >>> UX discussions around how these switches happen so that the overall >>> UX is not impacted severely. The fact that Foreman is made to look >>> more like Katello increases the expectation that the overall >>> navigation and UI paradigms will be the same. This is why, I would >>> like to see a demo if possible on a workflow that involves this >>> switch so we can evaluate the usability impact. >> I love the idea of having a Foreman UI skin that makes it look like >> Cloudforms, that is good stuff. >> >> Having said that, I'm fairly certain that we're going to want to be >> able to build workflows in Katello that touch Foreman objects and we >> probably want not to force the user to a *third* different webapp, no >> matter how similar we make it look. This means there is going to have >> to be some work done in Katello UI to represent Foreman objects, one >> way or another... > Certainly not force to use it, but enable to use it, and give a > feeling that it's a part of the whole solution. I agree that the basic > workflow should be supported in Katello without needing to log into > the Foreman. OTOH, I believe that there are some advanced features in > Foreman (like reporting, custom templates, maybe VNC console etc.) > that probably won't be available from Katello UI, but still it would > be nice to make it available for the users (without fear that they > might do something in Foreman that would break the integration). From > Foreman community point of view, I think it would be beneficial as > well to let them use Katello and Foreman together, without forcing > them to leave the Foreman UI completely. > > So if it would be possible for basic use-cases use only Katello and > for advanced ones let users safely go into Foreman UI, it would be great. > > -- Ivan While this is a nice goal to have I think someone higher up needs to decide whether this is actually something that is a requirement or not and we need to spec out what all it would take. This is not a simple undertaking. As a minimum we'd need to add orchestration to foreman for all shared entities (in addition to doing the same for katello), modify katello to allow foreman to orchestrate to it, a unified permissions model, and the same permission enforcement in katello and foreman. These are not quick things to do :) It also increases the QA requirements greatly. As there would now be 4 ways of creating and modifying something like an environment (Katello UI/API & Foreman UI/API). We would definitely want to get QA's input into the matter. I like the idea of users being able to do more advanced things in foreman, there's just a LOT of get there. -Justin >> >> --H >> >>>> Questions and ideas are welcome. >>>> >>>> Tomas >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> Looks very nice. I think some Foreman pages might benefit from Tupane. >>> >>> So what's the next step? Is it worth doing additional work for upstream >>> Foreman to look like another Red Hat CloudForms upstream related >>> product? >>> >>> -J >>> >>> -- >>> Jason E. Rist >>> Senior Software Engineer >>> Systems Management and Cloud Enablement >>> Red Hat, Inc. >>> +1.919.754.4048 >>> Freenode: jrist >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel > > From mrao at redhat.com Thu Jul 26 14:27:58 2012 From: mrao at redhat.com (Malini Rao) Date: Thu, 26 Jul 2012 10:27:58 -0400 (EDT) Subject: [katello-devel] Foreman skin design spike In-Reply-To: <501123B6.8050003@redhat.com> Message-ID: <1622667807.3633733.1343312878704.JavaMail.root@redhat.com> ----- Original Message ----- From: "Ohad Levy" To: katello-devel at redhat.com Sent: Thursday, July 26, 2012 7:02:14 AM Subject: Re: [katello-devel] Foreman skin design spike On 07/26/2012 11:20 AM, Lukas Zapletal wrote: > On Wed, Jul 25, 2012 at 10:52:30AM -0400, Hugh Brock wrote: >> Having said that, I'm fairly certain that we're going to want to be >> able to build workflows in Katello that touch Foreman objects and we >> probably want not to force the user to a *third* different webapp, no >> matter how similar we make it look. This means there is going to have >> to be some work done in Katello UI to represent Foreman objects, one >> way or another... >> > > I agree with that, but the reason why we actually think about an option > of having 3rd app avaiable to the user is to avoid re-writing many > screens. So by not forcing I understand to do everything what is > possible from Katello. > There is another question that needs to be answered, and that if the 'admin user' which logs into Katello is the same 'admin / operator / self service(?) user' that logs into foreman. if they are not the same users, then it might not be that huge of a UI issue. +1. Are there any user stories on Rally around the workflows that may involve moving from katello to Foreman or viceversa that we can look at? -Malini Ohad _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From mrao at redhat.com Thu Jul 26 14:31:40 2012 From: mrao at redhat.com (Malini Rao) Date: Thu, 26 Jul 2012 10:31:40 -0400 (EDT) Subject: [katello-devel] Foreman skin design spike In-Reply-To: <5010F246.8080301@redhat.com> Message-ID: <1571709067.3635848.1343313100935.JavaMail.root@redhat.com> ----- Original Message ----- From: "Tomas Strachota" To: katello-devel at redhat.com Sent: Thursday, July 26, 2012 3:31:18 AM Subject: Re: [katello-devel] Foreman skin design spike On 07/25/2012 05:08 PM, Brad Buckingham wrote: > On 07/25/2012 10:52 AM, Hugh O. Brock wrote: >> On Wed, Jul 25, 2012 at 10:29:22AM -0400, Malini Rao wrote: >>> >>> ----- Original Message ----- >>> From: "Jason Rist" >>> To: katello-devel at redhat.com >>> Sent: Wednesday, July 25, 2012 9:40:45 AM >>> Subject: Re: [katello-devel] Foreman skin design spike >>> >>> On 07/24/2012 08:29 AM, Tomas Strachota wrote: >>>> Team, >>>> I've finished a design spike to make Foreman look like Katello. So far >>>> it seems that we can make most of the skinning without bigger problems >>>> just by creating new styles for the bootstrap css& js library. >>>> >>>> You can checkout summary of the investigation and some screenshots on >>>> our wiki >>>> https://fedorahosted.org/katello/wiki/ForemanSkinDesign >>> Is there an instance that we could see these changes in? The >>> screenshots are useful and the initial changes are looking good but I >>> would like to see a bit more and provide you some feedback from the >>> UX consistency perspective. For instance, in the Environments list >>> screen, if we cannot do a 2-pane, then the location of the 'New >>> Environment' button/ link seems a little odd. >>>> Please note that not everything has been styled. Eg. most of the >>>> buttons >>>> have still it's original look. I didn't want to loose much time with it >>>> since there's a fair chance that we will just throw it away. >>> So what is the plan? Are we going to be hopping on to Foreman that >>> kinda looks like Katello at certain points in the workflow and then >>> jump back into Katello? Is this a short term strategy before we have >>> a more seamless integration? Either way, I think we should have some >>> UX discussions around how these switches happen so that the overall >>> UX is not impacted severely. The fact that Foreman is made to look >>> more like Katello increases the expectation that the overall >>> navigation and UI paradigms will be the same. This is why, I would >>> like to see a demo if possible on a workflow that involves this >>> switch so we can evaluate the usability impact. >> I love the idea of having a Foreman UI skin that makes it look like >> Cloudforms, that is good stuff. >> >> Having said that, I'm fairly certain that we're going to want to be >> able to build workflows in Katello that touch Foreman objects and we >> probably want not to force the user to a *third* different webapp, no >> matter how similar we make it look. This means there is going to have >> to be some work done in Katello UI to represent Foreman objects, one >> way or another... >> >> --H > [brad] This effort is just one of the design spikes that was created. > One of the intents was to understand the effort and feasibility of > applying the Katello L&F to Foreman. It does not imply a decision to > introduce a third webapp to the overall solution. That said, it is good > to hear folks feedback as it reinforces some of the discussions the team > has been having. > > Another design spike was to perform a similar exercise where the page is > exposed from Katello UI but using the Foreman APIs. This approach would > be more consistent with how Katello interfaces with Candlepin and Pulp. > As Brad has said, this is just one piece of the puzzle that should give us some background for the decision. I don't have any public foreman instance with this skin but I'll demonstrate that live it on Tuesday. [ Malini] --> When is this demo? Can we attend? I will actually be in Raleigh then to observe the CloudForms training session. So, let me know where you are meeting and I'll see if I can sneak out for a little bit. T. >>>> Questions and ideas are welcome. >>>> >>>> Tomas >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> Looks very nice. I think some Foreman pages might benefit from Tupane. >>> >>> So what's the next step? Is it worth doing additional work for upstream >>> Foreman to look like another Red Hat CloudForms upstream related >>> product? >>> >>> -J >>> >>> -- >>> Jason E. Rist >>> Senior Software Engineer >>> Systems Management and Cloud Enablement >>> Red Hat, Inc. >>> +1.919.754.4048 >>> Freenode: jrist >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From imcleod at redhat.com Thu Jul 26 18:15:30 2012 From: imcleod at redhat.com (Ian McLeod) Date: Thu, 26 Jul 2012 13:15:30 -0500 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <20120724151315.GA1780@redhat.com> References: <500440E6.5060707@redhat.com> <500447E4.1030509@redhat.com> <20120724151315.GA1780@redhat.com> Message-ID: <1343326530.3763.23.camel@localhost.localdomain> On Tue, 2012-07-24 at 11:13 -0400, Hugh O. Brock wrote: > On Mon, Jul 16, 2012 at 06:57:08PM +0200, Ivan Ne?as wrote: > > > > With funzo, we're trying to figure out how the Aeolus + Katello could > > better integrate together. > > > > The templates in Katello are going to be replaced with component outlines. In > > discussion about Foreman integration, it was not mentioned, that the > > Compontent Outline will contain the list of packages (System Template > > like we know it today has it). This is not required by Foreman (Foreman > > solves it with Puppet), but Aeolus is able to take the list of > > packages and install it into the built image, if I understand it > > correctly. Was it meant to be this way, or we just skipped it when > > talking about Foreman. It seems quite valuable Aeolus feature to me. > > Yeah, users do want to be able to do image based provisioning, in some > cases with quite complex images. In fact I was discussing with Ian > Mcleod the other day the idea that Factory might need to grow the > ability to invoke Puppet after it finishes running the native > installer when building the image (or running scripts on a pre-build > JEOS). > > Another option, quite seriously, would be to look at having Factory > use Puppet to resolve package requirements just as Foreman > does. Historically we have shied away from this approach because RPM > should take care of packaging requirements... but if we want to build > something that isn't RPM based, well, that won't work. Factory guys, > any thoughts? Adding puppet to the list of Factory customization steps is entirely possible. Issues that come to mind: * The details of what is actually in the image will now be spread between the TDL itself and the configuration on the puppet server. (And perhaps this is a good thing for some people.) * For snapshot-style builds, we need to ensure that the remote JEOS instance (on, for example, EC2) can communicate with the puppet server. * At least some of the puppet rules and use cases I have seen involve actions that are based on the unique identity of the host being modified or involve building out that identity by doing things like bootstrapping into a kerberos environment, establishing SSH host keys, etc. Obviously, these kinds of things cannot happen at image creation time. (Or, in the best case, they need to be repeated at instance creation time.) > > Another thing to solve is how to call back to Katello after the > > instance was deployed by Aeolus (if we're not satisfied with the > > current status of setting the script manually in deployable, which I > > guess we're not). It seems for now that Audrey is the only way how to > > run some scripts after the image was deployed. Will there we some other > > way for running scripts after deployment in Cloud Engine. If not, it > > seems that we will need to run Audrey and Puppet side by side. Maybe > > it's ok, just asking, if its acceptable to have two config servers run > > against the same machine? > > There's some interesting work going on with cloud-init that may > eliminate the Audrey requirement. Joe Vlcek is driving that, we might > check with him. > > --Hugh > > > Ohad: > > > > How does Foreman solve the EC2 deployment against Foreman? > > > > -- > > Ivan > > > > > > > > > -- Ian McLeod - Red Hat office: 312.660.3539 mobile: 312.899.6736 rh internal: (81) 33539 From vvaldez at redhat.com Fri Jul 27 00:07:22 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Thu, 26 Jul 2012 19:07:22 -0500 Subject: [katello-devel] disconnected katello sync Message-ID: beav was kind enough to get the hard work done on creating pulp repos from a manifest with katello-disconnected-configure https://github.com/beav/katello-disconnected-scripts I tested this out on a few different systems, added some options to restrict what arch/channels, and added katello-disconnected-sync to do the syncing and exporting. Time on a sync of a full os + two additional channels (~9000 packages) was roughly 20 minutes, instead of a few hours. This will be very helpful to people implementing this and not having to sync to the CDN every time (or for fully disconnected environments). Moving back to the CDN after an import is just as fast, seems to be verifying against the CDN. Example use: # python katello-disconnected-configure -m manifest.zip -s scripts -o /var/katello-content/ -r 6.2,6Server -a x86_64 -c cf-tools,supplentary # python katello-disconnected-sync --sync -r scripts/repos.list --export-dir=/var/katello-content/ Regards, Vinny Valdez, RHCA, RHCSS, RHCVA (110-119-187) Principal Architect Global Solutions & Strategy Office -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmccune at redhat.com Fri Jul 27 02:06:08 2012 From: mmccune at redhat.com (Mike McCune) Date: Thu, 26 Jul 2012 19:06:08 -0700 Subject: [katello-devel] disconnected katello sync In-Reply-To: References: Message-ID: <5011F790.5050008@redhat.com> On 07/26/2012 05:07 PM, Vinny Valdez wrote: > beav was kind enough to get the hard work done on creating pulp repos > from a manifest with katello-disconnected-configure > https://github.com/beav/katello-disconnected-scripts > > I tested this out on a few different systems, added some options to > restrict what arch/channels, and added katello-disconnected-sync to do > the syncing and exporting. Time on a sync of a full os + two additional > channels (~9000 packages) was roughly 20 minutes, instead of a few > hours. This will be very helpful to people implementing this and not > having to sync to the CDN every time (or for fully disconnected > environments). Moving back to the CDN after an import is just as fast, > seems to be verifying against the CDN. > > Example use: > > # python katello-disconnected-configure -m manifest.zip -s scripts -o > /var/katello-content/ -r 6.2,6Server -a x86_64 -c cf-tools,supplentary > > |# python katello-disconnected-sync --sync -r scripts/repos.list > --export-dir=/var/katello-content/| > > Regards, > > Vinny Valdez, RHCA, RHCSS, RHCVA (110-119-187) > Principal Architect > Global Solutions & Strategy Office > awesome work! -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From inecas at redhat.com Fri Jul 27 05:48:18 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Fri, 27 Jul 2012 07:48:18 +0200 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <1343326530.3763.23.camel@localhost.localdomain> References: <500440E6.5060707@redhat.com> <500447E4.1030509@redhat.com> <20120724151315.GA1780@redhat.com> <1343326530.3763.23.camel@localhost.localdomain> Message-ID: <50122BA2.30103@redhat.com> On Thu 26 Jul 2012 08:15:30 PM CEST, Ian McLeod wrote: > On Tue, 2012-07-24 at 11:13 -0400, Hugh O. Brock wrote: >> On Mon, Jul 16, 2012 at 06:57:08PM +0200, Ivan Ne?as wrote: >>> >>> With funzo, we're trying to figure out how the Aeolus + Katello could >>> better integrate together. >>> >>> The templates in Katello are going to be replaced with component outlines. In >>> discussion about Foreman integration, it was not mentioned, that the >>> Compontent Outline will contain the list of packages (System Template >>> like we know it today has it). This is not required by Foreman (Foreman >>> solves it with Puppet), but Aeolus is able to take the list of >>> packages and install it into the built image, if I understand it >>> correctly. Was it meant to be this way, or we just skipped it when >>> talking about Foreman. It seems quite valuable Aeolus feature to me. >> >> Yeah, users do want to be able to do image based provisioning, in some >> cases with quite complex images. In fact I was discussing with Ian >> Mcleod the other day the idea that Factory might need to grow the >> ability to invoke Puppet after it finishes running the native >> installer when building the image (or running scripts on a pre-build >> JEOS). >> >> Another option, quite seriously, would be to look at having Factory >> use Puppet to resolve package requirements just as Foreman >> does. Historically we have shied away from this approach because RPM >> should take care of packaging requirements... but if we want to build >> something that isn't RPM based, well, that won't work. Factory guys, >> any thoughts? > > Adding puppet to the list of Factory customization steps is entirely > possible. Issues that come to mind: > > * The details of what is actually in the image will now be spread > between the TDL itself and the configuration on the puppet server. (And > perhaps this is a good thing for some people.) > > * For snapshot-style builds, we need to ensure that the remote JEOS > instance (on, for example, EC2) can communicate with the puppet server. > > * At least some of the puppet rules and use cases I have seen involve > actions that are based on the unique identity of the host being modified > or involve building out that identity by doing things like bootstrapping > into a kerberos environment, establishing SSH host keys, etc. > Obviously, these kinds of things cannot happen at image creation time. > (Or, in the best case, they need to be repeated at instance creation > time.) If prepared properly, puppet manifests can be applied even without the master present. Especially, if the user that prepares the manifests counts on the fact, that it could be run without master (which is not so hard to test), he could then benefit significantly from this. He probably still might want to rerun it on instance creation time, but it's much faster then running against a JEOS. -- Ivan .. >>> Another thing to solve is how to call back to Katello after the >>> instance was deployed by Aeolus (if we're not satisfied with the >>> current status of setting the script manually in deployable, which I >>> guess we're not). It seems for now that Audrey is the only way how to >>> run some scripts after the image was deployed. Will there we some other >>> way for running scripts after deployment in Cloud Engine. If not, it >>> seems that we will need to run Audrey and Puppet side by side. Maybe >>> it's ok, just asking, if its acceptable to have two config servers run >>> against the same machine? >> >> There's some interesting work going on with cloud-init that may >> eliminate the Audrey requirement. Joe Vlcek is driving that, we might >> check with him. >> >> --Hugh >> >>> Ohad: >>> >>> How does Foreman solve the EC2 deployment against Foreman? >>> >>> -- >>> Ivan >>> >>> >>> >>> >> > -- Ivan From msuchy at redhat.com Fri Jul 27 08:14:21 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Fri, 27 Jul 2012 10:14:21 +0200 Subject: [katello-devel] Katello schema - documentation and questions Message-ID: <50124DDD.9040009@redhat.com> While working on APIDocumentationEfforts [1] I wanted some nice documentation of our schema. I find we have none, so I created one: http://miroslav.suchy.cz/katello/katelloschema.html It is created by PostgreSQL Autodoc [2]. To my surprise it does not contain foreign keys and very few indexes. First I thought it is bug in Autodoc. But then - to my horor - I find it is not bug. We do not have foreign keys and indexes on most tables! So we have two issues. 1) Indexes: E.g. table user_notices, which purpose is IMHO always to live between two JOINS and is school example where indexes should be used, do not have indexes. I can go through schema and suggest where we should create indexes. I do not expect that it would cause any problem. Objections here? 2) Foreign keys: I read about foreign keys and ruby and I learned that community around Rails think that application level is best/enough to keep data consistency. So I expect a lot of discussion here. Let me share my point of view here: IMO data consistency should be work of database engine. There are two examples: a) when our code is fatally interrupted. E.g. src/app/models/glue/pulp/repo.rb: def destroy_repo_orchestration pre_queue.create(:name => "remove product content : #{self.name}", :priority => 1, :action => [self, :del_content]) [.. FATAL CRASH HERE ...] pre_queue.create(:name => "delete pulp repo : #{self.name}", :priority => 2, :action => [self, :destroy_repo]) end You will end up with repository with product id, which does not exist. Foreign keys with ON DELETE CASCADE solve this. b) But even if we solve all issues in our code (e.g start using transactions), there is problems with humans. During my 5 years in RHN Satellite team I seen non trivial numbers of Customers issues, where either customer or even TAM(!) run directly SQL commands, which without foreign keys would result in inconsistent database. Using foreign keys seems doable: https://github.com/matthuhiggins/foreigner https://github.com/jenseng/immigrant So it should be basically two gems, few lines of code and some testing. Your opinions? [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts [2] http://www.rbt.ca/autodoc/ (available in Fedora as package) Mirek From inecas at redhat.com Fri Jul 27 10:00:33 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Fri, 27 Jul 2012 12:00:33 +0200 Subject: [katello-devel] RFC - Katello Component Outlines provisioning using Aeolus and Foreman Message-ID: <501266C1.4060009@redhat.com> Hi, I've tried to write down the some basic design document [1] about possible ways how integration of Foreman/Aeolus could look like in terms of Katello Component Outlines provisioning. Comments and suggestions welcome. [1] - https://fedorahosted.org/katello/wiki/ComponentOutlinesProvisioning -- Ivan From ppokorny at redhat.com Fri Jul 27 10:09:13 2012 From: ppokorny at redhat.com (Pavel Pokorny) Date: Fri, 27 Jul 2012 12:09:13 +0200 Subject: [katello-devel] Faster development environment Message-ID: <501268C9.6080908@redhat.com> Hi Katello developers, if you experience problems with the speed of development environment, try gem called rails-dev-boost[1]. Just add one line [2] to your Gemfile and run bundle. Every request is handled noticeable faster with this gem. [1] https://github.com/thedarkone/rails-dev-boost/ [2] gem 'rails-dev-boost', :git => 'git://github.com/thedarkone/rails-dev-boost.git', :require => 'rails_development_boost' -- Pavel ppokorny #katello From vondruch at redhat.com Fri Jul 27 12:48:57 2012 From: vondruch at redhat.com (=?UTF-8?B?VsOtdCBPbmRydWNo?=) Date: Fri, 27 Jul 2012 14:48:57 +0200 Subject: [katello-devel] Fwd: Rails updated to 3.2.6 in Rawhide In-Reply-To: <2093371484.5019064.1343378390775.JavaMail.root@redhat.com> References: <2093371484.5019064.1343378390775.JavaMail.root@redhat.com> Message-ID: <50128E39.8010604@redhat.com> Just FYI Vit -------- P?vodn? zpr?va -------- P?edm?t: Rails updated to 3.2.6 in Rawhide Datum: Fri, 27 Jul 2012 04:39:50 -0400 (EDT) Od: Bohuslav Kabrda P?eposl?no - Komu: Ruby SIG mailing list Komu: Development discussions related to Fedora , Ruby SIG mailing list Hi all! The Ruby on Rails stack has been updated to 3.2.6 version in Rawhide, as it was submitted in the Rails 3.2 Feature [1]. I'd like to ask all owners of depending packages to start rebuilding (or updating, if necessary). The depending packages are listed at [2]. Thanks! -- Regards, Bohuslav "Slavek" Kabrda. [1] https://fedoraproject.org/wiki/Features/Rails_3.2 [2] https://fedoraproject.org/wiki/Features/Rails_3.2#Dependencies _______________________________________________ ruby-sig mailing list ruby-sig at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmckay at redhat.com Fri Jul 27 13:12:25 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 27 Jul 2012 09:12:25 -0400 (EDT) Subject: [katello-devel] Fwd: VCR w/ spec tests In-Reply-To: <1337838078.13324541.1343394494254.JavaMail.root@redhat.com> Message-ID: <1538922448.13328511.1343394745342.JavaMail.root@redhat.com> ----- Forwarded Message ----- > From: "Tom McKay" > To: "Chris Alfonso" > Cc: aeolus-devel at lists.fedorahosted.org > Sent: Friday, July 27, 2012 9:08:14 AM > Subject: Re: VCR w/ spec tests > > > > ----- Original Message ----- > > From: "Chris Alfonso" > > To: "Tom McKay" > > Cc: aeolus-devel at lists.fedorahosted.org > > Sent: Friday, July 27, 2012 9:00:01 AM > > Subject: Re: VCR w/ spec tests > > > > On 27/07/12 08:43 -0400, Tom McKay wrote: > > > > > >I saw a patch come across that mentioned VCR; is that used in > > >Aeolus? If so, are there some docs on how it's used? Are there any > > >issues with the set of gems required as they relate to RHEL and > > >Fedora? > > > > > >Thanks! > > >Tom > > > > We are pulling in the VCR rubygem from our own repo > > http://download.lab.bos.redhat.com/rel-eng/CloudForms/latest/el6-ce/x86_64/os/Packages/ > > Nice! I'm going to hook it into katello based off the rubygem-* > there. Our current spec tests mock at too high a level, imho, and > I've been wanting to do something better. > > > > > I don't know of more documentation out there other than this > > https://www.relishapp.com/myronmarston/vcr/docs > > > > Conductor uses VCR to mock external service calle, such as image > > factory or > > image warehouse. > > > > -- Chris > > > I'm going to spend some time trying out VCR, using the rubygem-* from aeolus. If anyone has input on best practices, etc., speak up. I know someone mentioned VCR during our tech review a few months back, and after checking out a few comparable packages, VCR seemed the best. Having Aeolus already using it just ups the value. From lzap at redhat.com Fri Jul 27 13:26:49 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 27 Jul 2012 15:26:49 +0200 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <50124DDD.9040009@redhat.com> References: <50124DDD.9040009@redhat.com> Message-ID: <20120727132649.GA8314@lzapx.brq.redhat.com> +1 for adding foreign keys. LZ On Fri, Jul 27, 2012 at 10:14:21AM +0200, Miroslav Suchy wrote: > While working on APIDocumentationEfforts [1] I wanted some nice > documentation of our schema. I find we have none, so I created one: > http://miroslav.suchy.cz/katello/katelloschema.html > It is created by PostgreSQL Autodoc [2]. > > To my surprise it does not contain foreign keys and very few indexes. > First I thought it is bug in Autodoc. But then - to my horor - I > find it is not bug. We do not have foreign keys and indexes on most > tables! > > So we have two issues. > > 1) Indexes: > E.g. table user_notices, which purpose is IMHO always to live > between two JOINS and is school example where indexes should be > used, do not have indexes. > I can go through schema and suggest where we should create indexes. > I do not expect that it would cause any problem. > Objections here? > > 2) Foreign keys: > I read about foreign keys and ruby and I learned that community > around Rails think that application level is best/enough to keep > data consistency. So I expect a lot of discussion here. > Let me share my point of view here: > IMO data consistency should be work of database engine. > There are two examples: > a) when our code is fatally interrupted. E.g. > > src/app/models/glue/pulp/repo.rb: > def destroy_repo_orchestration > pre_queue.create(:name => "remove product content : > #{self.name}", :priority => 1, :action => [self, :del_content]) > [.. FATAL CRASH HERE ...] > pre_queue.create(:name => "delete pulp repo : #{self.name}", > :priority => 2, :action => [self, :destroy_repo]) > end > > You will end up with repository with product id, which does not exist. > Foreign keys with ON DELETE CASCADE solve this. > > b) But even if we solve all issues in our code (e.g start using > transactions), there is problems with humans. > During my 5 years in RHN Satellite team I seen non trivial numbers > of Customers issues, where either customer or even TAM(!) run > directly SQL commands, which without foreign keys would result in > inconsistent database. > Using foreign keys seems doable: > https://github.com/matthuhiggins/foreigner > https://github.com/jenseng/immigrant > So it should be basically two gems, few lines of code and some testing. > > Your opinions? > > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > [2] http://www.rbt.ca/autodoc/ (available in Fedora as package) > > Mirek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From sseago at redhat.com Fri Jul 27 14:29:33 2012 From: sseago at redhat.com (Scott Seago) Date: Fri, 27 Jul 2012 10:29:33 -0400 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <50124DDD.9040009@redhat.com> References: <50124DDD.9040009@redhat.com> Message-ID: <5012A5CD.7080605@redhat.com> On 07/27/2012 04:14 AM, Miroslav Suchy wrote: > While working on APIDocumentationEfforts [1] I wanted some nice > documentation of our schema. I find we have none, so I created one: > http://miroslav.suchy.cz/katello/katelloschema.html > It is created by PostgreSQL Autodoc [2]. > > To my surprise it does not contain foreign keys and very few indexes. > First I thought it is bug in Autodoc. But then - to my horor - I find > it is not bug. We do not have foreign keys and indexes on most tables! > > So we have two issues. > > 1) Indexes: > E.g. table user_notices, which purpose is IMHO always to live between > two JOINS and is school example where indexes should be used, do not > have indexes. > I can go through schema and suggest where we should create indexes. > I do not expect that it would cause any problem. > Objections here? > > 2) Foreign keys: > I read about foreign keys and ruby and I learned that community around > Rails think that application level is best/enough to keep data > consistency. So I expect a lot of discussion here. > Let me share my point of view here: > IMO data consistency should be work of database engine. > There are two examples: > a) when our code is fatally interrupted. E.g. > > src/app/models/glue/pulp/repo.rb: > def destroy_repo_orchestration > pre_queue.create(:name => "remove product content : #{self.name}", > :priority => 1, :action => [self, :del_content]) > [.. FATAL CRASH HERE ...] > pre_queue.create(:name => "delete pulp repo : #{self.name}", > :priority => 2, :action => [self, :destroy_repo]) > end > > You will end up with repository with product id, which does not exist. > Foreign keys with ON DELETE CASCADE solve this. > > b) But even if we solve all issues in our code (e.g start using > transactions), there is problems with humans. > During my 5 years in RHN Satellite team I seen non trivial numbers of > Customers issues, where either customer or even TAM(!) run directly > SQL commands, which without foreign keys would result in inconsistent > database. Note that, with rails, direct SQL modification can result in inconsistent database even with foreign keys. This bypasses validation, hooks, etc. I know for a fact that direct SQL modification will result in invalid data with conductor on issues unrelated to foreign keys -- I'd suspect katello is similar. We need to be clear in our documentation that customers (and TAMs!) need to use the rails console if they need to manipulate data outside of the app. Basically for rails/ActiveRecord, "rails console" == "psql" -- anything else will corrupt data! That said, I'm still in favor of using actual database foreign keys (as long as we do it in a database-independent way -- i.e. works for PG, mysql, sqlite, which I'm assuming the below gems will do). > Using foreign keys seems doable: > https://github.com/matthuhiggins/foreigner > https://github.com/jenseng/immigrant > So it should be basically two gems, few lines of code and some testing. > > Your opinions? > > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > [2] http://www.rbt.ca/autodoc/ (available in Fedora as package) > > Mirek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Fri Jul 27 16:10:15 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 27 Jul 2012 09:10:15 -0700 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <20120727132649.GA8314@lzapx.brq.redhat.com> References: <50124DDD.9040009@redhat.com> <20120727132649.GA8314@lzapx.brq.redhat.com> Message-ID: <5012BD67.8030305@redhat.com> agreed, +1 to FKs and indexes On 07/27/2012 06:26 AM, Lukas Zapletal wrote: > +1 for adding foreign keys. > > LZ > > On Fri, Jul 27, 2012 at 10:14:21AM +0200, Miroslav Suchy wrote: >> While working on APIDocumentationEfforts [1] I wanted some nice >> documentation of our schema. I find we have none, so I created one: >> http://miroslav.suchy.cz/katello/katelloschema.html >> It is created by PostgreSQL Autodoc [2]. >> >> To my surprise it does not contain foreign keys and very few indexes. >> First I thought it is bug in Autodoc. But then - to my horor - I >> find it is not bug. We do not have foreign keys and indexes on most >> tables! >> >> So we have two issues. >> >> 1) Indexes: >> E.g. table user_notices, which purpose is IMHO always to live >> between two JOINS and is school example where indexes should be >> used, do not have indexes. >> I can go through schema and suggest where we should create indexes. >> I do not expect that it would cause any problem. >> Objections here? >> >> 2) Foreign keys: >> I read about foreign keys and ruby and I learned that community >> around Rails think that application level is best/enough to keep >> data consistency. So I expect a lot of discussion here. >> Let me share my point of view here: >> IMO data consistency should be work of database engine. >> There are two examples: >> a) when our code is fatally interrupted. E.g. >> >> src/app/models/glue/pulp/repo.rb: >> def destroy_repo_orchestration >> pre_queue.create(:name => "remove product content : >> #{self.name}", :priority => 1, :action => [self, :del_content]) >> [.. FATAL CRASH HERE ...] >> pre_queue.create(:name => "delete pulp repo : #{self.name}", >> :priority => 2, :action => [self, :destroy_repo]) >> end >> >> You will end up with repository with product id, which does not exist. >> Foreign keys with ON DELETE CASCADE solve this. >> >> b) But even if we solve all issues in our code (e.g start using >> transactions), there is problems with humans. >> During my 5 years in RHN Satellite team I seen non trivial numbers >> of Customers issues, where either customer or even TAM(!) run >> directly SQL commands, which without foreign keys would result in >> inconsistent database. >> Using foreign keys seems doable: >> https://github.com/matthuhiggins/foreigner >> https://github.com/jenseng/immigrant >> So it should be basically two gems, few lines of code and some testing. >> >> Your opinions? >> >> >> [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts >> [2] http://www.rbt.ca/autodoc/ (available in Fedora as package) >> >> Mirek >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > From omaciel at redhat.com Fri Jul 27 17:38:40 2012 From: omaciel at redhat.com (Og Maciel) Date: Fri, 27 Jul 2012 13:38:40 -0400 (EDT) Subject: [katello-devel] "Interesting" log messages when starting katello In-Reply-To: <105731381.4043707.1343410642268.JavaMail.root@redhat.com> Message-ID: <1465366460.4043862.1343410720973.JavaMail.root@redhat.com> Hmmm... does anyone know what this is supposed to mean? Seen when running katello-service start INFO: [The Night Man] new_master [The Night Man][vuUOJdYVTXSm3Oo3c3V2LQ][inet[localhost/127.0.0.1:9300]], reason: zen-disco-join (elected_as_master) Full blown output # katello-service start Starting Katello services... Starting tomcat6: [ OK ] Waiting for tomcat to be ready ... Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using for ServerName [ OK ] Starting mongod: [ OK ] Starting Qpid AMQP daemon: [ OK ] Starting httpd: Starting elasticsearch: [ OK ] Starting katello: Jul 27, 2012 1:10:40 PM node INFO: [Crossfire] {0.18.4}[19778]: initializing ... Jul 27, 2012 1:10:40 PM plugins INFO: [Crossfire] loaded [], sites [] Starting server on 0.0.0.0:5000 ... Starting server on 0.0.0.0:5001 ... Starting server on 0.0.0.0:5002 ... Starting server on 0.0.0.0:5003 ... Jul 27, 2012 1:10:42 PM node INFO: [Crossfire] {0.18.4}[19778]: initialized Jul 27, 2012 1:10:42 PM node INFO: [Crossfire] {0.18.4}[19778]: starting ... Starting server on 0.0.0.0:5004 ... Jul 27, 2012 1:10:42 PM transport INFO: [Crossfire] bound_address {inet[/127.0.0.1:9300]}, publish_address {inet[localhost/127.0.0.1:9300]} [ OK ] Starting katello-jobs: bash: /var/log/katello/jobs-startup.log: Permission denied [FAILED] Done. [root at qetello02 ~]# Jul 27, 2012 1:10:46 PM cluster.service INFO: [Crossfire] new_master [Crossfire][yI-3uxg4S8iq3EjGtHGwUQ][inet[localhost/127.0.0.1:9300]], reason: zen-disco-join (elected_as_master) Jul 27, 2012 1:10:46 PM discovery INFO: [Crossfire] elasticsearch/yI-3uxg4S8iq3EjGtHGwUQ Jul 27, 2012 1:10:46 PM http INFO: [Crossfire] bound_address {inet[/127.0.0.1:9200]}, publish_address {inet[localhost/127.0.0.1:9200]} Jul 27, 2012 1:10:46 PM node INFO: [Crossfire] {0.18.4}[19778]: started -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From omaciel at redhat.com Fri Jul 27 17:45:04 2012 From: omaciel at redhat.com (Og Maciel) Date: Fri, 27 Jul 2012 13:45:04 -0400 (EDT) Subject: [katello-devel] "Interesting" log messages when starting katello In-Reply-To: <1465366460.4043862.1343410720973.JavaMail.root@redhat.com> Message-ID: <786925645.4046992.1343411104178.JavaMail.root@redhat.com> Moreover: # rpm -q katello katello-0.2.52-1.git.0.c9d729a.el6_3.noarch # service katello-jobs status katello-jobs is not running. # service katello-jobs start Starting katello-jobs: bash: /var/log/katello/jobs-startup.log: Permission denied # ls -l /var/log/katello/jobs-startup.log ls: cannot access /var/log/katello/jobs-startup.log: No such file or directory -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From esammons at redhat.com Fri Jul 27 17:53:03 2012 From: esammons at redhat.com (Eric Sammons) Date: Fri, 27 Jul 2012 13:53:03 -0400 (EDT) Subject: [katello-devel] "Interesting" log messages when starting katello In-Reply-To: <1465366460.4043862.1343410720973.JavaMail.root@redhat.com> Message-ID: <1973251932.4050565.1343411583707.JavaMail.root@redhat.com> ----- Original Message ----- > Hmmm... does anyone know what this is supposed to mean? Seen when > running katello-service start > > INFO: [The Night Man] new_master [The Night > Man][vuUOJdYVTXSm3Oo3c3V2LQ][inet[localhost/127.0.0.1:9300]], > reason: zen-disco-join (elected_as_master) > > Full blown output > > # katello-service start > Starting Katello services... > Starting tomcat6: [ OK ] > Waiting for tomcat to be ready ... > Starting httpd: httpd: Could not reliably determine the server's > fully qualified domain name, using for > ServerName This error is typically ok and if I recall correctly tends to occur in cases where you are using dhcp and your dhcp name is X but your hostname is Y. It may also occur when reverse dns lookups are not configured or not working; again this can be because your dns name is dhcpxxxx and your system name is yyyyyy. > [ OK ] > Starting mongod: [ OK ] > Starting Qpid AMQP daemon: [ OK ] > Starting httpd: > Starting elasticsearch: [ OK ] > Starting katello: Jul 27, 2012 1:10:40 PM node > INFO: [Crossfire] {0.18.4}[19778]: initializing ... > Jul 27, 2012 1:10:40 PM plugins > INFO: [Crossfire] loaded [], sites [] > Starting server on 0.0.0.0:5000 ... > Starting server on 0.0.0.0:5001 ... > Starting server on 0.0.0.0:5002 ... > Starting server on 0.0.0.0:5003 ... > Jul 27, 2012 1:10:42 PM node > INFO: [Crossfire] {0.18.4}[19778]: initialized > Jul 27, 2012 1:10:42 PM node > INFO: [Crossfire] {0.18.4}[19778]: starting ... > Starting server on 0.0.0.0:5004 ... > Jul 27, 2012 1:10:42 PM transport > INFO: [Crossfire] bound_address {inet[/127.0.0.1:9300]}, > publish_address {inet[localhost/127.0.0.1:9300]} > [ OK ] > Starting katello-jobs: bash: /var/log/katello/jobs-startup.log: > Permission denied > [FAILED] > Done. Check the status of selinux; I have been seeing some new selinux related issue crop up. If getenforce returns "Enforcing" do 'setenforce 0' and see what you get when you start katello-jobs (or try to start it). --Eric > [root at qetello02 ~]# Jul 27, 2012 1:10:46 PM cluster.service > INFO: [Crossfire] new_master > [Crossfire][yI-3uxg4S8iq3EjGtHGwUQ][inet[localhost/127.0.0.1:9300]], > reason: zen-disco-join (elected_as_master) > Jul 27, 2012 1:10:46 PM discovery > INFO: [Crossfire] elasticsearch/yI-3uxg4S8iq3EjGtHGwUQ > Jul 27, 2012 1:10:46 PM http > INFO: [Crossfire] bound_address {inet[/127.0.0.1:9200]}, > publish_address {inet[localhost/127.0.0.1:9200]} > Jul 27, 2012 1:10:46 PM node > INFO: [Crossfire] {0.18.4}[19778]: started > > -- > Og Maciel > > Senior QA Engineer > Red Hat, Inc. > +1.919.754.4782 > irc: omaciel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From esammons at redhat.com Fri Jul 27 17:56:31 2012 From: esammons at redhat.com (Eric Sammons) Date: Fri, 27 Jul 2012 13:56:31 -0400 (EDT) Subject: [katello-devel] "Interesting" log messages when starting katello In-Reply-To: <786925645.4046992.1343411104178.JavaMail.root@redhat.com> Message-ID: <895863178.4052211.1343411791444.JavaMail.root@redhat.com> ---- Original Message ----- > Moreover: > > # rpm -q katello > katello-0.2.52-1.git.0.c9d729a.el6_3.noarch > # service katello-jobs status > katello-jobs is not running. > # service katello-jobs start > Starting katello-jobs: bash: /var/log/katello/jobs-startup.log: > Permission denied > # ls -l /var/log/katello/jobs-startup.log > ls: cannot access /var/log/katello/jobs-startup.log: No such file or > directory Try the following: 1. if getenforce return Enforcing: # setenforce 0 # service katello-jobs start if successful great we know it is selinux related; if not try: 2. Create the log file: # touch /var/log/katello/jobs-startup.log # chown owner.group /var/log/katello/jobs-startup.log # service katello-jobs start [note: this code fail due to you creating the file by hand, doing this may cause a selinux error. You may need to set the context on the file appropriately.] > -- > Og Maciel > > Senior QA Engineer > Red Hat, Inc. > +1.919.754.4782 > irc: omaciel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From omaciel at redhat.com Fri Jul 27 18:14:03 2012 From: omaciel at redhat.com (Og Maciel) Date: Fri, 27 Jul 2012 14:14:03 -0400 (EDT) Subject: [katello-devel] "Interesting" log messages when starting katello In-Reply-To: <895863178.4052211.1343411791444.JavaMail.root@redhat.com> Message-ID: <2121941871.4061686.1343412843391.JavaMail.root@redhat.com> > Try the following: > > 1. if getenforce return Enforcing: > # setenforce 0 > # service katello-jobs start > > if successful great we know it is selinux related; if not try: No dice > 2. Create the log file: > # touch /var/log/katello/jobs-startup.log > # chown owner.group /var/log/katello/jobs-startup.log > # service katello-jobs start > [note: this code fail due to you creating the file by hand, > doing this may cause a selinux error. You may need to set the > context on the file appropriately.] No dice -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From jsherril at redhat.com Fri Jul 27 20:18:10 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Fri, 27 Jul 2012 16:18:10 -0400 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <5012BD67.8030305@redhat.com> References: <50124DDD.9040009@redhat.com> <20120727132649.GA8314@lzapx.brq.redhat.com> <5012BD67.8030305@redhat.com> Message-ID: <5012F782.1040902@redhat.com> +1 On 07/27/2012 12:10 PM, Mike McCune wrote: > agreed, +1 to FKs and indexes > > On 07/27/2012 06:26 AM, Lukas Zapletal wrote: >> +1 for adding foreign keys. >> >> LZ >> >> On Fri, Jul 27, 2012 at 10:14:21AM +0200, Miroslav Suchy wrote: >>> While working on APIDocumentationEfforts [1] I wanted some nice >>> documentation of our schema. I find we have none, so I created one: >>> http://miroslav.suchy.cz/katello/katelloschema.html >>> It is created by PostgreSQL Autodoc [2]. >>> >>> To my surprise it does not contain foreign keys and very few indexes. >>> First I thought it is bug in Autodoc. But then - to my horor - I >>> find it is not bug. We do not have foreign keys and indexes on most >>> tables! >>> >>> So we have two issues. >>> >>> 1) Indexes: >>> E.g. table user_notices, which purpose is IMHO always to live >>> between two JOINS and is school example where indexes should be >>> used, do not have indexes. >>> I can go through schema and suggest where we should create indexes. >>> I do not expect that it would cause any problem. >>> Objections here? >>> >>> 2) Foreign keys: >>> I read about foreign keys and ruby and I learned that community >>> around Rails think that application level is best/enough to keep >>> data consistency. So I expect a lot of discussion here. >>> Let me share my point of view here: >>> IMO data consistency should be work of database engine. >>> There are two examples: >>> a) when our code is fatally interrupted. E.g. >>> >>> src/app/models/glue/pulp/repo.rb: >>> def destroy_repo_orchestration >>> pre_queue.create(:name => "remove product content : >>> #{self.name}", :priority => 1, :action => [self, :del_content]) >>> [.. FATAL CRASH HERE ...] >>> pre_queue.create(:name => "delete pulp repo : #{self.name}", >>> :priority => 2, :action => [self, :destroy_repo]) >>> end >>> >>> You will end up with repository with product id, which does not exist. >>> Foreign keys with ON DELETE CASCADE solve this. >>> >>> b) But even if we solve all issues in our code (e.g start using >>> transactions), there is problems with humans. >>> During my 5 years in RHN Satellite team I seen non trivial numbers >>> of Customers issues, where either customer or even TAM(!) run >>> directly SQL commands, which without foreign keys would result in >>> inconsistent database. >>> Using foreign keys seems doable: >>> https://github.com/matthuhiggins/foreigner >>> https://github.com/jenseng/immigrant >>> So it should be basically two gems, few lines of code and some testing. >>> >>> Your opinions? >>> >>> >>> [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts >>> [2] http://www.rbt.ca/autodoc/ (available in Fedora as package) >>> >>> Mirek >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Fri Jul 27 22:01:38 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 27 Jul 2012 15:01:38 -0700 Subject: [katello-devel] Faster development environment In-Reply-To: <501268C9.6080908@redhat.com> References: <501268C9.6080908@redhat.com> Message-ID: <50130FC2.8000707@redhat.com> On 07/27/2012 03:09 AM, Pavel Pokorny wrote: > Hi Katello developers, > if you experience problems with the speed of development environment, > try gem called rails-dev-boost[1]. > Just add one line [2] to your Gemfile and run bundle. Every request is > handled noticeable faster with this gem. > > [1]https://github.com/thedarkone/rails-dev-boost/ > [2] gem 'rails-dev-boost', :git => > 'git://github.com/thedarkone/rails-dev-boost.git', :require => > 'rails_development_boost' thanks Pavel, this is *awesome* made my dev mode run almost as fast as production yet I was able to make code changes without a restart Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From ohadlevy at redhat.com Sun Jul 29 07:17:08 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Sun, 29 Jul 2012 10:17:08 +0300 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <50122BA2.30103@redhat.com> References: <500440E6.5060707@redhat.com> <500447E4.1030509@redhat.com> <20120724151315.GA1780@redhat.com> <1343326530.3763.23.camel@localhost.localdomain> <50122BA2.30103@redhat.com> Message-ID: <5014E374.6030801@redhat.com> On 07/27/2012 08:48 AM, Ivan Ne?as wrote: > If prepared properly, puppet manifests can be applied even without the > master present. Especially, if the user that prepares the manifests > counts on the fact, that it could be run without master (which is not so > hard to test), he could then benefit significantly from this. He > probably still might want to rerun it on instance creation time, but > it's much faster then running against a JEOS. True, but you really want to make sure that all services are stopped afterwards, until firstoboot would activate/reconfigure them again. so the bottom line, creating a new custom image vs using JEOS is an optimization step (less time to get a new customized instance to run) due to the fact that you upload the content upfront, it should potentially also save some disk space (if you would be using snapshots). saying that, you must make sure that you have nothing specific from the image creation time, such as services running etc, so in reality, you just want the packages, nothing else. I would think that using puppet for creating the image is a good idea, but might not fit exactly to how puppet works, and you could consider adding tags [1] or run stages[2] or simply send a patch to puppet to auto tag packages and then you could ask puppet to install only packages. Ohad [1] http://projects.puppetlabs.com/projects/1/wiki/Using_Tags [2] http://docs.puppetlabs.com/guides/language_guide.html From bkearney at redhat.com Sun Jul 29 13:06:25 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Sun, 29 Jul 2012 09:06:25 -0400 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <5012A5CD.7080605@redhat.com> References: <50124DDD.9040009@redhat.com> <5012A5CD.7080605@redhat.com> Message-ID: <50153551.2070601@redhat.com> On 07/27/2012 10:29 AM, Scott Seago wrote: > On 07/27/2012 04:14 AM, Miroslav Suchy wrote: >> While working on APIDocumentationEfforts [1] I wanted some nice >> documentation of our schema. I find we have none, so I created one: >> http://miroslav.suchy.cz/katello/katelloschema.html >> It is created by PostgreSQL Autodoc [2]. >> >> To my surprise it does not contain foreign keys and very few indexes. >> First I thought it is bug in Autodoc. But then - to my horor - I find >> it is not bug. We do not have foreign keys and indexes on most tables! >> >> So we have two issues. >> >> 1) Indexes: >> E.g. table user_notices, which purpose is IMHO always to live between >> two JOINS and is school example where indexes should be used, do not >> have indexes. >> I can go through schema and suggest where we should create indexes. >> I do not expect that it would cause any problem. >> Objections here? >> >> 2) Foreign keys: >> I read about foreign keys and ruby and I learned that community around >> Rails think that application level is best/enough to keep data >> consistency. So I expect a lot of discussion here. >> Let me share my point of view here: >> IMO data consistency should be work of database engine. >> There are two examples: >> a) when our code is fatally interrupted. E.g. >> >> src/app/models/glue/pulp/repo.rb: >> def destroy_repo_orchestration >> pre_queue.create(:name => "remove product content : #{self.name}", >> :priority => 1, :action => [self, :del_content]) >> [.. FATAL CRASH HERE ...] >> pre_queue.create(:name => "delete pulp repo : #{self.name}", >> :priority => 2, :action => [self, :destroy_repo]) >> end >> >> You will end up with repository with product id, which does not exist. >> Foreign keys with ON DELETE CASCADE solve this. >> >> b) But even if we solve all issues in our code (e.g start using >> transactions), there is problems with humans. >> During my 5 years in RHN Satellite team I seen non trivial numbers of >> Customers issues, where either customer or even TAM(!) run directly >> SQL commands, which without foreign keys would result in inconsistent >> database. > Note that, with rails, direct SQL modification can result in > inconsistent database even with foreign keys. This bypasses validation, > hooks, etc. I know for a fact that direct SQL modification will result > in invalid data with conductor on issues unrelated to foreign keys -- > I'd suspect katello is similar. > > We need to be clear in our documentation that customers (and TAMs!) need > to use the rails console if they need to manipulate data outside of the > app. Basically for rails/ActiveRecord, "rails console" == "psql" -- > anything else will corrupt data! > > That said, I'm still in favor of using actual database foreign keys (as > long as we do it in a database-independent way -- i.e. works for PG, > mysql, sqlite, which I'm assuming the below gems will do). We hit this in candlepin recently. What we also learned with postgres is that foreign keys do not give you indexes by default. -- bk From inecas at redhat.com Mon Jul 30 07:02:39 2012 From: inecas at redhat.com (Ivan Necas) Date: Mon, 30 Jul 2012 03:02:39 -0400 (EDT) Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <5014E374.6030801@redhat.com> Message-ID: <1988776871.4843424.1343631759553.JavaMail.root@redhat.com> Maybe the user preparing the puppet manifests should decide what to run when. That's what I do, when preparing reusable system images fo myself: having separated classes for preparing the image (e.g packages installation) and classes needed in run-time (configuration itself). No matter if I use stages or tag or other way to do that, at the end it's one class (or set if classes) to run on the template system and another classes for run-time. So enabling the users to make this decision of selecting classes for build or run time would bring him the possibility to optimize their processes the way they like. -- Ivan ----- Original Message ----- From: Ohad Levy To: Ivan Ne?as Cc: Ian McLeod , aeolus-devel at fedorahosted.org, katello-devel at redhat.com Sent: Sun, 29 Jul 2012 03:17:08 -0400 (EDT) Subject: Re: [katello-devel] Improving Aeolus + Katello integration On 07/27/2012 08:48 AM, Ivan Ne?as wrote: > If prepared properly, puppet manifests can be applied even without the > master present. Especially, if the user that prepares the manifests > counts on the fact, that it could be run without master (which is not so > hard to test), he could then benefit significantly from this. He > probably still might want to rerun it on instance creation time, but > it's much faster then running against a JEOS. True, but you really want to make sure that all services are stopped afterwards, until firstoboot would activate/reconfigure them again. so the bottom line, creating a new custom image vs using JEOS is an optimization step (less time to get a new customized instance to run) due to the fact that you upload the content upfront, it should potentially also save some disk space (if you would be using snapshots). saying that, you must make sure that you have nothing specific from the image creation time, such as services running etc, so in reality, you just want the packages, nothing else. I would think that using puppet for creating the image is a good idea, but might not fit exactly to how puppet works, and you could consider adding tags [1] or run stages[2] or simply send a patch to puppet to auto tag packages and then you could ask puppet to install only packages. Ohad [1] http://projects.puppetlabs.com/projects/1/wiki/Using_Tags [2] http://docs.puppetlabs.com/guides/language_guide.html From ohadlevy at redhat.com Mon Jul 30 07:05:31 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Mon, 30 Jul 2012 10:05:31 +0300 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <1988776871.4843424.1343631759553.JavaMail.root@redhat.com> References: <1988776871.4843424.1343631759553.JavaMail.root@redhat.com> Message-ID: <5016323B.4050305@redhat.com> On 07/30/2012 10:02 AM, Ivan Necas wrote: > > Maybe the user preparing the puppet manifests should decide what to run when. That's what I do, when preparing reusable system images fo myself: having separated classes for preparing the image (e.g packages installation) and classes needed in run-time (configuration itself). No matter if I use stages or tag or other way to do that, at the end it's one class (or set if classes) to run on the template system and another classes for run-time. I don't think users would like to write their manifests twice (and test). > > So enabling the users to make this decision of selecting classes for build or run time would bring him the possibility to optimize their processes the way they like. I'm all for customization and ease of use, but if you remember the the only thing that really saves time is downloading and installing system binaries, then what we really need to care about is packages. we already have a way to let the user execute something when building the image, so i think of all that customization is already covered? > > > -- Ivan > > ----- Original Message ----- > From: Ohad Levy > To: Ivan Ne?as > Cc: Ian McLeod , aeolus-devel at fedorahosted.org, katello-devel at redhat.com > Sent: Sun, 29 Jul 2012 03:17:08 -0400 (EDT) > Subject: Re: [katello-devel] Improving Aeolus + Katello integration > > On 07/27/2012 08:48 AM, Ivan Ne?as wrote: >> If prepared properly, puppet manifests can be applied even without the >> master present. Especially, if the user that prepares the manifests >> counts on the fact, that it could be run without master (which is not so >> hard to test), he could then benefit significantly from this. He >> probably still might want to rerun it on instance creation time, but >> it's much faster then running against a JEOS. > > True, but you really want to make sure that all services are stopped > afterwards, until firstoboot would activate/reconfigure them again. > > so the bottom line, > > creating a new custom image vs using JEOS is an optimization step (less > time to get a new customized instance to run) due to the fact that you > upload the content upfront, it should potentially also save some disk > space (if you would be using snapshots). > > saying that, you must make sure that you have nothing specific from the > image creation time, such as services running etc, so in reality, you > just want the packages, nothing else. > > I would think that using puppet for creating the image is a good idea, > but might not fit exactly to how puppet works, and you could consider > adding tags [1] or run stages[2] or simply send a patch to puppet to > auto tag packages and then you could ask puppet to install only packages. > > > > Ohad > > [1] http://projects.puppetlabs.com/projects/1/wiki/Using_Tags > [2] http://docs.puppetlabs.com/guides/language_guide.html > > From inecas at redhat.com Mon Jul 30 07:18:09 2012 From: inecas at redhat.com (Ivan Necas) Date: Mon, 30 Jul 2012 03:18:09 -0400 (EDT) Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <5016323B.4050305@redhat.com> Message-ID: <180480390.4847557.1343632689016.JavaMail.root@redhat.com> ----- Ohad Levy wrote: > On 07/30/2012 10:02 AM, Ivan Necas wrote: > > > > Maybe the user preparing the puppet manifests should decide what to run when. That's what I do, when preparing reusable system images fo myself: having separated classes for preparing the image (e.g packages installation) and classes needed in run-time (configuration itself). No matter if I use stages or tag or other way to do that, at the end it's one class (or set if classes) to run on the template system and another classes for run-time. > > I don't think users would like to write their manifests twice (and test). I'm not writng nanifests twice. Just selecting classes that are save to run on the template system. > > > > > So enabling the users to make this decision of selecting classes for build or run time would bring him the possibility to optimize their processes the way they like. > > I'm all for customization and ease of use, but if you remember the the > only thing that really saves time is downloading and installing system > binaries, then what we really need to care about is packages. > > we already have a way to let the user execute something when building > the image, so i think of all that customization is already covered? What way do you have in mind? -- Ivan > > > > > > > -- Ivan > > > > ----- Original Message ----- > > From: Ohad Levy > > To: Ivan Ne?as > > Cc: Ian McLeod , aeolus-devel at fedorahosted.org, katello-devel at redhat.com > > Sent: Sun, 29 Jul 2012 03:17:08 -0400 (EDT) > > Subject: Re: [katello-devel] Improving Aeolus + Katello integration > > > > On 07/27/2012 08:48 AM, Ivan Ne?as wrote: > >> If prepared properly, puppet manifests can be applied even without the > >> master present. Especially, if the user that prepares the manifests > >> counts on the fact, that it could be run without master (which is not so > >> hard to test), he could then benefit significantly from this. He > >> probably still might want to rerun it on instance creation time, but > >> it's much faster then running against a JEOS. > > > > True, but you really want to make sure that all services are stopped > > afterwards, until firstoboot would activate/reconfigure them again. > > > > so the bottom line, > > > > creating a new custom image vs using JEOS is an optimization step (less > > time to get a new customized instance to run) due to the fact that you > > upload the content upfront, it should potentially also save some disk > > space (if you would be using snapshots). > > > > saying that, you must make sure that you have nothing specific from the > > image creation time, such as services running etc, so in reality, you > > just want the packages, nothing else. > > > > I would think that using puppet for creating the image is a good idea, > > but might not fit exactly to how puppet works, and you could consider > > adding tags [1] or run stages[2] or simply send a patch to puppet to > > auto tag packages and then you could ask puppet to install only packages. > > > > > > > > Ohad > > > > [1] http://projects.puppetlabs.com/projects/1/wiki/Using_Tags > > [2] http://docs.puppetlabs.com/guides/language_guide.html > > > > > From ohadlevy at redhat.com Mon Jul 30 07:26:36 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Mon, 30 Jul 2012 10:26:36 +0300 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <180480390.4847557.1343632689016.JavaMail.root@redhat.com> References: <180480390.4847557.1343632689016.JavaMail.root@redhat.com> Message-ID: <5016372C.9030400@redhat.com> On 07/30/2012 10:18 AM, Ivan Necas wrote: > > ----- Ohad Levy wrote: >> On 07/30/2012 10:02 AM, Ivan Necas wrote: >>> >>> Maybe the user preparing the puppet manifests should decide what to run when. That's what I do, when preparing reusable system images fo myself: having separated classes for preparing the image (e.g packages installation) and classes needed in run-time (configuration itself). No matter if I use stages or tag or other way to do that, at the end it's one class (or set if classes) to run on the template system and another classes for run-time. >> >> I don't think users would like to write their manifests twice (and test). > I'm not writng nanifests twice. Just selecting classes that are save to run on the template system. so assuming you had a puppet structure that has module-package class style i guess you could pull it off, but it needs to make assumptions on the manifest (e.g. written in a certain way) and that there are no references within the puppet code to other non included resources. you are right that's its possible, but we would expecting our users to build it in a certain way, and if they include the wrong classes there might be unexpected results. Also, do you assume this works in a masterless mode? (e.g you would need to distribute the manifests to the image + ensure that the manifests can work without a master). and more than that, we would probably need a cleanup script to be executed on the instance regardless. >> >>> >>> So enabling the users to make this decision of selecting classes for build or run time would bring him the possibility to optimize their processes the way they like. >> >> I'm all for customization and ease of use, but if you remember the the >> only thing that really saves time is downloading and installing system >> binaries, then what we really need to care about is packages. >> >> we already have a way to let the user execute something when building >> the image, so i think of all that customization is already covered? > > What way do you have in mind? we did discuss several times to reuse foreman templates as an post image / post first boot template engine processor, so it would be done in the exact same way like its done for bare metal/ vms. we also need to figure out how to deploy the initial certificates. (e.g. if we allow the instances to reach out or are we 'pushing' the certs to them etc). in foreman for vm/bare metals we let the hit a url (with a uuid) and for ec2 / openstack we simply ssh into the instances. Ohad > > -- Ivan >> >>> >>> >>> -- Ivan >>> >>> ----- Original Message ----- >>> From: Ohad Levy >>> To: Ivan Ne?as >>> Cc: Ian McLeod , aeolus-devel at fedorahosted.org, katello-devel at redhat.com >>> Sent: Sun, 29 Jul 2012 03:17:08 -0400 (EDT) >>> Subject: Re: [katello-devel] Improving Aeolus + Katello integration >>> >>> On 07/27/2012 08:48 AM, Ivan Ne?as wrote: >>>> If prepared properly, puppet manifests can be applied even without the >>>> master present. Especially, if the user that prepares the manifests >>>> counts on the fact, that it could be run without master (which is not so >>>> hard to test), he could then benefit significantly from this. He >>>> probably still might want to rerun it on instance creation time, but >>>> it's much faster then running against a JEOS. >>> >>> True, but you really want to make sure that all services are stopped >>> afterwards, until firstoboot would activate/reconfigure them again. >>> >>> so the bottom line, >>> >>> creating a new custom image vs using JEOS is an optimization step (less >>> time to get a new customized instance to run) due to the fact that you >>> upload the content upfront, it should potentially also save some disk >>> space (if you would be using snapshots). >>> >>> saying that, you must make sure that you have nothing specific from the >>> image creation time, such as services running etc, so in reality, you >>> just want the packages, nothing else. >>> >>> I would think that using puppet for creating the image is a good idea, >>> but might not fit exactly to how puppet works, and you could consider >>> adding tags [1] or run stages[2] or simply send a patch to puppet to >>> auto tag packages and then you could ask puppet to install only packages. >>> >>> >>> >>> Ohad >>> >>> [1] http://projects.puppetlabs.com/projects/1/wiki/Using_Tags >>> [2] http://docs.puppetlabs.com/guides/language_guide.html >>> >>> >> > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Mon Jul 30 10:02:57 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 30 Jul 2012 12:02:57 +0200 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <50124DDD.9040009@redhat.com> References: <50124DDD.9040009@redhat.com> Message-ID: <20120730100257.GE5373@lzapx.brq.redhat.com> By the way, what are the biggest concerns in regard to using foreign keys and rails? What is the issue? LZ On Fri, Jul 27, 2012 at 10:14:21AM +0200, Miroslav Suchy wrote: > While working on APIDocumentationEfforts [1] I wanted some nice > documentation of our schema. I find we have none, so I created one: > http://miroslav.suchy.cz/katello/katelloschema.html > It is created by PostgreSQL Autodoc [2]. > > To my surprise it does not contain foreign keys and very few indexes. > First I thought it is bug in Autodoc. But then - to my horor - I > find it is not bug. We do not have foreign keys and indexes on most > tables! > > So we have two issues. > > 1) Indexes: > E.g. table user_notices, which purpose is IMHO always to live > between two JOINS and is school example where indexes should be > used, do not have indexes. > I can go through schema and suggest where we should create indexes. > I do not expect that it would cause any problem. > Objections here? > > 2) Foreign keys: > I read about foreign keys and ruby and I learned that community > around Rails think that application level is best/enough to keep > data consistency. So I expect a lot of discussion here. > Let me share my point of view here: > IMO data consistency should be work of database engine. > There are two examples: > a) when our code is fatally interrupted. E.g. > > src/app/models/glue/pulp/repo.rb: > def destroy_repo_orchestration > pre_queue.create(:name => "remove product content : > #{self.name}", :priority => 1, :action => [self, :del_content]) > [.. FATAL CRASH HERE ...] > pre_queue.create(:name => "delete pulp repo : #{self.name}", > :priority => 2, :action => [self, :destroy_repo]) > end > > You will end up with repository with product id, which does not exist. > Foreign keys with ON DELETE CASCADE solve this. > > b) But even if we solve all issues in our code (e.g start using > transactions), there is problems with humans. > During my 5 years in RHN Satellite team I seen non trivial numbers > of Customers issues, where either customer or even TAM(!) run > directly SQL commands, which without foreign keys would result in > inconsistent database. > Using foreign keys seems doable: > https://github.com/matthuhiggins/foreigner > https://github.com/jenseng/immigrant > So it should be basically two gems, few lines of code and some testing. > > Your opinions? > > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > [2] http://www.rbt.ca/autodoc/ (available in Fedora as package) > > Mirek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Mon Jul 30 14:18:01 2012 From: msuchy at redhat.com (=?ISO-8859-2?Q?Miroslav_Such=FD?=) Date: Mon, 30 Jul 2012 16:18:01 +0200 Subject: [katello-devel] Git branching tomorrow morning Message-ID: <50169799.1000907@redhat.com> Although lzap originally volunteer to be release nanny of 1.0, he handed over it to me. My first email as nanny: If you want something in Katello 1.0, please commit it today. Tomorrow morning I plane to create new branch. And into new branch I will accept only high priorities fixes. -- Miroslav Suchy Red Hat Systems Management Engineering From mmccune at redhat.com Mon Jul 30 14:39:31 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 30 Jul 2012 07:39:31 -0700 Subject: [katello-devel] Git branching tomorrow morning In-Reply-To: <50169799.1000907@redhat.com> References: <50169799.1000907@redhat.com> Message-ID: <50169CA3.90808@redhat.com> On 07/30/2012 07:18 AM, Miroslav Such? wrote: > Although lzap originally volunteer to be release nanny of 1.0, he handed > over it to me. My first email as nanny: > > If you want something in Katello 1.0, please commit it today. > Tomorrow morning I plane to create new branch. And into new branch I > will accept only high priorities fixes. can you wait until Wednesday? I'd like to get Content Deletion finished to the point where it is usable for the community. It would really help complete a 1.0 feature set. If not we can cherry-pick it into 1.0 when we are done but would be easier if we could get this feature finished in master Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From lzap at redhat.com Mon Jul 30 15:17:14 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 30 Jul 2012 17:17:14 +0200 Subject: [katello-devel] "Interesting" log messages when starting katello In-Reply-To: <1465366460.4043862.1343410720973.JavaMail.root@redhat.com> References: <105731381.4043707.1343410642268.JavaMail.root@redhat.com> <1465366460.4043862.1343410720973.JavaMail.root@redhat.com> Message-ID: <20120730151714.GO5373@lzapx.brq.redhat.com> Og, a commit (6925bb23) broke permissions of /var/log/katello. I have fixed this on your host and pushed a fix: https://github.com/Katello/katello/pull/396 Once this is in master, after yum update the directory perms should be fixed. LZ On Fri, Jul 27, 2012 at 01:38:40PM -0400, Og Maciel wrote: > Hmmm... does anyone know what this is supposed to mean? Seen when running katello-service start > > INFO: [The Night Man] new_master [The Night Man][vuUOJdYVTXSm3Oo3c3V2LQ][inet[localhost/127.0.0.1:9300]], reason: zen-disco-join (elected_as_master) > > Full blown output > > # katello-service start > Starting Katello services... > Starting tomcat6: [ OK ] > Waiting for tomcat to be ready ... > Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using for ServerName > [ OK ] > Starting mongod: [ OK ] > Starting Qpid AMQP daemon: [ OK ] > Starting httpd: > Starting elasticsearch: [ OK ] > Starting katello: Jul 27, 2012 1:10:40 PM node > INFO: [Crossfire] {0.18.4}[19778]: initializing ... > Jul 27, 2012 1:10:40 PM plugins > INFO: [Crossfire] loaded [], sites [] > Starting server on 0.0.0.0:5000 ... > Starting server on 0.0.0.0:5001 ... > Starting server on 0.0.0.0:5002 ... > Starting server on 0.0.0.0:5003 ... > Jul 27, 2012 1:10:42 PM node > INFO: [Crossfire] {0.18.4}[19778]: initialized > Jul 27, 2012 1:10:42 PM node > INFO: [Crossfire] {0.18.4}[19778]: starting ... > Starting server on 0.0.0.0:5004 ... > Jul 27, 2012 1:10:42 PM transport > INFO: [Crossfire] bound_address {inet[/127.0.0.1:9300]}, publish_address {inet[localhost/127.0.0.1:9300]} > [ OK ] > Starting katello-jobs: bash: /var/log/katello/jobs-startup.log: Permission denied > [FAILED] > Done. > [root at qetello02 ~]# Jul 27, 2012 1:10:46 PM cluster.service > INFO: [Crossfire] new_master [Crossfire][yI-3uxg4S8iq3EjGtHGwUQ][inet[localhost/127.0.0.1:9300]], reason: zen-disco-join (elected_as_master) > Jul 27, 2012 1:10:46 PM discovery > INFO: [Crossfire] elasticsearch/yI-3uxg4S8iq3EjGtHGwUQ > Jul 27, 2012 1:10:46 PM http > INFO: [Crossfire] bound_address {inet[/127.0.0.1:9200]}, publish_address {inet[localhost/127.0.0.1:9200]} > Jul 27, 2012 1:10:46 PM node > INFO: [Crossfire] {0.18.4}[19778]: started > > -- > Og Maciel > > Senior QA Engineer > Red Hat, Inc. > +1.919.754.4782 > irc: omaciel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From omaciel at redhat.com Mon Jul 30 15:25:31 2012 From: omaciel at redhat.com (Og Maciel) Date: Mon, 30 Jul 2012 11:25:31 -0400 (EDT) Subject: [katello-devel] "Interesting" log messages when starting katello In-Reply-To: <20120730151714.GO5373@lzapx.brq.redhat.com> Message-ID: <1050083777.4874939.1343661931555.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Monday, July 30, 2012 11:17:14 AM > Subject: Re: [katello-devel] "Interesting" log messages when starting katello > > Og, > > a commit (6925bb23) broke permissions of /var/log/katello. I have > fixed > this on your host and pushed a fix: > > https://github.com/Katello/katello/pull/396 Thank you! :) -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From jrist at redhat.com Mon Jul 30 15:54:00 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 30 Jul 2012 09:54:00 -0600 Subject: [katello-devel] Fedora 17 Stuff So Far Message-ID: <5016AE18.1060504@redhat.com> https://fedorahosted.org/katello/wiki/f17_research -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jsherril at redhat.com Mon Jul 30 20:02:11 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 30 Jul 2012 16:02:11 -0400 Subject: [katello-devel] Content search shared/unique terminology Message-ID: <5016E843.2060508@redhat.com> In the demo today it was brought up how poor the unique/shared terminology was within content search and how we needed a tipsy tooltip to better explain it, only with better naming. Corey brought up using union and difference instead of unique and shared which i like a lot. Thoughts? I've added the following tipsy in the meantime (please ignore the haml): =_('All:') = _("Show all results regardless of which columns they exist in.") =_('Shared:') = _("Show only results that exist in all selected columns.") =_('Unique:') = _("Show only results not existing in all selected columns.") -Justin From jrist at redhat.com Mon Jul 30 20:16:29 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 30 Jul 2012 14:16:29 -0600 Subject: [katello-devel] Content search shared/unique terminology In-Reply-To: <5016E843.2060508@redhat.com> References: <5016E843.2060508@redhat.com> Message-ID: <5016EB9D.9050602@redhat.com> On 07/30/2012 02:02 PM, Justin Sherrill wrote: > In the demo today it was brought up how poor the unique/shared > terminology was within content search and how we needed a tipsy tooltip > to better explain it, only with better naming. > > Corey brought up using union and difference instead of unique and shared > which i like a lot. Thoughts? > > > I've added the following tipsy in the meantime (please ignore the haml): > > =_('All:') > = _("Show all results regardless of which columns they exist in.") > =_('Shared:') > = _("Show only results that exist in all selected columns.") > =_('Unique:') > = _("Show only results not existing in all selected columns.") > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I tend to agree with Corey. Union and Intersection (or difference?) are "normal" or accepted means of understanding. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From msuchy at redhat.com Tue Jul 31 07:21:30 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Tue, 31 Jul 2012 09:21:30 +0200 Subject: [katello-devel] Fedora 17 Stuff So Far In-Reply-To: <5016AE18.1060504@redhat.com> References: <5016AE18.1060504@redhat.com> Message-ID: <5017877A.4060703@redhat.com> On 07/30/2012 05:54 PM, Jason Rist wrote: > https://fedorahosted.org/katello/wiki/f17_research > > -J See comments inline: > The above requires you to add the two separate repos as deps: > > http://repos.fedorapeople.org/repos/pulp/pulp/v1/stable/fedora-17/x86_64/ > > http://repos.fedorapeople.org/repos/candlepin/candlepin/fedora-16/x86_64/ Any reason why you are not using: http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/Fedora/17/ http://fedorapeople.org/groups/katello/releases/yum/katello-pulp/Fedora/17/ ? > if RUBY_VERSION < "1.9" > when nil: total_mem *= (1<<0) > when 'kB': total_mem *= (1<<10) > when 'MB': total_mem *= (1<<20) > when 'GB': total_mem *= (1<<30) > when 'TB': total_mem *= (1<<40) > else > when nil then total_mem *= (1<<0) > when 'kB' then total_mem *= (1<<10) > when 'MB' then total_mem *= (1<<20) > when 'GB' then total_mem *= (1<<30) > when 'TB' then total_mem *= (1<<40) > end Why this when: when nil then total_mem *= (1<<0) works in ruby-1.8 as well? > err: /Stage[main]/Apache2/Exec[reload-apache2]: Failed to call refresh: Could not find command '/etc/init.d/httpd' We have even in code: modules/certs/templates/rhsm-katello-reconfigure.erb: /etc/init.d/goferd restart >/dev/null 2&>1 You should never call /etc/init.d/foo directly. Always service foo start/stop/restart Command service ensure you have correct environment and set cwd to /. And works with both systemV and systemD. -- Miroslav Suchy Red Hat Systems Management Engineering From msuchy at redhat.com Tue Jul 31 07:52:46 2012 From: msuchy at redhat.com (=?ISO-8859-2?Q?Miroslav_Such=FD?=) Date: Tue, 31 Jul 2012 09:52:46 +0200 Subject: [katello-devel] Katello 1.0 branched Message-ID: <50178ECE.5050606@redhat.com> I just branched current master to origin/KATELLO-1.0 Please ping me, if you want to commit there something - I will accept only fixes, which prevent Katello installation or fixes for ISE. -- Miroslav Suchy Red Hat Systems Management Engineering From msuchy at redhat.com Tue Jul 31 08:46:48 2012 From: msuchy at redhat.com (=?ISO-8859-2?Q?Miroslav_Such=FD?=) Date: Tue, 31 Jul 2012 10:46:48 +0200 Subject: [katello-devel] Katello 1.0 highlights Message-ID: <50179B78.8060703@redhat.com> If you worked on some interesting feature of Katello 1.0, please send it to me (off-list) and I will put it into release notes. -- Miroslav Suchy Red Hat Systems Management Engineering From hbrock at redhat.com Tue Jul 31 12:29:45 2012 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 31 Jul 2012 08:29:45 -0400 Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <5016372C.9030400@redhat.com> References: <180480390.4847557.1343632689016.JavaMail.root@redhat.com> <5016372C.9030400@redhat.com> Message-ID: <20120731122945.GB15724@redhat.com> On Mon, Jul 30, 2012 at 10:26:36AM +0300, Ohad Levy wrote: > On 07/30/2012 10:18 AM, Ivan Necas wrote: > > > >----- Ohad Levy wrote: > >>On 07/30/2012 10:02 AM, Ivan Necas wrote: > >>> > >>>Maybe the user preparing the puppet manifests should decide what to run when. That's what I do, when preparing reusable system images fo myself: having separated classes for preparing the image (e.g packages installation) and classes needed in run-time (configuration itself). No matter if I use stages or tag or other way to do that, at the end it's one class (or set if classes) to run on the template system and another classes for run-time. > >> > >>I don't think users would like to write their manifests twice (and test). > >I'm not writng nanifests twice. Just selecting classes that are save to run on the template system. > > so assuming you had a puppet structure that has module-package class > style i guess you could pull it off, but it needs to make > assumptions on the manifest (e.g. written in a certain way) and that > there are no references within the puppet code to other non included > resources. > > you are right that's its possible, but we would expecting our users > to build it in a certain way, and if they include the wrong classes > there might be unexpected results. > > Also, do you assume this works in a masterless mode? (e.g you would > need to distribute the manifests to the image + ensure that the > manifests can work without a master). > > and more than that, we would probably need a cleanup script to be > executed on the instance regardless. I can tell you with 100% certainty that we have users right now who want to operate in this way (doing a lot of work in the image build environment rather than post-boot). I'm not claiming it is a *good* way to operate, or that we should encourage people to do it, but I think we have no choice but to support it at least to a degree. I do agree with Bryan that we should prioritize the thin-JEOS fat-post-boot case wherever possible. Take care, --Hugh > >> > >>> > >>>So enabling the users to make this decision of selecting classes for build or run time would bring him the possibility to optimize their processes the way they like. > >> > >>I'm all for customization and ease of use, but if you remember the the > >>only thing that really saves time is downloading and installing system > >>binaries, then what we really need to care about is packages. > >> > >>we already have a way to let the user execute something when building > >>the image, so i think of all that customization is already covered? > > > >What way do you have in mind? > > we did discuss several times to reuse foreman templates as an post > image / post first boot template engine processor, so it would be > done in the exact same way like its done for bare metal/ vms. > > we also need to figure out how to deploy the initial certificates. > (e.g. if we allow the instances to reach out or are we 'pushing' the > certs to them etc). > in foreman for vm/bare metals we let the hit a url (with a uuid) and > for ec2 / openstack we simply ssh into the instances. > > Ohad > > > >-- Ivan > >> > >>> > >>> > >>>-- Ivan > >>> > >>>----- Original Message ----- > >>>From: Ohad Levy > >>>To: Ivan Ne?as > >>>Cc: Ian McLeod , aeolus-devel at fedorahosted.org, katello-devel at redhat.com > >>>Sent: Sun, 29 Jul 2012 03:17:08 -0400 (EDT) > >>>Subject: Re: [katello-devel] Improving Aeolus + Katello integration > >>> > >>>On 07/27/2012 08:48 AM, Ivan Ne?as wrote: > >>>>If prepared properly, puppet manifests can be applied even without the > >>>>master present. Especially, if the user that prepares the manifests > >>>>counts on the fact, that it could be run without master (which is not so > >>>>hard to test), he could then benefit significantly from this. He > >>>>probably still might want to rerun it on instance creation time, but > >>>>it's much faster then running against a JEOS. > >>> > >>>True, but you really want to make sure that all services are stopped > >>>afterwards, until firstoboot would activate/reconfigure them again. > >>> > >>>so the bottom line, > >>> > >>>creating a new custom image vs using JEOS is an optimization step (less > >>>time to get a new customized instance to run) due to the fact that you > >>>upload the content upfront, it should potentially also save some disk > >>>space (if you would be using snapshots). > >>> > >>>saying that, you must make sure that you have nothing specific from the > >>>image creation time, such as services running etc, so in reality, you > >>>just want the packages, nothing else. > >>> > >>>I would think that using puppet for creating the image is a good idea, > >>>but might not fit exactly to how puppet works, and you could consider > >>>adding tags [1] or run stages[2] or simply send a patch to puppet to > >>>auto tag packages and then you could ask puppet to install only packages. > >>> > >>> > >>> > >>>Ohad > >>> > >>>[1] http://projects.puppetlabs.com/projects/1/wiki/Using_Tags > >>>[2] http://docs.puppetlabs.com/guides/language_guide.html > >>> > >>> > >> > > > > > >_______________________________________________ > >katello-devel mailing list > >katello-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From jrist at redhat.com Tue Jul 31 13:09:28 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 31 Jul 2012 07:09:28 -0600 Subject: [katello-devel] Fedora 17 Stuff So Far In-Reply-To: <5017877A.4060703@redhat.com> References: <5016AE18.1060504@redhat.com> <5017877A.4060703@redhat.com> Message-ID: <5017D908.6050407@redhat.com> On 07/31/2012 01:21 AM, Miroslav Such? wrote: > On 07/30/2012 05:54 PM, Jason Rist wrote: >> https://fedorahosted.org/katello/wiki/f17_research >> >> -J > > See comments inline: > >> The above requires you to add the two separate repos as deps: >> >> http://repos.fedorapeople.org/repos/pulp/pulp/v1/stable/fedora-17/x86_64/ >> >> http://repos.fedorapeople.org/repos/candlepin/candlepin/fedora-16/x86_64/ > > > > Any reason why you are not using: > http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/Fedora/17/ > > http://fedorapeople.org/groups/katello/releases/yum/katello-pulp/Fedora/17/ > ? As I mentioned in the demo, going to switch to that, but haven't updated the wiki to reflect it. > > >> if RUBY_VERSION < "1.9" >> when nil: total_mem *= (1<<0) >> when 'kB': total_mem *= (1<<10) >> when 'MB': total_mem *= (1<<20) >> when 'GB': total_mem *= (1<<30) >> when 'TB': total_mem *= (1<<40) >> else >> when nil then total_mem *= (1<<0) >> when 'kB' then total_mem *= (1<<10) >> when 'MB' then total_mem *= (1<<20) >> when 'GB' then total_mem *= (1<<30) >> when 'TB' then total_mem *= (1<<40) >> end > > > Why this when: > when nil then total_mem *= (1<<0) > works in ruby-1.8 as well? Yeah, this was fixed in PR 395 by inecas > >> err: /Stage[main]/Apache2/Exec[reload-apache2]: Failed to call >> refresh: Could not find command '/etc/init.d/httpd' > > We have even in code: > modules/certs/templates/rhsm-katello-reconfigure.erb: /etc/init.d/goferd > restart >/dev/null 2&>1 > > You should never call /etc/init.d/foo directly. Always > service foo start/stop/restart > Command service ensure you have correct environment and set cwd to /. > And works with both systemV and systemD. > > Agreed! This has also been fixed by one of lzap's pushes. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jrist at redhat.com Tue Jul 31 13:20:42 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 31 Jul 2012 07:20:42 -0600 Subject: [katello-devel] Katello 1.0 highlights In-Reply-To: <50179B78.8060703@redhat.com> References: <50179B78.8060703@redhat.com> Message-ID: <5017DBAA.7050007@redhat.com> On Tue 31 Jul 2012 02:46:48 AM MDT, Miroslav Such? wrote: > If you worked on some interesting feature of Katello 1.0, > please send it to me (off-list) and I will put it into release notes. Would it be worth just detailing everything? This is the "initial" release... -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From msuchy at redhat.com Tue Jul 31 13:26:27 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Tue, 31 Jul 2012 15:26:27 +0200 Subject: [katello-devel] Katello 1.0 highlights In-Reply-To: <5017DBAA.7050007@redhat.com> References: <50179B78.8060703@redhat.com> <5017DBAA.7050007@redhat.com> Message-ID: <5017DD03.7010504@redhat.com> On 31.7.2012 15:20, Jason Rist wrote: > Would it be worth just detailing everything? This is the "initial" > release... So what is everything? I could not enumerate it. Can you help me? :) Mirek From jason.dobies at redhat.com Tue Jul 31 13:36:25 2012 From: jason.dobies at redhat.com (Jay Dobies) Date: Tue, 31 Jul 2012 09:36:25 -0400 Subject: [katello-devel] Katello 1.0 highlights In-Reply-To: <5017DD03.7010504@redhat.com> References: <50179B78.8060703@redhat.com> <5017DBAA.7050007@redhat.com> <5017DD03.7010504@redhat.com> Message-ID: <5017DF59.4000703@redhat.com> On 07/31/2012 09:26 AM, Miroslav Suchy wrote: > On 31.7.2012 15:20, Jason Rist wrote: >> Would it be worth just detailing everything? This is the "initial" >> release... > > So what is everything? I could not enumerate it. Can you help me? :) With the scope of this release, I'd start with the very high level features and then rely on individual articles (can be published after the fact) digging into features. IMO, take the approach that you're appealing to people who don't have the first clue what Katello is, so give them a reason to install it. I also think it's very important to have at least one quick start guide. A feature list is very nice, but sitting down with something the scale of Katello it's hard to know where to start. Giving people a guide that says "Now get some content, now register a system..." gives them a simple path towards a working system that they can then experiment. -- Jay Dobies Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org From bkearney at redhat.com Tue Jul 31 13:37:24 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 31 Jul 2012 09:37:24 -0400 Subject: [katello-devel] Katello 1.0 highlights In-Reply-To: <5017DD03.7010504@redhat.com> References: <50179B78.8060703@redhat.com> <5017DBAA.7050007@redhat.com> <5017DD03.7010504@redhat.com> Message-ID: <5017DF94.9040708@redhat.com> On 07/31/2012 09:26 AM, Miroslav Suchy wrote: > On 31.7.2012 15:20, Jason Rist wrote: >> Would it be worth just detailing everything? This is the "initial" >> release... > > So what is everything? I could not enumerate it. Can you help me? :) Quick Summary: Patch Management -- Mirror content from external repositories into local Definitive Software Library -- Schedule recurring syncs of content -- Manage the content through multiple environments -- Use subscription model to associate content with machines which are registered to environments. System Management -- Inventory of systems which are registered, including installed software and system facts. -- Assign subscriptions provided by Red Hat, and customer products. -- Registration Macros with Activation Keys -- Remote installation of packages over AMQP -- System Grouping for Batch Processing General -- LDAP integration. -- Python based CLI. -- REST API -- bk From jlabocki at redhat.com Tue Jul 31 13:39:07 2012 From: jlabocki at redhat.com (James Labocki) Date: Tue, 31 Jul 2012 09:39:07 -0400 (EDT) Subject: [katello-devel] Improving Aeolus + Katello integration In-Reply-To: <20120731122945.GB15724@redhat.com> Message-ID: <270869977.22390782.1343741947841.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Hugh Brock" > To: "Ohad Levy" > Cc: aeolus-devel at fedorahosted.org, katello-devel at redhat.com > Sent: Tuesday, July 31, 2012 8:29:45 AM > Subject: Re: [katello-devel] Improving Aeolus + Katello integration > > On Mon, Jul 30, 2012 at 10:26:36AM +0300, Ohad Levy wrote: > > On 07/30/2012 10:18 AM, Ivan Necas wrote: > > > > > >----- Ohad Levy wrote: > > >>On 07/30/2012 10:02 AM, Ivan Necas wrote: > > >>> > > >>>Maybe the user preparing the puppet manifests should decide what > > >>>to run when. That's what I do, when preparing reusable system > > >>>images fo myself: having separated classes for preparing the > > >>>image (e.g packages installation) and classes needed in > > >>>run-time (configuration itself). No matter if I use stages or > > >>>tag or other way to do that, at the end it's one class (or set > > >>>if classes) to run on the template system and another classes > > >>>for run-time. > > >> > > >>I don't think users would like to write their manifests twice > > >>(and test). > > >I'm not writng nanifests twice. Just selecting classes that are > > >save to run on the template system. > > > > so assuming you had a puppet structure that has module-package > > class > > style i guess you could pull it off, but it needs to make > > assumptions on the manifest (e.g. written in a certain way) and > > that > > there are no references within the puppet code to other non > > included > > resources. > > > > you are right that's its possible, but we would expecting our users > > to build it in a certain way, and if they include the wrong classes > > there might be unexpected results. > > > > Also, do you assume this works in a masterless mode? (e.g you would > > need to distribute the manifests to the image + ensure that the > > manifests can work without a master). > > > > and more than that, we would probably need a cleanup script to be > > executed on the instance regardless. > > I can tell you with 100% certainty that we have users right now who > want to operate in this way (doing a lot of work in the image build > environment rather than post-boot). I'm not claiming it is a *good* > way to operate, or that we should encourage people to do it, but I > think we have no choice but to support it at least to a degree. > > I do agree with Bryan that we should prioritize the thin-JEOS > fat-post-boot case wherever possible. Not that we would position Aeolus without Katello on the product side (CloudForms), but if we had customers running their own systems management facility (HP, BMC, IBM, Home Grown Puppet) that wanted to use Aeolus for self-service and image building then having some fancy image management features in aeolus would be important. > > Take care, > --Hugh > > > >> > > >>> > > >>>So enabling the users to make this decision of selecting classes > > >>>for build or run time would bring him the possibility to > > >>>optimize their processes the way they like. > > >> > > >>I'm all for customization and ease of use, but if you remember > > >>the the > > >>only thing that really saves time is downloading and installing > > >>system > > >>binaries, then what we really need to care about is packages. > > >> > > >>we already have a way to let the user execute something when > > >>building > > >>the image, so i think of all that customization is already > > >>covered? > > > > > >What way do you have in mind? > > > > we did discuss several times to reuse foreman templates as an post > > image / post first boot template engine processor, so it would be > > done in the exact same way like its done for bare metal/ vms. > > > > we also need to figure out how to deploy the initial certificates. > > (e.g. if we allow the instances to reach out or are we 'pushing' > > the > > certs to them etc). > > in foreman for vm/bare metals we let the hit a url (with a uuid) > > and > > for ec2 / openstack we simply ssh into the instances. > > > > Ohad > > > > > >-- Ivan > > >> > > >>> > > >>> > > >>>-- Ivan > > >>> > > >>>----- Original Message ----- > > >>>From: Ohad Levy > > >>>To: Ivan Ne?as > > >>>Cc: Ian McLeod , > > >>>aeolus-devel at fedorahosted.org, katello-devel at redhat.com > > >>>Sent: Sun, 29 Jul 2012 03:17:08 -0400 (EDT) > > >>>Subject: Re: [katello-devel] Improving Aeolus + Katello > > >>>integration > > >>> > > >>>On 07/27/2012 08:48 AM, Ivan Ne?as wrote: > > >>>>If prepared properly, puppet manifests can be applied even > > >>>>without the > > >>>>master present. Especially, if the user that prepares the > > >>>>manifests > > >>>>counts on the fact, that it could be run without master (which > > >>>>is not so > > >>>>hard to test), he could then benefit significantly from this. > > >>>>He > > >>>>probably still might want to rerun it on instance creation > > >>>>time, but > > >>>>it's much faster then running against a JEOS. > > >>> > > >>>True, but you really want to make sure that all services are > > >>>stopped > > >>>afterwards, until firstoboot would activate/reconfigure them > > >>>again. > > >>> > > >>>so the bottom line, > > >>> > > >>>creating a new custom image vs using JEOS is an optimization > > >>>step (less > > >>>time to get a new customized instance to run) due to the fact > > >>>that you > > >>>upload the content upfront, it should potentially also save some > > >>>disk > > >>>space (if you would be using snapshots). > > >>> > > >>>saying that, you must make sure that you have nothing specific > > >>>from the > > >>>image creation time, such as services running etc, so in > > >>>reality, you > > >>>just want the packages, nothing else. > > >>> > > >>>I would think that using puppet for creating the image is a good > > >>>idea, > > >>>but might not fit exactly to how puppet works, and you could > > >>>consider > > >>>adding tags [1] or run stages[2] or simply send a patch to > > >>>puppet to > > >>>auto tag packages and then you could ask puppet to install only > > >>>packages. > > >>> > > >>> > > >>> > > >>>Ohad > > >>> > > >>>[1] http://projects.puppetlabs.com/projects/1/wiki/Using_Tags > > >>>[2] http://docs.puppetlabs.com/guides/language_guide.html > > >>> > > >>> > > >> > > > > > > > > >_______________________________________________ > > >katello-devel mailing list > > >katello-devel at redhat.com > > >https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -- > == Hugh Brock, hbrock at redhat.com == > == Engineering Manager, Cloud BU == > == Aeolus Project: Manage virtual infrastructure across clouds. == > == http://aeolusproject.org == > > "I know that you believe you understand what you think I said, but > I?m > not sure you realize that what you heard is not what I meant." > --Robert McCloskey > From ehelms at redhat.com Tue Jul 31 15:42:42 2012 From: ehelms at redhat.com (Eric Helms) Date: Tue, 31 Jul 2012 11:42:42 -0400 Subject: [katello-devel] Katello 1.0 branched In-Reply-To: <50178ECE.5050606@redhat.com> References: <50178ECE.5050606@redhat.com> Message-ID: <5017FCF2.4070007@redhat.com> On 07/31/2012 03:52 AM, Miroslav Such? wrote: > I just branched current master to > origin/KATELLO-1.0 > Please ping me, if you want to commit there something - I will accept > only fixes, which prevent Katello installation or fixes for ISE. With the end of two sprints occurring yesterday and today, there may be a couple of sets of fixes that would be important but not meet your criteria above sitting in or hitting pull requests today. One for example is a number of Content Search related fixes that make viewing and interacting with the results much easier and are part of the feature complete set of items for Content Search. Can we ensure these get included prior to community release? Thanks! Eric From thomasmckay at redhat.com Tue Jul 31 16:16:02 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 31 Jul 2012 12:16:02 -0400 (EDT) Subject: [katello-devel] deleting an imported manifest In-Reply-To: <1685582316.22850593.1343751256975.JavaMail.root@redhat.com> Message-ID: <395167807.22856808.1343751362095.JavaMail.root@redhat.com> Candlepin is supports the deletion of an imported manifest from an org. This, I believe, is an important feature to support in katello as well. Does it make sense to include this ability as part of the "content deletion" work? I don't know the implications surrounding this as it relates to pulp and content. From bkearney at redhat.com Tue Jul 31 17:08:41 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 31 Jul 2012 13:08:41 -0400 Subject: [katello-devel] Need a pull request reviewed Message-ID: <50181119.6080306@redhat.com> If someone from NULL could review please: https://github.com/Katello/katello/pull/176 -- bk From thomasmckay at redhat.com Tue Jul 31 17:24:24 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 31 Jul 2012 13:24:24 -0400 (EDT) Subject: [katello-devel] headpin vs. katello In-Reply-To: <350052817.23018016.1343755260657.JavaMail.root@redhat.com> Message-ID: <929922042.23021237.1343755464126.JavaMail.root@redhat.com> Tazim (and others interested in headpin only installs), While we figure out how best to provide a community headpin install in relation to katello, I will suggest that if you want to "check out" the latest greatest features in headpin, that you install katello and then katello-configure it to headpin. This will not be a fully functional headpin install (eg. the 'katello' executable is used for command line), but it will show you the latest code. Over the next couple weeks we (myself, Jordan, and Adam) will be working on making headpin fully available in nightly, weekly, and release builds. Thanks! Tom From msuchy at redhat.com Tue Jul 31 18:37:29 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Tue, 31 Jul 2012 20:37:29 +0200 Subject: [katello-devel] Katello 1.0 branched In-Reply-To: <5017FCF2.4070007@redhat.com> References: <50178ECE.5050606@redhat.com> <5017FCF2.4070007@redhat.com> Message-ID: <501825E9.7080304@redhat.com> On 31.7.2012 17:42, Eric Helms wrote: > With the end of two sprints occurring yesterday and today, there may be > a couple of sets of fixes that would be important but not meet your > criteria above sitting in or hitting pull requests today. One for > example is a number of Content Search related fixes that make viewing > and interacting with the results much easier and are part of the feature > complete set of items for Content Search. Can we ensure these get > included prior to community release? There will be always something we would like to add. I'm afraid we have to make somewhere the cut. I wanted to release it today, but had problem with rpm signing. So if you will make it before it will be released (and date is still floating), I can take a look and we can discuss it on irc. Mirek