From msuchy at redhat.com Mon Oct 1 06:01:26 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 01 Oct 2012 08:01:26 +0200 Subject: [katello-devel] RFC: Strategy for Importing Data from Spacewalk In-Reply-To: <5065FDF9.2080505@redhat.com> References: <2104825489.2747427.1348851564566.JavaMail.root@redhat.com> <5065D905.2010608@redhat.com> <20120928175415.GG10053@redhat.com> <5065FDF9.2080505@redhat.com> Message-ID: <506931B6.5000400@redhat.com> On 09/28/2012 09:43 PM, Mike McCune wrote: > that aside, +1 to a textual based format. I'm not sure about this. Spacewalk DB can be really big. Text export can inflate it several times. I would much rather operate directly on PostgreSQL db - or export of PostgreSQL db. This will solve all the encoding stuff, will save us disk space, and it will be faster. -- Miroslav Suchy Red Hat Systems Management Engineering From pchalupa at redhat.com Mon Oct 1 09:18:38 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Mon, 01 Oct 2012 11:18:38 +0200 Subject: [katello-devel] ActiveResource spike In-Reply-To: <506456B0.9070900@redhat.com> References: <5062CD69.7040404@redhat.com> <5062F40B.6090103@redhat.com> <50632011.2010209@redhat.com> <506456B0.9070900@redhat.com> Message-ID: <50695FEE.9070900@redhat.com> Hi, sorry I didn't read the email until now. I am working on merging foreman_architectures into master. Remaining tasks before merging: 1. merge work on foreman api documentation 2. generate new version of foreman_api gem 3. fix rake db:seed in katello (almost done) (it does not work with foreman orchestration enabled) 4. add migration which creates missing users in foreman 5. recover when user is missing in foreman by creating the missing user There are no stories or bugzillas for these tasks. 3. was discovered after the current stories were done. 4. and 5. came up this morning from discussion with Ivan about foreman configuration which he is currently working on. There is no story for merging foreman_architectures and "Make the pulp/candlepin/foreman code all look alike". So I've added 4 new stories: in Iteration 006 - US1399 - the merge story in Backlog - US1400 - the "Make the pulp/candlepin/foreman code all look alike" - US1401 - As a developer, I would like to have same set of error classes in ForemanModel as in ActiveResource - US1402 - As a developer, I would like foreman_api code to be DRY Petr On 27.09.12 15:37, Bryan Kearney wrote: > On 09/26/2012 11:32 AM, Dmitri Dolguikh wrote: >> On 26/09/12 01:24 PM, Bryan Kearney wrote: >>> On 09/26/2012 05:39 AM, Dmitri Dolguikh wrote: >>>> It seems that the majority of those who voiced their opinion would >>>> prefer to go with custom approach instead of spending time on >>>> ActiveResource. >>>> >>>> Let's go with that. >>> >>> What does this mean for backlog / sprint tasks? My goal is to get the >>> foreman branch into master. Is there any "Make hte >>> pulp/candlepin/foreman code all look alike" tasks as part of this? >> >> It's been a while since I worked with that branch, one of the folks >> involved should chime in... > > > fair enouhg... anyone? > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Mon Oct 1 12:46:21 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 01 Oct 2012 08:46:21 -0400 Subject: [katello-devel] RFC: Strategy for Importing Data from Spacewalk In-Reply-To: <5065FDF9.2080505@redhat.com> References: <2104825489.2747427.1348851564566.JavaMail.root@redhat.com> <5065D905.2010608@redhat.com> <20120928175415.GG10053@redhat.com> <5065FDF9.2080505@redhat.com> Message-ID: <5069909D.2020707@redhat.com> On 09/28/2012 03:43 PM, Mike McCune wrote: > On 09/28/2012 10:54 AM, Hugh Brock wrote: >> On Fri, Sep 28, 2012 at 01:06:13PM -0400, Bryan Kearney wrote: >>> On 09/28/2012 12:59 PM, James Labocki wrote: >>>> Comments inline >>>> >>>> ----- Original Message ----- >>>>> From: "Bryan Kearney" >>>>> To: katello-devel at redhat.com, "James Labocki", >>>>> ejacobs at redhat.com >>>>> Sent: Friday, September 28, 2012 12:42:06 PM >>>>> Subject: RFC: Strategy for Importing Data from Spacewalk >>>>> >>>>> All: >>>>> >>>>> I am looking for comments on an approach for migrating data from >>>>> spacewalk into katello. The model I was looking at is one set of >>>>> scripts >>>>> [1] which can export data from a spacewalk server and create a set of >>>>> flat files. These flat files could then be loaded into katello using >>>>> new >>>>> import commands [2] in the cli. My thinking was that the import >>>>> commands >>>>> could be re-used for any other initial set up work which may not be >>>>> from >>>>> an existing spacewalk server. >>>> >>>> Are there any examples of other systems management tools that create >>>> flat files for backing up or migrating configuration and data? If >>>> there are and we could align enough with them to be able to support >>>> them then this approach could provide value beyond just migrating >>>> Satellite to Katello (Opsware to Katello, OEM to Katello, etc). I >>>> doubt there is a standard way that exists, but might be worth >>>> thinking about it. >>> >>> I dont know, I can look around. >>> >>>> >>>>> >>>>> What is working today is the following; >>>>> >>>>> Export Scripts: >>>>> ------------------- >>>>> - Export orgs, users, activation keys, system groups. >>>>> - There are default credentials, or you can pass them in on the >>>>> command line >>>>> - The export can pass data to std out, or put it into a file. >>>> >>>> Is there anyway to go directly to Katello instead of creating the >>>> file? Are we doing this because we don't yet trust the export/import? >>> >>> We could. I liked the csv files for a couple of reasons: >>> >>> 1) If there was custom Transforms which needed to occur between >>> extract and loading, this allowed for it. >>> 2) The load could be run several times. >>> 3) The load is not connected to the export, so a user who is setting >>> up data could create csv files by some other means. >> >> If the data is hierarchical, I suppose there might be some merit in >> using JSON rather than CSV. But I like the flat file idea in general. >> >> --H >> > > for the love of all that is holy please lets use something other than > CSV. CSV is garbage when it comes to encoding, spaces, formatting, > hierarchy and all the other things we have support for in more modern > text transports (JSON, XML, YAML, etc..) > > that aside, +1 to a textual based format. > My thought was that folks may want to hand edit the files. But, I can easily move away from it. -- bk From bkearney at redhat.com Mon Oct 1 12:49:12 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 01 Oct 2012 08:49:12 -0400 Subject: [katello-devel] RFC: Strategy for Importing Data from Spacewalk In-Reply-To: <506931B6.5000400@redhat.com> References: <2104825489.2747427.1348851564566.JavaMail.root@redhat.com> <5065D905.2010608@redhat.com> <20120928175415.GG10053@redhat.com> <5065FDF9.2080505@redhat.com> <506931B6.5000400@redhat.com> Message-ID: <50699148.3040705@redhat.com> On 10/01/2012 02:01 AM, Miroslav Such? wrote: > On 09/28/2012 09:43 PM, Mike McCune wrote: >> that aside, +1 to a textual based format. > > I'm not sure about this. Spacewalk DB can be really big. Text export can > inflate it several times. > How much of the size is the package DB? > I would much rather operate directly on PostgreSQL db - or export of > PostgreSQL db. > > This will solve all the encoding stuff, will save us disk space, and it > will be faster. > But, we loose the generic tools to import. I would think for any bulk setup, or migration form other toolings this would be nice. -- bk From cperry at redhat.com Mon Oct 1 12:58:53 2012 From: cperry at redhat.com (Cliff Perry) Date: Mon, 01 Oct 2012 13:58:53 +0100 Subject: [katello-devel] RFC: Strategy for Importing Data from Spacewalk In-Reply-To: <5069909D.2020707@redhat.com> References: <2104825489.2747427.1348851564566.JavaMail.root@redhat.com> <5065D905.2010608@redhat.com> <20120928175415.GG10053@redhat.com> <5065FDF9.2080505@redhat.com> <5069909D.2020707@redhat.com> Message-ID: <5069938D.4070102@redhat.com> On 10/01/2012 01:46 PM, Bryan Kearney wrote: > On 09/28/2012 03:43 PM, Mike McCune wrote: >> On 09/28/2012 10:54 AM, Hugh Brock wrote: >>> On Fri, Sep 28, 2012 at 01:06:13PM -0400, Bryan Kearney wrote: >>>> On 09/28/2012 12:59 PM, James Labocki wrote: >>>>> Comments inline >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Bryan Kearney" >>>>>> To: katello-devel at redhat.com, "James Labocki", >>>>>> ejacobs at redhat.com >>>>>> Sent: Friday, September 28, 2012 12:42:06 PM >>>>>> Subject: RFC: Strategy for Importing Data from Spacewalk >>>>>> >>>>>> All: >>>>>> >>>>>> I am looking for comments on an approach for migrating data from >>>>>> spacewalk into katello. The model I was looking at is one set of >>>>>> scripts >>>>>> [1] which can export data from a spacewalk server and create a set of >>>>>> flat files. These flat files could then be loaded into katello using >>>>>> new >>>>>> import commands [2] in the cli. My thinking was that the import >>>>>> commands >>>>>> could be re-used for any other initial set up work which may not be >>>>>> from >>>>>> an existing spacewalk server. >>>>> >>>>> Are there any examples of other systems management tools that create >>>>> flat files for backing up or migrating configuration and data? If >>>>> there are and we could align enough with them to be able to support >>>>> them then this approach could provide value beyond just migrating >>>>> Satellite to Katello (Opsware to Katello, OEM to Katello, etc). I >>>>> doubt there is a standard way that exists, but might be worth >>>>> thinking about it. >>>> >>>> I dont know, I can look around. >>>> >>>>> >>>>>> >>>>>> What is working today is the following; >>>>>> >>>>>> Export Scripts: >>>>>> ------------------- >>>>>> - Export orgs, users, activation keys, system groups. >>>>>> - There are default credentials, or you can pass them in on the >>>>>> command line >>>>>> - The export can pass data to std out, or put it into a file. >>>>> >>>>> Is there anyway to go directly to Katello instead of creating the >>>>> file? Are we doing this because we don't yet trust the export/import? >>>> >>>> We could. I liked the csv files for a couple of reasons: >>>> >>>> 1) If there was custom Transforms which needed to occur between >>>> extract and loading, this allowed for it. >>>> 2) The load could be run several times. >>>> 3) The load is not connected to the export, so a user who is setting >>>> up data could create csv files by some other means. >>> >>> If the data is hierarchical, I suppose there might be some merit in >>> using JSON rather than CSV. But I like the flat file idea in general. >>> >>> --H >>> >> >> for the love of all that is holy please lets use something other than >> CSV. CSV is garbage when it comes to encoding, spaces, formatting, >> hierarchy and all the other things we have support for in more modern >> text transports (JSON, XML, YAML, etc..) >> >> that aside, +1 to a textual based format. >> > > My thought was that folks may want to hand edit the files. But, I can > easily move away from it. > Well, I do like the idea of the three step (maybe 2); 'export to file', [optional] mung files, read files and and write/call APIs to create new. A single step process removes the optional middle bit, but makes it easier for handling data. But I also see Mikes point about how good is csv at holding UTF8 data. Cliff > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From msuchy at redhat.com Mon Oct 1 13:04:22 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 01 Oct 2012 15:04:22 +0200 Subject: [katello-devel] RFC: Strategy for Importing Data from Spacewalk In-Reply-To: <50699148.3040705@redhat.com> References: <2104825489.2747427.1348851564566.JavaMail.root@redhat.com> <5065D905.2010608@redhat.com> <20120928175415.GG10053@redhat.com> <5065FDF9.2080505@redhat.com> <506931B6.5000400@redhat.com> <50699148.3040705@redhat.com> Message-ID: <506994D6.8020604@redhat.com> On 10/01/2012 02:49 PM, Bryan Kearney wrote: > On 10/01/2012 02:01 AM, Miroslav Such? wrote: >> On 09/28/2012 09:43 PM, Mike McCune wrote: >>> that aside, +1 to a textual based format. >> >> I'm not sure about this. Spacewalk DB can be really big. Text export can >> inflate it several times. >> > > How much of the size is the package DB? Taken from sputnik-prod.***: $ db-control tablesizes ... RHNPACKAGE 59M RHNPACKAGEARCH 128K RHNPACKAGECAPABILITY 2.3G RHNPACKAGECHANGELOGDATA 34M RHNPACKAGECHANGELOGREC 270M RHNPACKAGECONFLICTS 3M RHNPACKAGEDELTA 128K RHNPACKAGEDELTAELEMENT 128K RHNPACKAGEEVR 3M RHNPACKAGEFILE 3.1G RHNPACKAGEFILEDELETEQUEUE 192K RHNPACKAGEGROUP 128K RHNPACKAGEKEY 64K RHNPACKAGEKEYASSOCIATION 4M RHNPACKAGEKEYTYPE 64K RHNPACKAGENAME 768K RHNPACKAGENEVRA 5M RHNPACKAGEOBSOLETES 3M RHNPACKAGEPROVIDER 64K RHNPACKAGEPROVIDES 104M RHNPACKAGERECOMMENDS 64K RHNPACKAGEREPODATA 220.5M RHNPACKAGEREQUIRES 60M RHNPACKAGESOURCE 128K RHNPACKAGESUGGESTS 64K RHNPACKAGESUPPLEMENTS 64K RHNPACKAGESYNCBLACKLIST 128K RHNPACKAGEUPGRADEARCHCOMPAT 64K ... I'm lazy to cunt it precisly, but RHNPACKAGEFILE + RHNPACKAGECAPABILITY is already more then 5 GB. -- Miroslav Suchy Red Hat Systems Management Engineering From lzap at redhat.com Tue Oct 2 09:02:07 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 2 Oct 2012 11:02:07 +0200 Subject: [katello-devel] Pulp warning: Unsupported characters for Yum Message-ID: <20121002090207.GA4257@lzapx.brq.redhat.com> Hey, during pulp migration I can see this warning: ID for repositories [] contains characters which are not supported by Yum as a repository title in a '.repo' file. Because of this, you may see an error when installing a package from these repositories on a consumer. You can either manually update consumer's .repo file to update title, or delete and create a new repository that follows new ID restriction. Repository ID may now contain only numbers(0-9), upper and lower case letters(A-Z, a-z), hyphens(-), underscore(_) and periods(.) What is our strategy for CFSE here (particulary 1.0 to 1.1)? Should we make a doco bug? What is the recommended approach? Does subscription-manager takes care of it automatically? Just a couple of questions. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Oct 2 11:04:12 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 2 Oct 2012 13:04:12 +0200 Subject: [katello-devel] Foreman and - yeah - SELinux Message-ID: <20121002110412.GD4257@lzapx.brq.redhat.com> Guys, I have noticed we do not have any selinux policy for Foreman, but we start it in the confined mode. Therefore once we start with more integrations we will likely hit an issue - Foreman won't be able to do anything in confined mode :-) I am putting new item on the backlog: As a user, I'd like to have SELinux policy for Foreman I have also noticed there is now thin_d domain in both Fedoras and RHEL6. We run the main Katello process in the initrc_t domain which is nasty. Therefore I am crating another sprint task: As a dev, I'd like run katello process in its own domain Our current SELinux policies are quite permissive and they were created quickly, maybe it's the time to harden the stuff: As a dev, I'd like to harden Katello SELinux policy Now the question is if Foreman developers are able to deliver this feature for us, because from our experiences with SELinux it is always better when devs with experiences with the codebase are hardering the stuff. Otherwise we can only provide lower quality "get it only working" version, which is also usually not tested enough (guys are often running in to issues due to missing rules). LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Tue Oct 2 11:55:42 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 02 Oct 2012 07:55:42 -0400 Subject: [katello-devel] Foreman and - yeah - SELinux In-Reply-To: <20121002110412.GD4257@lzapx.brq.redhat.com> References: <20121002110412.GD4257@lzapx.brq.redhat.com> Message-ID: <506AD63E.5030100@redhat.com> On 10/02/2012 07:04 AM, Lukas Zapletal wrote: > Guys, > > I have noticed we do not have any selinux policy for Foreman, but we > start it in the confined mode. Therefore once we start with more > integrations we will likely hit an issue - Foreman won't be able to do > anything in confined mode :-) > > I am putting new item on the backlog: > > As a user, I'd like to have SELinux policy for Foreman > > I have also noticed there is now thin_d domain in both Fedoras and > RHEL6. We run the main Katello process in the initrc_t domain which is > nasty. Therefore I am crating another sprint task: > > As a dev, I'd like run katello process in its own domain > > Our current SELinux policies are quite permissive and they were created > quickly, maybe it's the time to harden the stuff: > > As a dev, I'd like to harden Katello SELinux policy > > Now the question is if Foreman developers are able to deliver this > feature for us, because from our experiences with SELinux it is always > better when devs with experiences with the codebase are hardering the > stuff. Otherwise we can only provide lower quality "get it only working" > version, which is also usually not tested enough (guys are often running > in to issues due to missing rules). > > LZ > Thanks... will prioritize these. -- bk From lzap at redhat.com Tue Oct 2 12:18:16 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 2 Oct 2012 14:18:16 +0200 Subject: [katello-devel] Funky fuzzy errors in the thin.log Message-ID: <20121002121816.GE4257@lzapx.brq.redhat.com> Hey, if you install nightly and open up /var/log/katello/thin-log.log or /var/log/katello/jobs-startup.log you will see lots of these i18n error messages there. Can we get rid of them too? They are flooding the logs. -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Tue Oct 2 12:26:02 2012 From: daviddavis at redhat.com (David Davis) Date: Tue, 2 Oct 2012 08:26:02 -0400 (EDT) Subject: [katello-devel] Funky fuzzy errors in the thin.log In-Reply-To: <20121002121816.GE4257@lzapx.brq.redhat.com> Message-ID: <762237883.5616379.1349180762043.JavaMail.root@redhat.com> +1. It's also flooding the jenkins logs. ----- Original Message ----- From: "Lukas Zapletal" To: katello-devel at redhat.com Sent: Tuesday, October 2, 2012 8:18:16 AM Subject: [katello-devel] Funky fuzzy errors in the thin.log Hey, if you install nightly and open up /var/log/katello/thin-log.log or /var/log/katello/jobs-startup.log you will see lots of these i18n error messages there. Can we get rid of them too? They are flooding the logs. -- Later, Lukas "lzap" Zapletal #katello #systemengine _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From jcoufal at redhat.com Tue Oct 2 12:34:40 2012 From: jcoufal at redhat.com (=?UTF-8?B?SmFyb23DrXIgQ291ZmFs?=) Date: Tue, 02 Oct 2012 14:34:40 +0200 Subject: [katello-devel] Quick developer guide for Forms Message-ID: <506ADF60.3070202@redhat.com> Hi all, I summarized features of Forms in short developer guide. Currently used our Wiki page, in further future it should be described in better way directly in Converge-UI library (I hope). https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Forms Best -- Jarda -- Jarom?r Coufal Interaction Designer Red Hat Czech s.r.o. Mobile: +420 724 595 508 E-mail: jcoufal at redhat.com IRC: jcoufal at #cloudforms-ui, #aeolus, #brno From lzap at redhat.com Tue Oct 2 13:02:06 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 2 Oct 2012 15:02:06 +0200 Subject: [katello-devel] Katello nightly does not work Message-ID: <20121002130206.GI4257@lzapx.brq.redhat.com> Hey, I have noticed (and Jeff confirmed me this) current nightly does not work. Apache (or Thin) does not respond, no other error reports than: # grep -iE '(^err|error|fatal|AVC)' /var/log/katello/katello-configure/*log /var/log/katello/*log /var/log/pulp/*log /var/log/tomcat6/catalina.out /var/log/audit/audit.log /var/log/httpd/*log /var/log/elasticsearch/ | grep -viE '(msgid|msgstr|resteasy)' /var/log/katello/client.log:2012-10-02 14:11:07,811 [ERROR][MainThread] error() @ base.py:206 - error: Service unavailable or restarting, try later /var/log/httpd/ssl_kt_error_log:[Tue Oct 02 14:11:07 2012] [error] proxy: BALANCER: (balancer://thinservers). All workers are in error state I thought it is SELinux, but it is not. Currently investigating the issue, please comment if you know something. Otherwise git blame will show it (I hope it's not me :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Tue Oct 2 13:12:16 2012 From: daviddavis at redhat.com (David Davis) Date: Tue, 2 Oct 2012 09:12:16 -0400 (EDT) Subject: [katello-devel] Fwd: Build failed in Jenkins: katello-unit #3379 In-Reply-To: <775504508.44.1349181433013.JavaMail.tomcat@hudson.rhq.lab.eng.bos.redhat.com> Message-ID: <927908301.5644984.1349183536766.JavaMail.root@redhat.com> So katello-unit is back up and running but in the mean time we've incurred some broken rspec tests. Anyone want to help me fix these? Thanks. David ----- Forwarded Message ----- From: LeeroyJenkins at redhat.com To: katello-internal at redhat.com, lzap+git at redhat.com, msuchy at redhat.com, pajkycz at gmail.com, pchalupa at redhat.com, daviddavis at redhat.com, bbuckingham at redhat.com, mmccune at redhat.com, mbacovsk at redhat.com, inecas at redhat.com, dmitri at redhat.com Sent: Tuesday, October 2, 2012 8:35:59 AM Subject: Build failed in Jenkins: katello-unit #3379 See ------------------------------------------ [...truncated 47504 lines...] # ./spec/controllers/systems_controller_spec.rb:742 systems/index.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/systems/index.html.haml_spec.rb:16 sync_management/index.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/sync_management/index.html.haml_spec.rb:16 content/index.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/content/index.html.haml_spec.rb:16 operations/index.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/operations/index.html.haml_spec.rb:16 dashboard/show.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/dashboard/show.html.haml_spec.rb:16 dashboard/index.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/dashboard/index.html.haml_spec.rb:16 HelpTip add some examples to (or delete) # Not Yet Implemented # ./spec/models/help_tip_spec.rb:16 System host-guest relation guest system # Not Yet Implemented # ./spec/models/system_spec.rb:335 System host-guest relation host system # Not Yet Implemented # ./spec/models/system_spec.rb:345 LdapGroupRole add some examples to (or delete) # Not Yet Implemented # ./spec/models/ldap_group_role_spec.rb:4 UsersHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/users_helper_spec.rb:26 DashboardHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/dashboard_helper_spec.rb:26 SyncManagementHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/sync_management_helper_spec.rb:26 SystemGroupsHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/system_groups_helper_spec.rb:16 FiltersHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/filters_helper_spec.rb:14 NodesHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/nodes_helper_spec.rb:26 ErrataHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/errata_helper_spec.rb:26 CustomInfoHelper add tests for CustomInfoHelper::consolidate() # Not Yet Implemented # ./spec/helpers/custom_info_helper_spec.rb:16 SyncSchedulesHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/sync_schedules_helper_spec.rb:14 EnvironmentsHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/environments_helper_spec.rb:26 OperationsHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/operations_helper_spec.rb:26 SyncPlansHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/sync_plans_helper_spec.rb:14 PuppetclassesHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/puppetclasses_helper_spec.rb:26 ContentHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/content_helper_spec.rb:26 PackagesHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/packages_helper_spec.rb:26 ContentSearchHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/content_search_helper_spec.rb:14 SystemsHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/systems_helper_spec.rb:26 Failures: 1) Api::ProductsController show all @products in an environment should find organization Failure/Error: get 'index', :organization_id => @organization.label received :first with unexpected arguments expected: ({:conditions=>{:label=>"test_organization1"}}) got: ({:conditions=>{:name=>"test_organization1"}}) # ./app/controllers/api/api_controller.rb:96:in `find_optional_organization' # ./lib/util/threadsession.rb:79:in `thread_locals' # ./spec/controllers/api/products_controller_spec.rb:164 2) Api::ProductsController show all @products in library should find organization Failure/Error: get 'index', :organization_id => @organization.label received :first with unexpected arguments expected: ({:conditions=>{:label=>"test_organization1"}}) got: ({:conditions=>{:name=>"test_organization1"}}) # ./app/controllers/api/api_controller.rb:96:in `find_optional_organization' # ./lib/util/threadsession.rb:79:in `thread_locals' # ./spec/controllers/api/products_controller_spec.rb:192 3) Api::ActivationKeysController show all activation keys should retrieve organization Failure/Error: Organization.should_receive(:first).once.with(hash_including(:conditions => {:label => '1234'})).and_return(@organization) received :first with unexpected arguments expected: (hash_including(:conditions=>{:label=>"1234"})) got: ({:conditions=>{:name=>"1234"}}) # ./spec/controllers/api/activation_keys_controller_spec.rb:84 4) Api::ActivationKeysController add system groups to an activation key should throw a 404 is passed in a bad system group id Failure/Error: response.status.should == 404 expected: 404 got: 500 (using ==) # ./spec/controllers/api/activation_keys_controller_spec.rb:320 5) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add package Failure/Error: lambda { @changeset.add_package!("pack", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:175 6) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add erratum Failure/Error: lambda { @changeset.add_erratum!("err", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:180 7) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add distribution Failure/Error: lambda { @changeset.add_distribution!("some-distro-id", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:186 8) Changeset Changeset should adding content adding content from the prior environment should add package by nvre Failure/Error: lambda { @changeset.add_package!(@pack_nvre, @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:209 9) Changeset Changeset should adding content adding content from the prior environment should add erratum Failure/Error: lambda { @changeset.add_erratum!("err", @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:222 10) Changeset Changeset should adding content adding content from the prior environment should add distribution Failure/Error: lambda { @changeset.add_distribution!("some-distro-id", @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:235 Finished in 624.47 seconds 2277 examples, 10 failures, 46 pending Failures: 1) Api::ProductsController show all @products in an environment should find organization Failure/Error: get 'index', :organization_id => @organization.label received :first with unexpected arguments expected: ({:conditions=>{:label=>"test_organization1"}}) got: ({:conditions=>{:name=>"test_organization1"}}) # ./app/controllers/api/api_controller.rb:96:in `find_optional_organization' # ./lib/util/threadsession.rb:79:in `thread_locals' # ./spec/controllers/api/products_controller_spec.rb:164 2) Api::ProductsController show all @products in library should find organization Failure/Error: get 'index', :organization_id => @organization.label received :first with unexpected arguments expected: ({:conditions=>{:label=>"test_organization1"}}) got: ({:conditions=>{:name=>"test_organization1"}}) # ./app/controllers/api/api_controller.rb:96:in `find_optional_organization' # ./lib/util/threadsession.rb:79:in `thread_locals' # ./spec/controllers/api/products_controller_spec.rb:192 3) Api::ActivationKeysController show all activation keys should retrieve organization Failure/Error: Organization.should_receive(:first).once.with(hash_including(:conditions => {:label => '1234'})).and_return(@organization) received :first with unexpected arguments expected: (hash_including(:conditions=>{:label=>"1234"})) got: ({:conditions=>{:name=>"1234"}}) # ./spec/controllers/api/activation_keys_controller_spec.rb:84 4) Api::ActivationKeysController add system groups to an activation key should throw a 404 is passed in a bad system group id Failure/Error: response.status.should == 404 expected: 404 got: 500 (using ==) # ./spec/controllers/api/activation_keys_controller_spec.rb:320 5) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add package Failure/Error: lambda { @changeset.add_package!("pack", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:175 6) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add erratum Failure/Error: lambda { @changeset.add_erratum!("err", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:180 7) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add distribution Failure/Error: lambda { @changeset.add_distribution!("some-distro-id", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:186 8) Changeset Changeset should adding content adding content from the prior environment should add package by nvre Failure/Error: lambda { @changeset.add_package!(@pack_nvre, @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:209 9) Changeset Changeset should adding content adding content from the prior environment should add erratum Failure/Error: lambda { @changeset.add_erratum!("err", @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:222 10) Changeset Changeset should adding content adding content from the prior environment should add distribution Failure/Error: lambda { @changeset.add_distribution!("some-distro-id", @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:235 rake aborted! ruby -S bundle exec rspec ./spec/controllers/gpg_keys_controller_spec.rb ./spec/controllers/providers_controller_spec.rb ./spec/controllers/products_controller_spec.rb ./spec/controllers/sync_schedules_controller_spec.rb ./spec/controllers/system_group_packages_controller_spec.rb ./spec/controllers/distributions_controller_spec.rb ./spec/controllers/filters_controller_spec.rb ./spec/controllers/system_group_errata_controller_spec.rb ./spec/controllers/system_groups_controller_spec.rb ./spec/controllers/repositories_controller_spec.rb ./spec/controllers/dashboard_controller_spec.rb ./spec/controllers/system_templates_controller_spec.rb ./spec/controllers/system_group_events_controller_spec.rb ./spec/controllers/operations_controller_spec.rb ./spec/controllers/system_packages_controller_spec.rb ./spec/controllers/notices_controller_spec.rb ./spec/controllers/activation_keys_controller_spec.rb ./spec/controllers/sync_management_controller_spec.rb ./spec/controllers/users_controller_spec.rb ./spec/controllers/system_errata_controller_spec.rb ./spec/controllers/subscriptions_controller_spec.rb ./spec/controllers/packages_controller_spec.rb ./spec/controllers/systems_controller_spec.rb ./spec/controllers/user_session_controller_spec.rb ./spec/controllers/password_resets_controller_spec.rb ./spec/controllers/roles_controller_spec.rb ./spec/controllers/search_controller_spec.rb ./spec/controllers/sync_plans_controller_spec.rb ./spec/controllers/errata_controller_spec.rb ./spec/controllers/system_events_controller_spec.rb ./spec/controllers/changeset_controller_spec.rb ./spec/controllers/api/gpg_keys_controller_spec.rb ./spec/controllers/api/providers_controller_spec.rb ./spec/controllers/api/root_controller_spec.rb ./spec/controllers/api/tasks_controller_spec.rb ./spec/controllers/api/products_controller_spec.rb ./spec/controllers/api/sync_controller_spec.rb ./spec/controllers/api/system_group_packages_controller_spec.rb ./spec/controllers/api/templates_controller_spec.rb ./spec/controllers/api/changesets_content_controller_spec.rb ./spec/controllers/api/distributions_controller_spec.rb ./spec/controllers/api/filters_controller_spec.rb ./spec/controllers/api/templates_content_controller_spec.rb ./spec/controllers/api/system_group_errata_controller_spec.rb ./spec/controllers/api/system_groups_controller_spec.rb ./spec/controllers/api/repositories_controller_spec.rb ./spec/controllers/api/permissions_controller_spec.rb ./spec/controllers/api/changesets_controller_spec.rb ./spec/controllers/api/activation_keys_controller_spec.rb ./spec/controllers/api/users_controller_spec.rb ./spec/controllers/api/subscriptions_controller_spec.rb ./spec/controllers/api/packages_controller_spec.rb ./spec/controllers/api/systems_controller_spec.rb ./spec/controllers/api/custom_info_controller_spec.rb ./spec/controllers/api/systems_packages_controller_spec.rb ./spec/controllers/api/roles_controller_spec.rb ./spec/controllers/api/puppetclasses_controller_spec.rb ./spec/controllers/api/sync_plans_controller_spec.rb ./spec/controllers/api/errata_controller_spec.rb ./spec/controllers/api/uebercerts_controller_spec.rb ./spec/controllers/api/organizations_controller_spec.rb ./spec/controllers/api/environments_controller_spec.rb ./spec/controllers/promotions_controller_spec.rb ./spec/controllers/organizations_controller_spec.rb ./spec/controllers/content_search_controller_spec.rb ./spec/controllers/environments_controller_spec.rb ./spec/views/systems/index.html.haml_spec.rb ./spec/views/sync_management/index.html.haml_spec.rb ./spec/views/distributions/_filelist.html.haml_spec.rb ./spec/views/distributions/_show.html.haml_spec.rb ./spec/views/content/index.html.haml_spec.rb ./spec/views/activation_keys/_edit.html.haml_spec.rb ./spec/views/activation_keys/_new.html.haml_spec.rb ./spec/views/activation_keys/index.html.haml_spec.rb ./spec/views/common/_search.html.haml_spec.rb ./spec/views/operations/index.html.haml_spec.rb ./spec/views/dashboard/show.html.haml_spec.rb ./spec/views/dashboard/index.html.haml_spec.rb ./spec/models/activation_key_spec.rb ./spec/models/repo_spec.rb ./spec/models/permission_spec.rb ./spec/models/environment_spec.rb ./spec/models/changeset_spec.rb ./spec/models/role_spec.rb ./spec/models/help_tip_spec.rb ./spec/models/orchestration_spec.rb ./spec/models/errata_spec.rb ./spec/models/system_spec.rb ./spec/models/provider_spec.rb ./spec/models/custom_info_spec.rb ./spec/models/task_status_spec.rb ./spec/models/system_template_package_spec.rb ./spec/models/pool_spec.rb ./spec/models/system_template_spec.rb ./spec/models/ldap_group_role_spec.rb ./spec/models/lazy_accessor_spec.rb ./spec/models/distribution_spec.rb ./spec/models/product_spec.rb ./spec/models/system_group_spec.rb ./spec/models/sync_plan_spec.rb ./spec/models/candlepin_consumer_spec.rb ./spec/models/gpg_key_spec.rb ./spec/models/user_spec.rb ./spec/models/pulp_task_status_spec.rb ./spec/models/repository_spec.rb ./spec/models/organization_spec.rb ./spec/models/system_template_revision_spec.rb ./spec/models/hypervisor_spec.rb ./spec/helpers/users_helper_spec.rb ./spec/helpers/application_info_helper_spec.rb ./spec/helpers/dashboard_helper_spec.rb ./spec/helpers/sync_management_helper_spec.rb ./spec/helpers/system_groups_helper_spec.rb ./spec/helpers/filters_helper_spec.rb ./spec/helpers/nodes_helper_spec.rb ./spec/helpers/hash_util_spec.rb ./spec/helpers/errata_helper_spec.rb ./spec/helpers/custom_info_helper_spec.rb ./spec/helpers/sync_schedules_helper_spec.rb ./spec/helpers/environments_helper_spec.rb ./spec/helpers/katello_url_helper_spec.rb ./spec/helpers/operations_helper_spec.rb ./spec/helpers/sync_plans_helper_spec.rb ./spec/helpers/puppetclasses_helper_spec.rb ./spec/helpers/content_helper_spec.rb ./spec/helpers/packages_helper_spec.rb ./spec/helpers/content_search_helper_spec.rb ./spec/helpers/systems_helper_spec.rb ./spec/lib/model_util_spec.rb ./spec/lib/mapping_spec.rb ./spec/lib/url_matcher_spec.rb ./spec/lib/notifications_spec.rb ./spec/lib/cdn_spec.rb ./spec/lib/package_util_spec.rb ./spec/lib/password_spec.rb ./spec/routing/environments_routing_spec.rb ./spec/routing/user_session_routes_spec.rb ./spec/routing/consumers_routing_spec.rb failed /usr/lib/ruby/gems/1.8/gems/rspec-core-2.5.1/lib/rspec/core/rake_task.rb:139:in `initialize' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:60:in `verbose' /usr/lib/ruby/gems/1.8/gems/rspec-core-2.5.1/lib/rspec/core/rake_task.rb:131:in `send' /usr/lib/ruby/gems/1.8/gems/rspec-core-2.5.1/lib/rspec/core/rake_task.rb:131:in `initialize' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `invoke_with_call_chain' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:176:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:157:in `invoke_with_call_chain' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/bin/rake:33 /usr/bin/rake:19:in `load' /usr/bin/rake:19 Tasks: TOP => hudson:spec => spec Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Recording fingerprints Failed to send e-mail to davidd because no e-mail address is known, and no default e-mail domain is configured From lzap at redhat.com Tue Oct 2 13:18:41 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 2 Oct 2012 15:18:41 +0200 Subject: [katello-devel] Katello nightly does not work In-Reply-To: <20121002130206.GI4257@lzapx.brq.redhat.com> References: <20121002130206.GI4257@lzapx.brq.redhat.com> Message-ID: <20121002131840.GJ4257@lzapx.brq.redhat.com> Got it, grep ^servers /etc/katello/thin.yml servers: Stop katello and apache. Then set it to servers: 2 and then start katello and apache. Due to change a5cf1f55051f3b146e8551aca08dce1a0d6c53b6 we are not setting it up correctly. I am going to fix this now. LZ On Tue, Oct 02, 2012 at 03:02:06PM +0200, Lukas Zapletal wrote: > Hey, > > I have noticed (and Jeff confirmed me this) current nightly does not > work. Apache (or Thin) does not respond, no other error reports than: > > # grep -iE '(^err|error|fatal|AVC)' > /var/log/katello/katello-configure/*log /var/log/katello/*log > /var/log/pulp/*log /var/log/tomcat6/catalina.out > /var/log/audit/audit.log /var/log/httpd/*log /var/log/elasticsearch/ | > grep -viE '(msgid|msgstr|resteasy)' > > /var/log/katello/client.log:2012-10-02 14:11:07,811 [ERROR][MainThread] > error() @ base.py:206 - error: Service unavailable or restarting, try > later > > /var/log/httpd/ssl_kt_error_log:[Tue Oct 02 14:11:07 2012] [error] > proxy: BALANCER: (balancer://thinservers). All workers are in error > state > > I thought it is SELinux, but it is not. Currently investigating the > issue, please comment if you know something. Otherwise git blame will > show it (I hope it's not me :-) > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > 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 Tue Oct 2 14:00:45 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Tue, 02 Oct 2012 16:00:45 +0200 Subject: [katello-devel] Funky fuzzy errors in the thin.log In-Reply-To: <20121002121816.GE4257@lzapx.brq.redhat.com> References: <20121002121816.GE4257@lzapx.brq.redhat.com> Message-ID: <506AF38D.7030503@redhat.com> On 10/02/2012 02:18 PM, Lukas Zapletal wrote: > Can we get rid of > them too? They are flooding the logs. Your wish comes true: https://github.com/Katello/katello/pull/774 Anything else I can do for you today? :)) -- Miroslav Suchy Red Hat Systems Management Engineering From daviddavis at redhat.com Tue Oct 2 14:03:10 2012 From: daviddavis at redhat.com (David Davis) Date: Tue, 2 Oct 2012 10:03:10 -0400 (EDT) Subject: [katello-devel] Fwd: Build failed in Jenkins: katello-unit #3379 In-Reply-To: <927908301.5644984.1349183536766.JavaMail.root@redhat.com> Message-ID: <558226605.5695153.1349186590582.JavaMail.root@redhat.com> Hey, so I fixed a bunch of the rspec tests. The others had to do with translating strings which I am not too familiar with. Anyway, here's my pull request: https://github.com/Katello/katello/pull/773 Thanks. ----- Original Message ----- From: "David Davis" To: "katello-devel" Sent: Tuesday, October 2, 2012 9:12:16 AM Subject: [katello-devel] Fwd: Build failed in Jenkins: katello-unit #3379 So katello-unit is back up and running but in the mean time we've incurred some broken rspec tests. Anyone want to help me fix these? Thanks. David ----- Forwarded Message ----- From: LeeroyJenkins at redhat.com To: katello-internal at redhat.com, lzap+git at redhat.com, msuchy at redhat.com, pajkycz at gmail.com, pchalupa at redhat.com, daviddavis at redhat.com, bbuckingham at redhat.com, mmccune at redhat.com, mbacovsk at redhat.com, inecas at redhat.com, dmitri at redhat.com Sent: Tuesday, October 2, 2012 8:35:59 AM Subject: Build failed in Jenkins: katello-unit #3379 See ------------------------------------------ [...truncated 47504 lines...] # ./spec/controllers/systems_controller_spec.rb:742 systems/index.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/systems/index.html.haml_spec.rb:16 sync_management/index.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/sync_management/index.html.haml_spec.rb:16 content/index.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/content/index.html.haml_spec.rb:16 operations/index.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/operations/index.html.haml_spec.rb:16 dashboard/show.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/dashboard/show.html.haml_spec.rb:16 dashboard/index.html.haml add some examples to (or delete) # Not Yet Implemented # ./spec/views/dashboard/index.html.haml_spec.rb:16 HelpTip add some examples to (or delete) # Not Yet Implemented # ./spec/models/help_tip_spec.rb:16 System host-guest relation guest system # Not Yet Implemented # ./spec/models/system_spec.rb:335 System host-guest relation host system # Not Yet Implemented # ./spec/models/system_spec.rb:345 LdapGroupRole add some examples to (or delete) # Not Yet Implemented # ./spec/models/ldap_group_role_spec.rb:4 UsersHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/users_helper_spec.rb:26 DashboardHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/dashboard_helper_spec.rb:26 SyncManagementHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/sync_management_helper_spec.rb:26 SystemGroupsHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/system_groups_helper_spec.rb:16 FiltersHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/filters_helper_spec.rb:14 NodesHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/nodes_helper_spec.rb:26 ErrataHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/errata_helper_spec.rb:26 CustomInfoHelper add tests for CustomInfoHelper::consolidate() # Not Yet Implemented # ./spec/helpers/custom_info_helper_spec.rb:16 SyncSchedulesHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/sync_schedules_helper_spec.rb:14 EnvironmentsHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/environments_helper_spec.rb:26 OperationsHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/operations_helper_spec.rb:26 SyncPlansHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/sync_plans_helper_spec.rb:14 PuppetclassesHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/puppetclasses_helper_spec.rb:26 ContentHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/content_helper_spec.rb:26 PackagesHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/packages_helper_spec.rb:26 ContentSearchHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/content_search_helper_spec.rb:14 SystemsHelper add some examples to (or delete) # Not Yet Implemented # ./spec/helpers/systems_helper_spec.rb:26 Failures: 1) Api::ProductsController show all @products in an environment should find organization Failure/Error: get 'index', :organization_id => @organization.label received :first with unexpected arguments expected: ({:conditions=>{:label=>"test_organization1"}}) got: ({:conditions=>{:name=>"test_organization1"}}) # ./app/controllers/api/api_controller.rb:96:in `find_optional_organization' # ./lib/util/threadsession.rb:79:in `thread_locals' # ./spec/controllers/api/products_controller_spec.rb:164 2) Api::ProductsController show all @products in library should find organization Failure/Error: get 'index', :organization_id => @organization.label received :first with unexpected arguments expected: ({:conditions=>{:label=>"test_organization1"}}) got: ({:conditions=>{:name=>"test_organization1"}}) # ./app/controllers/api/api_controller.rb:96:in `find_optional_organization' # ./lib/util/threadsession.rb:79:in `thread_locals' # ./spec/controllers/api/products_controller_spec.rb:192 3) Api::ActivationKeysController show all activation keys should retrieve organization Failure/Error: Organization.should_receive(:first).once.with(hash_including(:conditions => {:label => '1234'})).and_return(@organization) received :first with unexpected arguments expected: (hash_including(:conditions=>{:label=>"1234"})) got: ({:conditions=>{:name=>"1234"}}) # ./spec/controllers/api/activation_keys_controller_spec.rb:84 4) Api::ActivationKeysController add system groups to an activation key should throw a 404 is passed in a bad system group id Failure/Error: response.status.should == 404 expected: 404 got: 500 (using ==) # ./spec/controllers/api/activation_keys_controller_spec.rb:320 5) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add package Failure/Error: lambda { @changeset.add_package!("pack", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:175 6) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add erratum Failure/Error: lambda { @changeset.add_erratum!("err", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:180 7) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add distribution Failure/Error: lambda { @changeset.add_distribution!("some-distro-id", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:186 8) Changeset Changeset should adding content adding content from the prior environment should add package by nvre Failure/Error: lambda { @changeset.add_package!(@pack_nvre, @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:209 9) Changeset Changeset should adding content adding content from the prior environment should add erratum Failure/Error: lambda { @changeset.add_erratum!("err", @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:222 10) Changeset Changeset should adding content adding content from the prior environment should add distribution Failure/Error: lambda { @changeset.add_distribution!("some-distro-id", @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:235 Finished in 624.47 seconds 2277 examples, 10 failures, 46 pending Failures: 1) Api::ProductsController show all @products in an environment should find organization Failure/Error: get 'index', :organization_id => @organization.label received :first with unexpected arguments expected: ({:conditions=>{:label=>"test_organization1"}}) got: ({:conditions=>{:name=>"test_organization1"}}) # ./app/controllers/api/api_controller.rb:96:in `find_optional_organization' # ./lib/util/threadsession.rb:79:in `thread_locals' # ./spec/controllers/api/products_controller_spec.rb:164 2) Api::ProductsController show all @products in library should find organization Failure/Error: get 'index', :organization_id => @organization.label received :first with unexpected arguments expected: ({:conditions=>{:label=>"test_organization1"}}) got: ({:conditions=>{:name=>"test_organization1"}}) # ./app/controllers/api/api_controller.rb:96:in `find_optional_organization' # ./lib/util/threadsession.rb:79:in `thread_locals' # ./spec/controllers/api/products_controller_spec.rb:192 3) Api::ActivationKeysController show all activation keys should retrieve organization Failure/Error: Organization.should_receive(:first).once.with(hash_including(:conditions => {:label => '1234'})).and_return(@organization) received :first with unexpected arguments expected: (hash_including(:conditions=>{:label=>"1234"})) got: ({:conditions=>{:name=>"1234"}}) # ./spec/controllers/api/activation_keys_controller_spec.rb:84 4) Api::ActivationKeysController add system groups to an activation key should throw a 404 is passed in a bad system group id Failure/Error: response.status.should == 404 expected: 404 got: 500 (using ==) # ./spec/controllers/api/activation_keys_controller_spec.rb:320 5) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add package Failure/Error: lambda { @changeset.add_package!("pack", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:175 6) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add erratum Failure/Error: lambda { @changeset.add_erratum!("err", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:180 7) Changeset Changeset should adding content fail adding content from not promoted repository should fail on add distribution Failure/Error: lambda { @changeset.add_distribution!("some-distro-id", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:186 8) Changeset Changeset should adding content adding content from the prior environment should add package by nvre Failure/Error: lambda { @changeset.add_package!(@pack_nvre, @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:209 9) Changeset Changeset should adding content adding content from the prior environment should add erratum Failure/Error: lambda { @changeset.add_erratum!("err", @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:222 10) Changeset Changeset should adding content adding content from the prior environment should add distribution Failure/Error: lambda { @changeset.add_distribution!("some-distro-id", @prod) }. expected ActiveRecord::RecordInvalid with message matching /already been taken/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:235 rake aborted! ruby -S bundle exec rspec ./spec/controllers/gpg_keys_controller_spec.rb ./spec/controllers/providers_controller_spec.rb ./spec/controllers/products_controller_spec.rb ./spec/controllers/sync_schedules_controller_spec.rb ./spec/controllers/system_group_packages_controller_spec.rb ./spec/controllers/distributions_controller_spec.rb ./spec/controllers/filters_controller_spec.rb ./spec/controllers/system_group_errata_controller_spec.rb ./spec/controllers/system_groups_controller_spec.rb ./spec/controllers/repositories_controller_spec.rb ./spec/controllers/dashboard_controller_spec.rb ./spec/controllers/system_templates_controller_spec.rb ./spec/controllers/system_group_events_controller_spec.rb ./spec/controllers/operations_controller_spec.rb ./spec/controllers/system_packages_controller_spec.rb ./spec/controllers/notices_controller_spec.rb ./spec/controllers/activation_keys_controller_spec.rb ./spec/controllers/sync_management_controller_spec.rb ./spec/controllers/users_contro! ller_spec.rb ./spec/controllers/system_errata_controller_spec.rb ./spec/controllers/subscriptions_controller_spec.rb ./spec/controllers/packages_controller_spec.rb ./spec/controllers/systems_controller_spec.rb ./spec/controllers/user_session_controller_spec.rb ./spec/controllers/password_resets_controller_spec.rb ./spec/controllers/roles_controller_spec.rb ./spec/controllers/search_controller_spec.rb ./spec/controllers/sync_plans_controller_spec.rb ./spec/controllers/errata_controller_spec.rb ./spec/controllers/system_events_controller_spec.rb ./spec/controllers/changeset_controller_spec.rb ./spec/controllers/api/gpg_keys_controller_spec.rb ./spec/controllers/api/providers_controller_spec.rb ./spec/controllers/api/root_controller_spec.rb ./spec/controllers/api/tasks_controller_spec.rb ./spec/controllers/api/products_controller_spec.rb ./spec/controllers/api/sync_controller_spec.rb ./spec/controllers/api/system_group_packages_controller_spec.rb ./spec/controllers/api/templat! es_controller_spec.rb ./spec/controllers/api/changesets_content_contro ller_spec.rb ./spec/controllers/api/distributions_controller_spec.rb ./spec/controllers/api/filters_controller_spec.rb ./spec/controllers/api/templates_content_controller_spec.rb ./spec/controllers/api/system_group_errata_controller_spec.rb ./spec/controllers/api/system_groups_controller_spec.rb ./spec/controllers/api/repositories_controller_spec.rb ./spec/controllers/api/permissions_controller_spec.rb ./spec/controllers/api/changesets_controller_spec.rb ./spec/controllers/api/activation_keys_controller_spec.rb ./spec/controllers/api/users_controller_spec.rb ./spec/controllers/api/subscriptions_controller_spec.rb ./spec/controllers/api/packages_controller_spec.rb ./spec/controllers/api/systems_controller_spec.rb ./spec/controllers/api/custom_info_controller_spec.rb ./spec/controllers/api/systems_packages_controller_spec.rb ./spec/controllers/api/roles_controller_spec.rb ./spec/controllers/api/puppetclasses_controller_spec.rb ./spec/controllers/api/sync_plans_controller_spec.! rb ./spec/controllers/api/errata_controller_spec.rb ./spec/controllers/api/uebercerts_controller_spec.rb ./spec/controllers/api/organizations_controller_spec.rb ./spec/controllers/api/environments_controller_spec.rb ./spec/controllers/promotions_controller_spec.rb ./spec/controllers/organizations_controller_spec.rb ./spec/controllers/content_search_controller_spec.rb ./spec/controllers/environments_controller_spec.rb ./spec/views/systems/index.html.haml_spec.rb ./spec/views/sync_management/index.html.haml_spec.rb ./spec/views/distributions/_filelist.html.haml_spec.rb ./spec/views/distributions/_show.html.haml_spec.rb ./spec/views/content/index.html.haml_spec.rb ./spec/views/activation_keys/_edit.html.haml_spec.rb ./spec/views/activation_keys/_new.html.haml_spec.rb ./spec/views/activation_keys/index.html.haml_spec.rb ./spec/views/common/_search.html.haml_spec.rb ./spec/views/operations/index.html.haml_spec.rb ./spec/views/dashboard/show.html.haml_spec.rb ./spec/views/dashboa! rd/index.html.haml_spec.rb ./spec/models/activation_key_spec.rb ./spec /models/repo_spec.rb ./spec/models/permission_spec.rb ./spec/models/environment_spec.rb ./spec/models/changeset_spec.rb ./spec/models/role_spec.rb ./spec/models/help_tip_spec.rb ./spec/models/orchestration_spec.rb ./spec/models/errata_spec.rb ./spec/models/system_spec.rb ./spec/models/provider_spec.rb ./spec/models/custom_info_spec.rb ./spec/models/task_status_spec.rb ./spec/models/system_template_package_spec.rb ./spec/models/pool_spec.rb ./spec/models/system_template_spec.rb ./spec/models/ldap_group_role_spec.rb ./spec/models/lazy_accessor_spec.rb ./spec/models/distribution_spec.rb ./spec/models/product_spec.rb ./spec/models/system_group_spec.rb ./spec/models/sync_plan_spec.rb ./spec/models/candlepin_consumer_spec.rb ./spec/models/gpg_key_spec.rb ./spec/models/user_spec.rb ./spec/models/pulp_task_status_spec.rb ./spec/models/repository_spec.rb ./spec/models/organization_spec.rb ./spec/models/system_template_revision_spec.rb ./spec/models/hypervisor_spec.rb ./spec/helpers/u! sers_helper_spec.rb ./spec/helpers/application_info_helper_spec.rb ./spec/helpers/dashboard_helper_spec.rb ./spec/helpers/sync_management_helper_spec.rb ./spec/helpers/system_groups_helper_spec.rb ./spec/helpers/filters_helper_spec.rb ./spec/helpers/nodes_helper_spec.rb ./spec/helpers/hash_util_spec.rb ./spec/helpers/errata_helper_spec.rb ./spec/helpers/custom_info_helper_spec.rb ./spec/helpers/sync_schedules_helper_spec.rb ./spec/helpers/environments_helper_spec.rb ./spec/helpers/katello_url_helper_spec.rb ./spec/helpers/operations_helper_spec.rb ./spec/helpers/sync_plans_helper_spec.rb ./spec/helpers/puppetclasses_helper_spec.rb ./spec/helpers/content_helper_spec.rb ./spec/helpers/packages_helper_spec.rb ./spec/helpers/content_search_helper_spec.rb ./spec/helpers/systems_helper_spec.rb ./spec/lib/model_util_spec.rb ./spec/lib/mapping_spec.rb ./spec/lib/url_matcher_spec.rb ./spec/lib/notifications_spec.rb ./spec/lib/cdn_spec.rb ./spec/lib/package_util_spec.rb ./spec/lib/pa! ssword_spec.rb ./spec/routing/environments_routing_spec.rb ./spec/rout ing/user_session_routes_spec.rb ./spec/routing/consumers_routing_spec.rb failed /usr/lib/ruby/gems/1.8/gems/rspec-core-2.5.1/lib/rspec/core/rake_task.rb:139:in `initialize' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/file_utils_ext.rb:60:in `verbose' /usr/lib/ruby/gems/1.8/gems/rspec-core-2.5.1/lib/rspec/core/rake_task.rb:131:in `send' /usr/lib/ruby/gems/1.8/gems/rspec-core-2.5.1/lib/rspec/core/rake_task.rb:131:in `initialize' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `invoke_with_call_chain' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:176:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:174:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:157:in `invoke_with_call_chain' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/bin/rake:33 /usr/bin/rake:19:in `load' /usr/bin/rake:19 Tasks: TOP => hudson:spec => spec Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Recording fingerprints Failed to send e-mail to davidd because no e-mail address is known, and no default e-mail domain is configured _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From inecas at redhat.com Tue Oct 2 14:12:22 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 02 Oct 2012 16:12:22 +0200 Subject: [katello-devel] Funky fuzzy errors in the thin.log In-Reply-To: <506AF38D.7030503@redhat.com> References: <20121002121816.GE4257@lzapx.brq.redhat.com> <506AF38D.7030503@redhat.com> Message-ID: <506AF646.7070308@redhat.com> On 10/02/2012 04:00 PM, Miroslav Such? wrote: > On 10/02/2012 02:18 PM, Lukas Zapletal wrote: >> Can we get rid of >> them too? They are flooding the logs. > > Your wish comes true: > https://github.com/Katello/katello/pull/774 > > Anything else I can do for you today? :)) > I believe pulling translations from Zanata is what frees us form the warnings and from the actual fuzzy messages as well. https://github.com/Katello/katello/pull/775 -- Ivan From omaciel at redhat.com Tue Oct 2 14:14:09 2012 From: omaciel at redhat.com (Og Maciel) Date: Tue, 2 Oct 2012 10:14:09 -0400 (EDT) Subject: [katello-devel] Funky fuzzy errors in the thin.log In-Reply-To: <506AF38D.7030503@redhat.com> Message-ID: <2134323072.5634342.1349187249856.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Miroslav Such?" > To: katello-devel at redhat.com > Sent: Tuesday, October 2, 2012 10:00:45 AM > Subject: Re: [katello-devel] Funky fuzzy errors in the thin.log > > Your wish comes true: > https://github.com/Katello/katello/pull/774 > > Anything else I can do for you today? :)) Man, I had complained about this before and thought I had even filed a BZ (could not find it)... should have talked to you Miroslav! :) -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.646.707.7723 irc: omaciel From lzap at redhat.com Tue Oct 2 14:27:58 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 2 Oct 2012 16:27:58 +0200 Subject: [katello-devel] Katello nightly does not work In-Reply-To: <20121002130206.GI4257@lzapx.brq.redhat.com> References: <20121002130206.GI4257@lzapx.brq.redhat.com> Message-ID: <20121002142757.GL4257@lzapx.brq.redhat.com> Fix is here: https://github.com/Katello/katello/pull/776 LZ On Tue, Oct 02, 2012 at 03:02:06PM +0200, Lukas Zapletal wrote: > Hey, > > I have noticed (and Jeff confirmed me this) current nightly does not > work. Apache (or Thin) does not respond, no other error reports than: > > # grep -iE '(^err|error|fatal|AVC)' > /var/log/katello/katello-configure/*log /var/log/katello/*log > /var/log/pulp/*log /var/log/tomcat6/catalina.out > /var/log/audit/audit.log /var/log/httpd/*log /var/log/elasticsearch/ | > grep -viE '(msgid|msgstr|resteasy)' > > /var/log/katello/client.log:2012-10-02 14:11:07,811 [ERROR][MainThread] > error() @ base.py:206 - error: Service unavailable or restarting, try > later > > /var/log/httpd/ssl_kt_error_log:[Tue Oct 02 14:11:07 2012] [error] > proxy: BALANCER: (balancer://thinservers). All workers are in error > state > > I thought it is SELinux, but it is not. Currently investigating the > issue, please comment if you know something. Otherwise git blame will > show it (I hope it's not me :-) > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > 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 Tue Oct 2 17:32:08 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 2 Oct 2012 13:32:08 -0400 (EDT) Subject: [katello-devel] Deleting a manifest and pulp In-Reply-To: <17886372.3826238.1349198713002.JavaMail.root@redhat.com> Message-ID: <639511348.3828288.1349199128537.JavaMail.root@redhat.com> I've had a chance to dig a bit deeper into the delete manifest story and need some help. A wiki was started here: https://fedorahosted.org/katello/wiki/SubscriptionManifestDeletionDesign First, from a headpin point-of-view manifest deletion is trivial: Call candlepin and delete it, then remove references to the Red Hat provider subscriptions from activation keys. For katello it is much more complicated. In addition to cleaning out katello references such as activation keys, what happens to the pulp content? If someone wants to sign up to assist me with the pulp moving parts next iteration, that would be great. Need to understand the "pulp v2" implications too. From bkearney at redhat.com Tue Oct 2 20:43:07 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 02 Oct 2012 16:43:07 -0400 Subject: [katello-devel] Fwd: [Pulp-list] i18n input In-Reply-To: <6D5C7F45-18A5-4695-A380-8783C47F5E34@redhat.com> References: <6D5C7F45-18A5-4695-A380-8783C47F5E34@redhat.com> Message-ID: <506B51DB.2000409@redhat.com> Comments? -- bk -------- Original Message -------- Subject: [Pulp-list] i18n input Date: Tue, 2 Oct 2012 14:40:18 -0600 From: Jason Connor To: pulp-list at redhat.com Hi All, Lately we've been struggling with a rash of bugs related to i18n input in Pulp. Python 2's unicode support is only so-so and whenever we get non-ascii or non-utf-8 encoded strings, we tend to run into trouble (the most common is problematic encoding seems to be latin-1). Given that Python's str type is really just a byte array with some built in smarts, it isn't really possible to guess what the encoding might actually be. To address this issue, I propose that we make string encoding as utf-8 a hard requirement on the server. To enforce this, we'll try to decode all strings from utf-8 and any failures will get a 400 server response with some sort of standardized message: utf-8 encoded strings only (dummy), or something similar. Any thoughts? Jason L Connor linear on freenode #pulp http://pulpproject.org/ RHCE: 805010912355231 GPG Fingerprint: 2048R/CC4ED7C1 _______________________________________________ Pulp-list mailing list Pulp-list at redhat.com https://www.redhat.com/mailman/listinfo/pulp-list From mmccune at redhat.com Tue Oct 2 21:17:23 2012 From: mmccune at redhat.com (Mike McCune) Date: Tue, 02 Oct 2012 14:17:23 -0700 Subject: [katello-devel] Fwd: [Pulp-list] i18n input In-Reply-To: <506B51DB.2000409@redhat.com> References: <6D5C7F45-18A5-4695-A380-8783C47F5E34@redhat.com> <506B51DB.2000409@redhat.com> Message-ID: <506B59E3.20807@redhat.com> comment: This would be awesome. I'd much rather see the below vs a worst case scenario of forcing ASCII encoding for everything. On 10/02/2012 01:43 PM, Bryan Kearney wrote: > Comments? > > -- bk > > > > -------- Original Message -------- > Subject: [Pulp-list] i18n input > Date: Tue, 2 Oct 2012 14:40:18 -0600 > From: Jason Connor > To: pulp-list at redhat.com > > Hi All, > > Lately we've been struggling with a rash of bugs related to i18n input > in Pulp. Python 2's unicode support is only so-so and whenever we get > non-ascii or non-utf-8 encoded strings, we tend to run into trouble (the > most common is problematic encoding seems to be latin-1). Given that > Python's str type is really just a byte array with some built in smarts, > it isn't really possible to guess what the encoding might actually be. > > To address this issue, I propose that we make string encoding as utf-8 a > hard requirement on the server. To enforce this, we'll try to decode all > strings from utf-8 and any failures will get a 400 server response with > some sort of standardized message: utf-8 encoded strings only (dummy), > or something similar. > > Any thoughts? > > Jason L Connor > linear on freenode #pulp > http://pulpproject.org/ > RHCE: 805010912355231 > GPG Fingerprint: 2048R/CC4ED7C1 > > > > > _______________________________________________ > Pulp-list mailing list > Pulp-list at redhat.com > https://www.redhat.com/mailman/listinfo/pulp-list > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Tue Oct 2 22:00:10 2012 From: mmccune at redhat.com (Mike McCune) Date: Tue, 02 Oct 2012 15:00:10 -0700 Subject: [katello-devel] Pulp warning: Unsupported characters for Yum In-Reply-To: <20121002090207.GA4257@lzapx.brq.redhat.com> References: <20121002090207.GA4257@lzapx.brq.redhat.com> Message-ID: <506B63EA.6010304@redhat.com> On 10/02/2012 02:02 AM, Lukas Zapletal wrote: > Hey, > > during pulp migration I can see this warning: > > ID for repositories [] contains characters which are not supported by > Yum as a repository title in a '.repo' file. > Because of this, you may see an error when installing a package from > these repositories on a consumer. You can either > manually update consumer's .repo file to update title, or delete and > create a new repository that follows new ID restriction. > Repository ID may now contain only numbers(0-9), upper and lower case > letters(A-Z, a-z), hyphens(-), underscore(_) and periods(.) > > What is our strategy for CFSE here (particulary 1.0 to 1.1)? Should we > make a doco bug? What is the recommended approach? Does > subscription-manager takes care of it automatically? > we attempted to solve this with the series of bugs around adding labels to Orgs/Envs/Products/Repos: https://fedorahosted.org/katello/wiki/ObjectLabelDesign#Yum the Object Labeling solves it for new objects we create but for existing repositories with orgs/envs/products/repos with UTF8 characters we are out of luck because Pulp does *not* let you change the ID of the repo. We won't be able to migrate these over to the new scheme with a simple upgrade. We may need to look into doing as pulp states above where we delete old repos and recreate with the new label. This will cause some pain because they will need to get re-synced and re-promoted ... a fairly annoying problem that I'm looking into currently. Mike From omaciel at redhat.com Tue Oct 2 22:14:24 2012 From: omaciel at redhat.com (Og Maciel) Date: Tue, 2 Oct 2012 18:14:24 -0400 (EDT) Subject: [katello-devel] Pulp warning: Unsupported characters for Yum In-Reply-To: <506B63EA.6010304@redhat.com> Message-ID: <1407364073.5953946.1349216064336.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Mike McCune" > To: katello-devel at redhat.com > Sent: Tuesday, October 2, 2012 6:00:10 PM > Subject: Re: [katello-devel] Pulp warning: Unsupported characters for Yum > > the Object Labeling solves it for new objects we create but for > existing > repositories with orgs/envs/products/repos with UTF8 characters we > are > out of luck because Pulp does *not* let you change the ID of the > repo. > We won't be able to migrate these over to the new scheme with a > simple > upgrade. > > We may need to look into doing as pulp states above where we delete > old > repos and recreate with the new label. This will cause some pain > because they will need to get re-synced and re-promoted ... a fairly > annoying problem that I'm looking into currently. Shouldn't we then provide some kind of "migration" script to help out those who may be out of luck? It would be a "nice thing to do" imho. -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.646.707.7723 irc: omaciel From lzap at redhat.com Wed Oct 3 07:27:21 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 3 Oct 2012 09:27:21 +0200 Subject: [katello-devel] Deleting a manifest and pulp In-Reply-To: <639511348.3828288.1349199128537.JavaMail.root@redhat.com> References: <17886372.3826238.1349198713002.JavaMail.root@redhat.com> <639511348.3828288.1349199128537.JavaMail.root@redhat.com> Message-ID: <20121003072721.GA4248@lzapx.brq.redhat.com> On Tue, Oct 02, 2012 at 01:32:08PM -0400, Tom McKay wrote: > First, from a headpin point-of-view manifest deletion is trivial: Call candlepin and delete it, then remove references to the Red Hat provider subscriptions from activation keys. > What happens to registered/subscribed consumers then? > For katello it is much more complicated. In addition to cleaning out katello references such as activation keys, what happens to the pulp content? I would like to ask first what is the desired behavior for consumers. If they should be immediately removed from subscriptions, that is in the next refresh call after 4 hours, then we could delete the repos from Pulp. Best solution could be to defer this deletion 5 hours or something (maybe to schedule this if this is possible?) but then reimport could cause issues (repoid would be occupied for some time). If there is a way of immediate unregistration then I think we could delete the repos immediately. > What is the desired state of a Katello system after you delete a > manifest? > I assume deleting all the referenced data from Katello databases and backend engines. > Should we delete all the repos associated with the manifest after you > delete it? > Should we leave the content there but hide it? > Should we leave the content there but note that it is unentitled? > I think so, and I think we should do it immediately (asking consumers to unregister ASAP). If we must wait 4 hours for technical reasons (refresh), we must inform the user he can reimport after 5 hours and defer deletions. > What happens when we re-import a manifest .. should it just stitch > everything back up together? > Stitching in software development does not sound good at all :-) I'd rather delete everything re-creating it. But this really depends on what are PM requirements are on this. Maybe they will really want consumers to stay subscribed until manifest is re-imported. My obligatory question follows: How does Satellite do it today? -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Oct 3 07:40:02 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 3 Oct 2012 09:40:02 +0200 Subject: [katello-devel] Fwd: [Pulp-list] i18n input In-Reply-To: <506B51DB.2000409@redhat.com> References: <6D5C7F45-18A5-4695-A380-8783C47F5E34@redhat.com> <506B51DB.2000409@redhat.com> Message-ID: <20121003074002.GB4248@lzapx.brq.redhat.com> Everything should be UNICODE only from the very first line ;-) LZ On Tue, Oct 02, 2012 at 04:43:07PM -0400, Bryan Kearney wrote: > Comments? > > -- bk > > > > -------- Original Message -------- > Subject: [Pulp-list] i18n input > Date: Tue, 2 Oct 2012 14:40:18 -0600 > From: Jason Connor > To: pulp-list at redhat.com > > Hi All, > > Lately we've been struggling with a rash of bugs related to i18n > input in Pulp. Python 2's unicode support is only so-so and whenever > we get non-ascii or non-utf-8 encoded strings, we tend to run into > trouble (the most common is problematic encoding seems to be > latin-1). Given that Python's str type is really just a byte array > with some built in smarts, it isn't really possible to guess what > the encoding might actually be. > > To address this issue, I propose that we make string encoding as > utf-8 a hard requirement on the server. To enforce this, we'll try > to decode all strings from utf-8 and any failures will get a 400 > server response with some sort of standardized message: utf-8 > encoded strings only (dummy), or something similar. > > Any thoughts? > > Jason L Connor > linear on freenode #pulp > http://pulpproject.org/ > RHCE: 805010912355231 > GPG Fingerprint: 2048R/CC4ED7C1 > > > > > _______________________________________________ > Pulp-list mailing list > Pulp-list at redhat.com > https://www.redhat.com/mailman/listinfo/pulp-list > > > _______________________________________________ > 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 Wed Oct 3 07:47:19 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 03 Oct 2012 09:47:19 +0200 Subject: [katello-devel] Fwd: [Pulp-list] i18n input In-Reply-To: <20121003074002.GB4248@lzapx.brq.redhat.com> References: <6D5C7F45-18A5-4695-A380-8783C47F5E34@redhat.com> <506B51DB.2000409@redhat.com> <20121003074002.GB4248@lzapx.brq.redhat.com> Message-ID: <506BED87.7050504@redhat.com> On 10/03/2012 09:40 AM, Lukas Zapletal wrote: > Everything should be UNICODE only from the very first line;-) +1 Everything we get on input should be encoded as soon as possible. And internal code should work with unicode. -- Miroslav Suchy Red Hat Systems Management Engineering From lzap at redhat.com Wed Oct 3 07:49:50 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 3 Oct 2012 09:49:50 +0200 Subject: [katello-devel] Pulp warning: Unsupported characters for Yum In-Reply-To: <1407364073.5953946.1349216064336.JavaMail.root@redhat.com> References: <506B63EA.6010304@redhat.com> <1407364073.5953946.1349216064336.JavaMail.root@redhat.com> Message-ID: <20121003074950.GC4248@lzapx.brq.redhat.com> On Tue, Oct 02, 2012 at 06:14:24PM -0400, Og Maciel wrote: > > We may need to look into doing as pulp states above where we delete > > old > > repos and recreate with the new label. This will cause some pain > > because they will need to get re-synced and re-promoted ... a fairly > > annoying problem that I'm looking into currently. > > Shouldn't we then provide some kind of "migration" script to help out those who may be out of luck? It would be a "nice thing to do" imho. > -- The issue is I saw this warning message in this scenario: 1) Install CFSE10 2) Fetch some data from fake CDN, subscribe few repos (and those are just simple names like "Zoo Enterprise i386 6.1") 3) Upgrade to CFSE11 4) During the migration you see this warning message (actually it is hidden by katello-upgrade but I saw it) 5) Unfortunately I did not get to the state I could test the consumers if yum still work. I wonder why Pulp warns in this case, it looks our labels are okay, because org is ACME and env was set to "env" or "prod" or something like that. QA: Can you investigate more on upgrade scenarios? I have fixed a bug (part of the latest puddle) when we were NOT running pulp-migrate at all, therefore upgrade was not working at all. Now it should be finally working. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Oct 3 07:51:51 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 3 Oct 2012 09:51:51 +0200 Subject: [katello-devel] Fwd: [Pulp-list] i18n input In-Reply-To: <506BED87.7050504@redhat.com> References: <6D5C7F45-18A5-4695-A380-8783C47F5E34@redhat.com> <506B51DB.2000409@redhat.com> <20121003074002.GB4248@lzapx.brq.redhat.com> <506BED87.7050504@redhat.com> Message-ID: <20121003075151.GD4248@lzapx.brq.redhat.com> On Wed, Oct 03, 2012 at 09:47:19AM +0200, Miroslav Suchy wrote: > On 10/03/2012 09:40 AM, Lukas Zapletal wrote: > >Everything should be UNICODE only from the very first line;-) > > Everything we get on input should be encoded as soon as possible. > And internal code should work with unicode. And IPv6 as well :-) Cos Reuters said the other day EU has ran out of v4 addresses. So it must be true. :-P -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Wed Oct 3 08:15:39 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 03 Oct 2012 10:15:39 +0200 Subject: [katello-devel] Fwd: [Pulp-list] i18n input In-Reply-To: <20121003075151.GD4248@lzapx.brq.redhat.com> References: <6D5C7F45-18A5-4695-A380-8783C47F5E34@redhat.com> <506B51DB.2000409@redhat.com> <20121003074002.GB4248@lzapx.brq.redhat.com> <506BED87.7050504@redhat.com> <20121003075151.GD4248@lzapx.brq.redhat.com> Message-ID: <506BF42B.5060504@redhat.com> On 10/03/2012 09:51 AM, Lukas Zapletal wrote: > And IPv6 as well:-) And IDN as well. -- Miroslav Suchy Red Hat Systems Management Engineering From thomasmckay at redhat.com Wed Oct 3 11:38:32 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 3 Oct 2012 07:38:32 -0400 (EDT) Subject: [katello-devel] Deleting a manifest and pulp In-Reply-To: <20121003072721.GA4248@lzapx.brq.redhat.com> Message-ID: <1058369165.4152245.1349264312937.JavaMail.root@redhat.com> Note: I'll cut&paste replies to the wiki as the thread continues... ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, October 3, 2012 3:27:21 AM > Subject: Re: [katello-devel] Deleting a manifest and pulp > > On Tue, Oct 02, 2012 at 01:32:08PM -0400, Tom McKay wrote: > > > First, from a headpin point-of-view manifest deletion is trivial: > > Call candlepin and delete it, then remove references to the Red > > Hat provider subscriptions from activation keys. > > > > What happens to registered/subscribed consumers then? > The "what happens" is entirely in candlepin's hands. When a manifest is deleted, the entitlements are immediately revoked (and deleted) in candlepin. If the system tries to consume content, it will be denied. > > For katello it is much more complicated. In addition to cleaning > > out katello references such as activation keys, what happens to > > the pulp content? > > I would like to ask first what is the desired behavior for consumers. > If > they should be immediately removed from subscriptions, that is in the > next refresh call after 4 hours, then we could delete the repos from > Pulp. Best solution could be to defer this deletion 5 hours or > something > (maybe to schedule this if this is possible?) but then reimport could > cause issues (repoid would be occupied for some time). > > If there is a way of immediate unregistration then I think we could > delete the repos immediately. I am entirely fine with deleting the repos that correspond with the deleted subscriptions. However there are several aspects that concern me. >From a user experience point of view what if they then import a new manifest with products that correspond to the deleted ones? Here's an example: The development org needs RHEL w/ high performance mojo to reproduce and fix a bug. Since this is not a subscription they typically use they go to the customer portal and take the one subscription from the production org's distributor. The production org, being good corporate citizens, also download an updated manifest that no longer contains the "mojo" product. In effect, they have deleted this product. At the end of the fixing, development removes the mojo from their distributor and production adds it back. In effect, development has deleted the product and production has added it back. Should the production org have to re-enable, re-sync, re-promote, re-activation-key, re-system-template, re-everything for the product that returned? Or should the production org have to explicitly delete software that they no longer have access to? More burdensome for deletion but done explicitly through changesets, etc. Remember there are three cases where products are "deleted": 1) Delete entire manifest, 2) Remove a product from the manifest, 3) Product expires by date. I think the chance of a customer wishing to add back a deleted product could be high. So, while deleting all the pulp data on disk and all the katello references to it, is this the best answer or just the easiest? > > > What is the desired state of a Katello system after you delete a > > manifest? > > > I assume deleting all the referenced data from Katello databases and > backend engines. > > > Should we delete all the repos associated with the manifest after > > you > > delete it? > > Should we leave the content there but hide it? > > Should we leave the content there but note that it is unentitled? > > > I think so, and I think we should do it immediately (asking consumers > to > unregister ASAP). If we must wait 4 hours for technical reasons > (refresh), we must inform the user he can reimport after 5 hours and > defer deletions. > > > What happens when we re-import a manifest .. should it just stitch > > everything back up together? > > > Stitching in software development does not sound good at all :-) I'd > rather delete everything re-creating it. But this really depends on > what > are PM requirements are on this. Maybe they will really want > consumers > to stay subscribed until manifest is re-imported. > > My obligatory question follows: > > How does Satellite do it today? > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jbowes at redhat.com Wed Oct 3 12:21:38 2012 From: jbowes at redhat.com (James Bowes) Date: Wed, 3 Oct 2012 09:21:38 -0300 Subject: [katello-devel] Fwd: [Pulp-list] i18n input In-Reply-To: <506B51DB.2000409@redhat.com> References: <6D5C7F45-18A5-4695-A380-8783C47F5E34@redhat.com> <506B51DB.2000409@redhat.com> Message-ID: <20121003122138.GB19363@pipboy.redhat.com> On Tue, Oct 02, 2012 at 04:43:07PM -0400, Bryan Kearney wrote: > Comments? rpm enforces no such restriction, so you can look forward to enjoying changelog entries encoded in Big5 and other esoteric formats. You can probably borrow some code from yum for trying to convert those, and falling back to a missing char symbol or '?' if not. Is it safe to assume pulp will gain i18n/l10n shortly, too? > > -- bk > > > > -------- Original Message -------- > Subject: [Pulp-list] i18n input > Date: Tue, 2 Oct 2012 14:40:18 -0600 > From: Jason Connor > To: pulp-list at redhat.com > > Hi All, > > Lately we've been struggling with a rash of bugs related to i18n > input in Pulp. Python 2's unicode support is only so-so and whenever > we get non-ascii or non-utf-8 encoded strings, we tend to run into > trouble (the most common is problematic encoding seems to be > latin-1). Given that Python's str type is really just a byte array > with some built in smarts, it isn't really possible to guess what > the encoding might actually be. > > To address this issue, I propose that we make string encoding as > utf-8 a hard requirement on the server. To enforce this, we'll try > to decode all strings from utf-8 and any failures will get a 400 > server response with some sort of standardized message: utf-8 > encoded strings only (dummy), or something similar. > > Any thoughts? > > Jason L Connor > linear on freenode #pulp > http://pulpproject.org/ > RHCE: 805010912355231 > GPG Fingerprint: 2048R/CC4ED7C1 > > > > > _______________________________________________ > Pulp-list mailing list > Pulp-list at redhat.com > https://www.redhat.com/mailman/listinfo/pulp-list > > > _______________________________________________ > 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 jason.dobies at redhat.com Wed Oct 3 12:33:50 2012 From: jason.dobies at redhat.com (Jay Dobies) Date: Wed, 03 Oct 2012 08:33:50 -0400 Subject: [katello-devel] Fwd: [Pulp-list] i18n input In-Reply-To: <20121003122138.GB19363@pipboy.redhat.com> References: <6D5C7F45-18A5-4695-A380-8783C47F5E34@redhat.com> <506B51DB.2000409@redhat.com> <20121003122138.GB19363@pipboy.redhat.com> Message-ID: <506C30AE.2010405@redhat.com> On 10/03/2012 08:21 AM, James Bowes wrote: > On Tue, Oct 02, 2012 at 04:43:07PM -0400, Bryan Kearney wrote: >> Comments? > > rpm enforces no such restriction, so you can look forward to enjoying > changelog entries encoded in Big5 and other esoteric formats. You can > probably borrow some code from yum for trying to convert those, and > falling back to a missing char symbol or '?' if not. > > Is it safe to assume pulp will gain i18n/l10n shortly, too? Depends on what you mean. This conversation has been around handling data, but from the server standpoint there are very few places we're returning anything user-facing. So from the perspective of a REST API caller they are largely just getting data back and an exception structure to indicate what went wrong, they can do as they wish. From the CLI, support is mostly there as well. There are probably places we haven't run through gettext, but those are minimal at this point. We haven't started pulling together translations yet though. >> >> -- bk >> >> >> >> -------- Original Message -------- >> Subject: [Pulp-list] i18n input >> Date: Tue, 2 Oct 2012 14:40:18 -0600 >> From: Jason Connor >> To: pulp-list at redhat.com >> >> Hi All, >> >> Lately we've been struggling with a rash of bugs related to i18n >> input in Pulp. Python 2's unicode support is only so-so and whenever >> we get non-ascii or non-utf-8 encoded strings, we tend to run into >> trouble (the most common is problematic encoding seems to be >> latin-1). Given that Python's str type is really just a byte array >> with some built in smarts, it isn't really possible to guess what >> the encoding might actually be. >> >> To address this issue, I propose that we make string encoding as >> utf-8 a hard requirement on the server. To enforce this, we'll try >> to decode all strings from utf-8 and any failures will get a 400 >> server response with some sort of standardized message: utf-8 >> encoded strings only (dummy), or something similar. >> >> Any thoughts? >> >> Jason L Connor >> linear on freenode #pulp >> http://pulpproject.org/ >> RHCE: 805010912355231 >> GPG Fingerprint: 2048R/CC4ED7C1 >> >> >> >> >> _______________________________________________ >> Pulp-list mailing list >> Pulp-list at redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-list >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > -James > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > -- Jay Dobies Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org From bkearney at redhat.com Wed Oct 3 12:35:28 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 03 Oct 2012 08:35:28 -0400 Subject: [katello-devel] Pulp warning: Unsupported characters for Yum In-Reply-To: <1407364073.5953946.1349216064336.JavaMail.root@redhat.com> References: <1407364073.5953946.1349216064336.JavaMail.root@redhat.com> Message-ID: <506C3110.6070501@redhat.com> On 10/02/2012 06:14 PM, Og Maciel wrote: > ----- Original Message ----- >> From: "Mike McCune" >> To: katello-devel at redhat.com >> Sent: Tuesday, October 2, 2012 6:00:10 PM >> Subject: Re: [katello-devel] Pulp warning: Unsupported characters for Yum >> >> the Object Labeling solves it for new objects we create but for >> existing >> repositories with orgs/envs/products/repos with UTF8 characters we >> are >> out of luck because Pulp does *not* let you change the ID of the >> repo. >> We won't be able to migrate these over to the new scheme with a >> simple >> upgrade. >> >> We may need to look into doing as pulp states above where we delete >> old >> repos and recreate with the new label. This will cause some pain >> because they will need to get re-synced and re-promoted ... a fairly >> annoying problem that I'm looking into currently. > > Shouldn't we then provide some kind of "migration" script to help out those who may be out of luck? It would be a "nice thing to do" imho. > Ask on the list and internally how many folks have this issue. If there are none, I vote for not providing a fix until we run into it. -- bk From jbowes at redhat.com Wed Oct 3 12:55:33 2012 From: jbowes at redhat.com (James Bowes) Date: Wed, 3 Oct 2012 09:55:33 -0300 Subject: [katello-devel] Fwd: [Pulp-list] i18n input In-Reply-To: <506C30AE.2010405@redhat.com> References: <6D5C7F45-18A5-4695-A380-8783C47F5E34@redhat.com> <506B51DB.2000409@redhat.com> <20121003122138.GB19363@pipboy.redhat.com> <506C30AE.2010405@redhat.com> Message-ID: <20121003125533.GC19363@pipboy.redhat.com> On Wed, Oct 03, 2012 at 08:33:50AM -0400, Jay Dobies wrote: > On 10/03/2012 08:21 AM, James Bowes wrote: > >On Tue, Oct 02, 2012 at 04:43:07PM -0400, Bryan Kearney wrote: > >>Comments? > > > >rpm enforces no such restriction, so you can look forward to enjoying > >changelog entries encoded in Big5 and other esoteric formats. You can > >probably borrow some code from yum for trying to convert those, and > >falling back to a missing char symbol or '?' if not. > > > >Is it safe to assume pulp will gain i18n/l10n shortly, too? > > Depends on what you mean. > > This conversation has been around handling data, but from the server It has, but the data it's about is data from non english speaking users. You can't support them properly without doing i18n/l10n right, too. > standpoint there are very few places we're returning anything > user-facing. So from the perspective of a REST API caller they are > largely just getting data back and an exception structure to > indicate what went wrong, they can do as they wish. > There's a few strings in the server code marked for i18n. Some that get logged are, for example, yet others are not. > From the CLI, support is mostly there as well. There are probably > places we haven't run through gettext, but those are minimal at this > point. We haven't started pulling together translations yet though. > You should start :) I can see a number of places where the code is doing the wrong thing with gettext. platform/src/pulp/client/extensions/exceptions.py line 108 is a good example. That string won't be included in your po files. i18n is messy, hard, and invasive. Even if you don't have localizations, you can still make a dummy locale with some nonsense strings (I tend to use en_CA), to verify your strings are extracted properly, and replaced properly, too. Best to start as soon as possible, and get the pain over with. > >> > >>-- bk > >> > >> > >> > >>-------- Original Message -------- > >>Subject: [Pulp-list] i18n input > >>Date: Tue, 2 Oct 2012 14:40:18 -0600 > >>From: Jason Connor > >>To: pulp-list at redhat.com > >> > >>Hi All, > >> > >>Lately we've been struggling with a rash of bugs related to i18n > >>input in Pulp. Python 2's unicode support is only so-so and whenever > >>we get non-ascii or non-utf-8 encoded strings, we tend to run into > >>trouble (the most common is problematic encoding seems to be > >>latin-1). Given that Python's str type is really just a byte array > >>with some built in smarts, it isn't really possible to guess what > >>the encoding might actually be. > >> > >>To address this issue, I propose that we make string encoding as > >>utf-8 a hard requirement on the server. To enforce this, we'll try > >>to decode all strings from utf-8 and any failures will get a 400 > >>server response with some sort of standardized message: utf-8 > >>encoded strings only (dummy), or something similar. > >> > >>Any thoughts? > >> > >>Jason L Connor > >>linear on freenode #pulp > >>http://pulpproject.org/ > >>RHCE: 805010912355231 > >>GPG Fingerprint: 2048R/CC4ED7C1 > >> > >> > >> > >> > >>_______________________________________________ > >>Pulp-list mailing list > >>Pulp-list at redhat.com > >>https://www.redhat.com/mailman/listinfo/pulp-list > >> > >> > >>_______________________________________________ > >>katello-devel mailing list > >>katello-devel at redhat.com > >>https://www.redhat.com/mailman/listinfo/katello-devel > > > >-James > > > > > > > >_______________________________________________ > >katello-devel mailing list > >katello-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/katello-devel > > > > > -- > Jay Dobies > Freenode: jdob @ #pulp > http://pulpproject.org | http://blog.pulpproject.org > > _______________________________________________ > 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 jsherril at redhat.com Wed Oct 3 13:01:49 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 03 Oct 2012 09:01:49 -0400 Subject: [katello-devel] Deleting a manifest and pulp In-Reply-To: <20121003072721.GA4248@lzapx.brq.redhat.com> References: <17886372.3826238.1349198713002.JavaMail.root@redhat.com> <639511348.3828288.1349199128537.JavaMail.root@redhat.com> <20121003072721.GA4248@lzapx.brq.redhat.com> Message-ID: <506C373D.3050800@redhat.com> On 10/03/2012 03:27 AM, Lukas Zapletal wrote: > On Tue, Oct 02, 2012 at 01:32:08PM -0400, Tom McKay wrote: > >> First, from a headpin point-of-view manifest deletion is trivial: Call candlepin and delete it, then remove references to the Red Hat provider subscriptions from activation keys. >> > What happens to registered/subscribed consumers then? > >> For katello it is much more complicated. In addition to cleaning out katello references such as activation keys, what happens to the pulp content? > I would like to ask first what is the desired behavior for consumers. If > they should be immediately removed from subscriptions, that is in the > next refresh call after 4 hours, then we could delete the repos from > Pulp. Best solution could be to defer this deletion 5 hours or something > (maybe to schedule this if this is possible?) but then reimport could > cause issues (repoid would be occupied for some time). > > If there is a way of immediate unregistration then I think we could > delete the repos immediately. > >> What is the desired state of a Katello system after you delete a >> manifest? >> > I assume deleting all the referenced data from Katello databases and > backend engines. > >> Should we delete all the repos associated with the manifest after you >> delete it? >> Should we leave the content there but hide it? >> Should we leave the content there but note that it is unentitled? >> > I think so, and I think we should do it immediately (asking consumers to > unregister ASAP). If we must wait 4 hours for technical reasons > (refresh), we must inform the user he can reimport after 5 hours and > defer deletions. > >> What happens when we re-import a manifest .. should it just stitch >> everything back up together? >> > Stitching in software development does not sound good at all :-) I'd > rather delete everything re-creating it. But this really depends on what > are PM requirements are on this. Maybe they will really want consumers > to stay subscribed until manifest is re-imported. > > My obligatory question follows: > > How does Satellite do it today? > Satellite today doesn't have the idea of deleting a 'manifest' or satellite cert in this case. You can upload new manifests, but the products and repos are never deleted unless the customer runs a special script to delete red hat content. Even they do that their custom channels/repos created from red hat content still exist. I'm a -1 for deleting content and a +1 for 'disabling' it, allowing some way to delete, and stitching it back up if a new manifest is uploaded. -Justin From daviddavis at redhat.com Wed Oct 3 13:43:04 2012 From: daviddavis at redhat.com (David Davis) Date: Wed, 3 Oct 2012 09:43:04 -0400 (EDT) Subject: [katello-devel] Breaking translation bug In-Reply-To: <84471491.6264626.1349270595999.JavaMail.root@redhat.com> Message-ID: <1339117051.6293104.1349271784952.JavaMail.root@redhat.com> So there's a bug that's happening only in Jenkins where we're getting these failures: Changeset Changeset should adding content fail adding content from not promoted repository should fail on add package Failure/Error: lambda { @changeset.add_package!("pack", @prod) }. expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> # ./spec/models/changeset_spec.rb:175 The problem is that in the controller we're setting I18n.locale to current_user's default_locale and we're mocking current_user in a lot of cases so the locale just ends up being some mock-type data. Then when it runs the model specs, it fails in jenkins because the locale is not en (for English). It happens only on some systems because it depends on which order the specs are run (model then controller vs. controller then model). There's a few different way to fix this from happening, each with their faults: 1. Just set the default_locale to en for the user mocked models. Problem: if we ever end up testing non-English locales or if someone forgets to stub #default_locale, the changeset specs will break again. 2. Reset the locale before each rspec test. Problem: I am not aware of a good place to do this. 3. Reset the locale on an as-needed basis. Problem: This is kind of a hack but then again it's probably a bad idea for any spec to assume the locale is set to en. Any thoughts? Thanks. David From jrist at redhat.com Wed Oct 3 13:50:45 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 03 Oct 2012 07:50:45 -0600 Subject: [katello-devel] Breaking translation bug In-Reply-To: <1339117051.6293104.1349271784952.JavaMail.root@redhat.com> References: <84471491.6264626.1349270595999.JavaMail.root@redhat.com> <1339117051.6293104.1349271784952.JavaMail.root@redhat.com> Message-ID: <506C42B5.7060501@redhat.com> On Wed 03 Oct 2012 07:43:04 AM MDT, David Davis wrote: > So there's a bug that's happening only in Jenkins where we're getting these failures: > > Changeset Changeset should adding content fail adding content from not promoted repository should fail on add package > Failure/Error: lambda { @changeset.add_package!("pack", @prod) }. > expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> > # ./spec/models/changeset_spec.rb:175 > > The problem is that in the controller we're setting I18n.locale to current_user's default_locale and we're mocking current_user in a lot of cases so the locale just ends up being some mock-type data. Then when it runs the model specs, it fails in jenkins because the locale is not en (for English). It happens only on some systems because it depends on which order the specs are run (model then controller vs. controller then model). > > There's a few different way to fix this from happening, each with their faults: > > 1. Just set the default_locale to en for the user mocked models. Problem: if we ever end up testing non-English locales or if someone forgets to stub #default_locale, the changeset specs will break again. > > 2. Reset the locale before each rspec test. Problem: I am not aware of a good place to do this. > > 3. Reset the locale on an as-needed basis. Problem: This is kind of a hack but then again it's probably a bad idea for any spec to assume the locale is set to en. > > Any thoughts? > > Thanks. > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Are those the only options? I'd like if we didn't assume this was all English, so 3 looks the best... -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From daviddavis at redhat.com Wed Oct 3 14:02:43 2012 From: daviddavis at redhat.com (David Davis) Date: Wed, 3 Oct 2012 10:02:43 -0400 (EDT) Subject: [katello-devel] Breaking translation bug In-Reply-To: <506C42B5.7060501@redhat.com> Message-ID: <337848308.6327916.1349272963320.JavaMail.root@redhat.com> Eric brought up another option: have the test script run the models/controllers/etc separately. Then we wouldn't have globals bleed over from the controllers to models and vice versa. Also, there might be other options as well that I may not be thinking of. David ----- Original Message ----- From: "Jason Rist" To: "David Davis" Cc: "katello-devel" Sent: Wednesday, October 3, 2012 9:50:45 AM Subject: Re: [katello-devel] Breaking translation bug On Wed 03 Oct 2012 07:43:04 AM MDT, David Davis wrote: > So there's a bug that's happening only in Jenkins where we're getting these failures: > > Changeset Changeset should adding content fail adding content from not promoted repository should fail on add package > Failure/Error: lambda { @changeset.add_package!("pack", @prod) }. > expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> > # ./spec/models/changeset_spec.rb:175 > > The problem is that in the controller we're setting I18n.locale to current_user's default_locale and we're mocking current_user in a lot of cases so the locale just ends up being some mock-type data. Then when it runs the model specs, it fails in jenkins because the locale is not en (for English). It happens only on some systems because it depends on which order the specs are run (model then controller vs. controller then model). > > There's a few different way to fix this from happening, each with their faults: > > 1. Just set the default_locale to en for the user mocked models. Problem: if we ever end up testing non-English locales or if someone forgets to stub #default_locale, the changeset specs will break again. > > 2. Reset the locale before each rspec test. Problem: I am not aware of a good place to do this. > > 3. Reset the locale on an as-needed basis. Problem: This is kind of a hack but then again it's probably a bad idea for any spec to assume the locale is set to en. > > Any thoughts? > > Thanks. > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Are those the only options? I'd like if we didn't assume this was all English, so 3 looks the best... -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From bbuckingham at redhat.com Wed Oct 3 14:03:37 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Wed, 03 Oct 2012 10:03:37 -0400 Subject: [katello-devel] Breaking translation bug In-Reply-To: <1339117051.6293104.1349271784952.JavaMail.root@redhat.com> References: <1339117051.6293104.1349271784952.JavaMail.root@redhat.com> Message-ID: <506C45B9.8080301@redhat.com> On 10/03/2012 09:43 AM, David Davis wrote: > So there's a bug that's happening only in Jenkins where we're getting these failures: > > Changeset Changeset should adding content fail adding content from not promoted repository should fail on add package > Failure/Error: lambda { @changeset.add_package!("pack", @prod) }. > expected ActiveRecord::RecordInvalid with message matching /has not been promoted/, got #.activerecord.errors.messages.record_invalid> > # ./spec/models/changeset_spec.rb:175 > > The problem is that in the controller we're setting I18n.locale to current_user's default_locale and we're mocking current_user in a lot of cases so the locale just ends up being some mock-type data. Then when it runs the model specs, it fails in jenkins because the locale is not en (for English). It happens only on some systems because it depends on which order the specs are run (model then controller vs. controller then model). > > There's a few different way to fix this from happening, each with their faults: > > 1. Just set the default_locale to en for the user mocked models. Problem: if we ever end up testing non-English locales or if someone forgets to stub #default_locale, the changeset specs will break again. > > 2. Reset the locale before each rspec test. Problem: I am not aware of a good place to do this. > > 3. Reset the locale on an as-needed basis. Problem: This is kind of a hack but then again it's probably a bad idea for any spec to assume the locale is set to en. > > Any thoughts? > > Thanks. > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I'd probably lean towards #2. (As you mention, the key is knowing 'where' this can be specified. Perhaps as part of the helper used to define the user (real or mock).) At least then, we know the behavior should be expected to be the same for all tests. In general, testing or verifying using different locales seems like it could be handled differently. From an rspec point of view, not sure what we'd really be looking for. With the exception of tests associated with an actual user where we want to make sure that changing the user's locale generates different results, it seems like for locale, we are really most interested in knowing whether all strings are translated and that those strings are correct (which doesn't seem like something for rspec). From tkolhar at redhat.com Wed Oct 3 15:13:18 2012 From: tkolhar at redhat.com (Tazim Kolhar) Date: Wed, 3 Oct 2012 11:13:18 -0400 (EDT) Subject: [katello-devel] Headpin packaging issue In-Reply-To: <909317239.2893846.1349276843688.JavaMail.root@redhat.com> Message-ID: <327223085.2895342.1349277198416.JavaMail.root@redhat.com> Hi all, I have been following the doc : https://fedorahosted.org/katello/wiki/Install for headpin (sam1.2 official) installation and configuration. The repo location used : http://fedorapeople.org/groups/katello/releases/yum/nightly/RHEL/6Server/x86_64/ today, on #systemengine it was found that there are some packaging issue. Please, provide updates when the issue is fixed. Also, please provide appropriate steps for installation and configuration if there are any changes apart from the doc above. Please, update accordingly. need to fix the headpin-cli-automation tests issues . cannot proceed becoz of the packaging issue . Thanks & Regards, Tazim. From tkolhar at redhat.com Wed Oct 3 15:18:03 2012 From: tkolhar at redhat.com (Tazim Kolhar) Date: Wed, 3 Oct 2012 11:18:03 -0400 (EDT) Subject: [katello-devel] Headpin packaging issue In-Reply-To: <327223085.2895342.1349277198416.JavaMail.root@redhat.com> Message-ID: <1544191581.2896931.1349277483067.JavaMail.root@redhat.com> Hi all, I have been following the doc : https://fedorahosted.org/katello/wiki/Install for headpin (sam1.2 official) installation and configuration. The repo location used : http://fedorapeople.org/groups/katello/releases/yum/nightly/RHEL/6Server/x86_64/ today, on #systemengine it was found that there are some packaging issue. Please, provide updates when the issue is fixed. Also, please provide appropriate steps for installation and configuration if there are any changes apart from the doc above. Please, update accordingly. need to fix the headpin-cli-automation tests issues . cannot proceed becoz of the packaging issue . Thanks & Regards, Tazim. From paji at redhat.com Wed Oct 3 15:47:01 2012 From: paji at redhat.com (Partha Aji) Date: Wed, 3 Oct 2012 11:47:01 -0400 (EDT) Subject: [katello-devel] Breaking translation bug In-Reply-To: <337848308.6327916.1349272963320.JavaMail.root@redhat.com> Message-ID: <217814094.5702442.1349279221329.JavaMail.root@redhat.com> ----- Original Message ----- > From: "David Davis" > To: jrist at redhat.com > Cc: "katello-devel" > Sent: Wednesday, October 3, 2012 10:02:43 AM > Subject: Re: [katello-devel] Breaking translation bug > > Eric brought up another option: have the test script run the > models/controllers/etc separately. Then we wouldn't have globals > bleed over from the controllers to models and vice versa. > > Also, there might be other options as well that I may not be thinking > of. > > David > > > ----- Original Message ----- > From: "Jason Rist" > To: "David Davis" > Cc: "katello-devel" > Sent: Wednesday, October 3, 2012 9:50:45 AM > Subject: Re: [katello-devel] Breaking translation bug > > On Wed 03 Oct 2012 07:43:04 AM MDT, David Davis wrote: > > So there's a bug that's happening only in Jenkins where we're > > getting these failures: > > > > Changeset Changeset should adding content fail adding content from > > not promoted repository should fail on add package > > Failure/Error: lambda { @changeset.add_package!("pack", @prod) > > }. > > expected ActiveRecord::RecordInvalid with message matching > > /has not been promoted/, got # > translation missing: > > User_#.activerecord.errors.messages.record_invalid> > > # ./spec/models/changeset_spec.rb:175 > > > > The problem is that in the controller we're setting I18n.locale to > > current_user's default_locale and we're mocking current_user in a > > lot of cases so the locale just ends up being some mock-type data. > > Then when it runs the model specs, it fails in jenkins because the > > locale is not en (for English). It happens only on some systems > > because it depends on which order the specs are run (model then > > controller vs. controller then model). > > > > There's a few different way to fix this from happening, each with > > their faults: > > > > 1. Just set the default_locale to en for the user mocked models. > > Problem: if we ever end up testing non-English locales or if > > someone forgets to stub #default_locale, the changeset specs will > > break again. > > > > 2. Reset the locale before each rspec test. Problem: I am not aware > > of a good place to do this. > > > > 3. Reset the locale on an as-needed basis. Problem: This is kind of > > a hack but then again it's probably a bad idea for any spec to > > assume the locale is set to en. > > > > Any thoughts? > > > > Thanks. > > > > David > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > Are those the only options? I'd like if we didn't assume this was all > English, so 3 looks the best... > I 'd go with 2 ideally, but even 1 is ok as long as resetting the default locale is simple to do and documented. I mean 99% of the tests are going to be en_us. Not worth spending time figuring out. The special cases where we test i18n we should have some simple way to reset the locale. Not worth spending much more time on those test IMO. Partha From bkearney at redhat.com Wed Oct 3 17:06:37 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 03 Oct 2012 13:06:37 -0400 Subject: [katello-devel] Deleting a manifest and pulp In-Reply-To: <20121003072721.GA4248@lzapx.brq.redhat.com> References: <17886372.3826238.1349198713002.JavaMail.root@redhat.com> <639511348.3828288.1349199128537.JavaMail.root@redhat.com> <20121003072721.GA4248@lzapx.brq.redhat.com> Message-ID: <506C709D.7010400@redhat.com> On 10/03/2012 03:27 AM, Lukas Zapletal wrote: > On Tue, Oct 02, 2012 at 01:32:08PM -0400, Tom McKay wrote: > >> First, from a headpin point-of-view manifest deletion is trivial: Call candlepin and delete it, then remove references to the Red Hat provider subscriptions from activation keys. >> > > What happens to registered/subscribed consumers then? If a manifest is removed, all machines should loose their susbcriptions and be unable to get updates from CFSE. The machine should still be registered with CFSE. > >> For katello it is much more complicated. In addition to cleaning out katello references such as activation keys, what happens to the pulp content? > > I would like to ask first what is the desired behavior for consumers. If > they should be immediately removed from subscriptions, that is in the > next refresh call after 4 hours, then we could delete the repos from > Pulp. Best solution could be to defer this deletion 5 hours or something > (maybe to schedule this if this is possible?) but then reimport could > cause issues (repoid would be occupied for some time). I have assumed that the consumer is immediately removed on the server, and at hte next yum call or checkin hte client would reflect it. > > If there is a way of immediate unregistration then I think we could > delete the repos immediately. > >> What is the desired state of a Katello system after you delete a >> manifest? >> > I assume deleting all the referenced data from Katello databases and > backend engines. > >> Should we delete all the repos associated with the manifest after you >> delete it? >> Should we leave the content there but hide it? >> Should we leave the content there but note that it is unentitled? >> > I think so, and I think we should do it immediately (asking consumers to > unregister ASAP). If we must wait 4 hours for technical reasons > (refresh), we must inform the user he can reimport after 5 hours and > defer deletions. > >> What happens when we re-import a manifest .. should it just stitch >> everything back up together? >> > Stitching in software development does not sound good at all :-) I'd > rather delete everything re-creating it. But this really depends on what > are PM requirements are on this. Maybe they will really want consumers > to stay subscribed until manifest is re-imported. > > My obligatory question follows: > > How does Satellite do it today? > Can we delete from all but library? Or, perhaps, just leave it orphaned? where it is. -- bk From jomara at redhat.com Wed Oct 3 18:11:21 2012 From: jomara at redhat.com (Jordan OMara) Date: Wed, 3 Oct 2012 14:11:21 -0400 Subject: [katello-devel] Headpin packaging issue In-Reply-To: <1544191581.2896931.1349277483067.JavaMail.root@redhat.com> References: <327223085.2895342.1349277198416.JavaMail.root@redhat.com> <1544191581.2896931.1349277483067.JavaMail.root@redhat.com> Message-ID: <20121003181121.GQ6046@redhat.com> On 03/10/12 11:18 -0400, Tazim Kolhar wrote: >Hi all, > > I have been following the doc : https://fedorahosted.org/katello/wiki/Install > for headpin (sam1.2 official) installation and configuration. > The repo location used : http://fedorapeople.org/groups/katello/releases/yum/nightly/RHEL/6Server/x86_64/ > > today, on #systemengine it was found that there are some packaging issue. > Please, provide updates when the issue is fixed. > There is an issue with headpin-cli sticking around and not being correctly obsoleted by katello-cli. I will get this addressed tomorrow -- 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 thomasmckay at redhat.com Wed Oct 3 19:09:01 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 3 Oct 2012 15:09:01 -0400 (EDT) Subject: [katello-devel] Allowing user names w/ ., _, and @ Message-ID: <184685733.4323437.1349291341699.JavaMail.root@redhat.com> Speak up now if you know of problems allowing user names containing ., _, and @ in them. foo_bar at acme.org From inecas at redhat.com Wed Oct 3 19:46:40 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 03 Oct 2012 21:46:40 +0200 Subject: [katello-devel] Allowing user names w/ ., _, and @ In-Reply-To: <184685733.4323437.1349291341699.JavaMail.root@redhat.com> References: <184685733.4323437.1349291341699.JavaMail.root@redhat.com> Message-ID: <506C9620.8030605@redhat.com> On 10/03/2012 09:09 PM, Tom McKay wrote: > Speak up now if you know of problems allowing user names containing ., _, and @ in them. > foo_bar at acme.org I don't have problems with it. But it seems Pulp has (at least 1.1.12): InvalidDocument: key 'me at inec.us' must not contain '.' Or is this already known issue and we have a plan for this? -- Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From dmitri at redhat.com Thu Oct 4 10:20:36 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 04 Oct 2012 11:20:36 +0100 Subject: [katello-devel] Allowing user names w/ ., _, and @ In-Reply-To: <184685733.4323437.1349291341699.JavaMail.root@redhat.com> References: <184685733.4323437.1349291341699.JavaMail.root@redhat.com> Message-ID: <506D62F4.1010105@redhat.com> On 03/10/12 08:09 PM, Tom McKay wrote: > Speak up now if you know of problems allowing user names containing ., _, and @ in them. > foo_bar at acme.org > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel if the plan is to have emails as user names, I'd also include '+' to that list. -d From thomasmckay at redhat.com Thu Oct 4 17:26:57 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 4 Oct 2012 13:26:57 -0400 (EDT) Subject: [katello-devel] updating candlepin in http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/ Message-ID: <927267911.4681835.1349371617933.JavaMail.root@redhat.com> The F16 and F17 versions of candlepin are being updated from 0.7.8 to 0.7.12. The RHEL version is missing a dependency in koji and will need to wait. The newer version is now in http://koji.katello.org/releases/yum/katello-candlepin and will (hopefully) make its way to http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/ on Monday. From omaciel at redhat.com Thu Oct 4 18:02:11 2012 From: omaciel at redhat.com (Og Maciel) Date: Thu, 4 Oct 2012 14:02:11 -0400 (EDT) Subject: [katello-devel] updating candlepin in http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/ In-Reply-To: <927267911.4681835.1349371617933.JavaMail.root@redhat.com> Message-ID: <617957282.7467181.1349373731293.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tom McKay" > To: "katello-devel" > Sent: Thursday, October 4, 2012 1:26:57 PM > Subject: [katello-devel] updating candlepin in http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/ > > The F16 and F17 versions of candlepin are being updated from 0.7.8 to > 0.7.12. The RHEL version is missing a dependency in koji and will > need to wait. Wait for? -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.646.707.7723 irc: omaciel From gregswift at gmail.com Thu Oct 4 18:10:03 2012 From: gregswift at gmail.com (Greg Swift) Date: Thu, 4 Oct 2012 13:10:03 -0500 Subject: [katello-devel] slightly off topic and cross posted: setting up apache+passenger for puppet Message-ID: pardon the off topic cross post, was told it would hurt to ask both group and since katello/pulp is the main reason (from my understanding) that passenger finally made its way into fedora/epel I figured you guys were the best people to ask. So i was updating my 'apache+passenger+puppet' walk through [1] to utilize the new epel passenger package and there is a set of steps I wonder if there is a 'better' way to do. From my write up it specifically states: Create rack directory structure mkdir -p /usr/share/puppet/rack/puppetmasterd/{public,tmp} Copy config.ru fromthe puppet source dir cp /usr/share/puppet/ext/rack/files/config.ru /usr/share/puppet/rack/puppetmasterd/ Set permissions on the previous items chown -R puppet: /usr/share/puppet/rack/puppetmasterd/ Is there a 'better' way/path/etc? thanks -greg [1] http://nytefyre.net/2012/10/puppet-via-apache-using-passenger-from-epel/ From thomasmckay at redhat.com Thu Oct 4 18:37:21 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 4 Oct 2012 14:37:21 -0400 (EDT) Subject: [katello-devel] updating candlepin in http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/ In-Reply-To: <617957282.7467181.1349373731293.JavaMail.root@redhat.com> Message-ID: <283463057.4702512.1349375841864.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Og Maciel" > To: "Tom McKay" > Cc: "katello-devel" > Sent: Thursday, October 4, 2012 2:02:11 PM > Subject: Re: [katello-devel] updating candlepin in > http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/ > > ----- Original Message ----- > > From: "Tom McKay" > > To: "katello-devel" > > Sent: Thursday, October 4, 2012 1:26:57 PM > > Subject: [katello-devel] updating candlepin in > > http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/ > > > > The F16 and F17 versions of candlepin are being updated from 0.7.8 > > to > > 0.7.12. The RHEL version is missing a dependency in koji and will > > need to wait. > > Wait for? It will need to wait for those with the power to build the missing dep(s) in our koji. > -- > Og Maciel > > Senior QA Engineer > Red Hat, Inc. > +1.646.707.7723 > irc: omaciel > From daviddavis at redhat.com Fri Oct 5 21:51:07 2012 From: daviddavis at redhat.com (David Davis) Date: Fri, 5 Oct 2012 17:51:07 -0400 (EDT) Subject: [katello-devel] Python variable names In-Reply-To: <515515314.7800828.1349473528893.JavaMail.root@redhat.com> Message-ID: <2129901128.7801786.1349473867834.JavaMail.root@redhat.com> I have a quick Python question. In our Python guide, it says to use snake case for variable names but for function arguments, it seems like we're mostly using camel case. Here's an example from cli/src/katello/client/api/environment.py: def environments_by_org(self, orgId): path = "/api/organizations/%s/environments" % orgId envs = self.server.GET(path)[1] return envs Here you see orgId instead of org_id. Is this code out of date or are we using camel case for argument variables and snake case for non-argument variables? Thanks. David From lzap at redhat.com Mon Oct 8 07:53:45 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 8 Oct 2012 09:53:45 +0200 Subject: [katello-devel] updating candlepin in http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/ In-Reply-To: <283463057.4702512.1349375841864.JavaMail.root@redhat.com> References: <617957282.7467181.1349373731293.JavaMail.root@redhat.com> <283463057.4702512.1349375841864.JavaMail.root@redhat.com> Message-ID: <20121008075345.GD4220@lzapx.brq.redhat.com> It looks like someone has empowered you: http://koji.katello.org/koji/packageinfo?packageID=97 Good work! :-) LZ On Thu, Oct 04, 2012 at 02:37:21PM -0400, Tom McKay wrote: > > > ----- Original Message ----- > > From: "Og Maciel" > > To: "Tom McKay" > > Cc: "katello-devel" > > Sent: Thursday, October 4, 2012 2:02:11 PM > > Subject: Re: [katello-devel] updating candlepin in > > http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/ > > > > ----- Original Message ----- > > > From: "Tom McKay" > > > To: "katello-devel" > > > Sent: Thursday, October 4, 2012 1:26:57 PM > > > Subject: [katello-devel] updating candlepin in > > > http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/ > > > > > > The F16 and F17 versions of candlepin are being updated from 0.7.8 > > > to > > > 0.7.12. The RHEL version is missing a dependency in koji and will > > > need to wait. > > > > Wait for? > > It will need to wait for those with the power to build the missing dep(s) in our koji. > > > -- > > Og Maciel > > > > Senior QA Engineer > > Red Hat, Inc. > > +1.646.707.7723 > > 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 msuchy at redhat.com Mon Oct 8 10:10:39 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 08 Oct 2012 12:10:39 +0200 Subject: [katello-devel] Python variable names In-Reply-To: <2129901128.7801786.1349473867834.JavaMail.root@redhat.com> References: <2129901128.7801786.1349473867834.JavaMail.root@redhat.com> Message-ID: <5072A69F.3090901@redhat.com> On 10/05/2012 11:51 PM, David Davis wrote: > Here you see orgId instead of org_id. Is this code out of date or are we using camel case for argument variables and snake case for non-argument variables? Because nobody is perfect. It is most probably written by somebody whose mother language is Java. This specific line is there from day zero. Yes. org_id should be correct form. -- Miroslav Suchy Red Hat Systems Management Engineering From inecas at redhat.com Mon Oct 8 17:56:32 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 08 Oct 2012 19:56:32 +0200 Subject: [katello-devel] The final answer for gettext stings interpolation, the universe and everything. Message-ID: <507313D0.1060309@redhat.com> Hello team, There were some discussion about interpolating the gettext strings in history of Katello (for example here [1] or [2] here). But still there might be some doubts on it. The final answer is (not 42): _("A string like #{this} will never ever be translated. Gettext just skips it"). Well, this is not the complete answer. What's missing is a script that will detect this problems automagically. So here it is (see the attachment). I will fix the rest of the strings tomorrow (thanks Mirek for already fixing major part of them) and add this script to our builds, refusing to build if there is a problem) so that no other interpolation will leak into our code base. [1] - https://www.redhat.com/archives/katello-devel/2011-August/msg00138.html [2] - https://www.redhat.com/archives/katello-devel/2012-September/msg00253.html -- Ivan -------------- next part -------------- A non-text attachment was scrubbed... Name: check-gettext.sh Type: application/x-shellscript Size: 520 bytes Desc: not available URL: From msuchy at redhat.com Tue Oct 9 10:15:21 2012 From: msuchy at redhat.com (=?ISO-8859-2?Q?Miroslav_Such=FD?=) Date: Tue, 09 Oct 2012 12:15:21 +0200 Subject: [katello-devel] Koji Message-ID: <5073F939.3060906@redhat.com> Hi team, we finally have public instance of Koji: http://koji.katello.org/ Documentation is at: https://fedorahosted.org/katello/wiki/Koji Those of you who are familiar with this document already I will just pin point the change: https://fedorahosted.org/katello/wiki/Koji#Repos Here ^^^ is definition of cronjob script for syncing to: http://fedorapeople.org/groups/katello/ Although you can use yum repositories directly from Koji, please prefer http://fedorapeople.org/groups/katello/ because IP traffic on Koji itself is not unlimited. Enjoy. -- Miroslav Suchy Red Hat Systems Management Engineering From lzap at redhat.com Tue Oct 9 11:38:15 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 9 Oct 2012 13:38:15 +0200 Subject: [katello-devel] Koji In-Reply-To: <5073F939.3060906@redhat.com> References: <5073F939.3060906@redhat.com> Message-ID: <20121009113815.GA14504@lzapx.brq.redhat.com> On Tue, Oct 09, 2012 at 12:15:21PM +0200, Miroslav Suchy wrote: > Although you can use yum repositories directly from Koji, please prefer > http://fedorapeople.org/groups/katello/ > because IP traffic on Koji itself is not unlimited. The repos are mirrored several times a day (right after repogen on Koji) and also we keep 2-3 months history on fedorapeople.org site, therefore there is less chance you get 404 when your metadata are not up to date. If you are in gitkatello fedora account group, you have write access to these files by the way. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Oct 10 07:06:55 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 10 Oct 2012 09:06:55 +0200 Subject: [katello-devel] Koji In-Reply-To: <20121009113815.GA14504@lzapx.brq.redhat.com> References: <5073F939.3060906@redhat.com> <20121009113815.GA14504@lzapx.brq.redhat.com> Message-ID: <20121010070655.GA4202@lzapx.brq.redhat.com> Hi all, I have put all our fake repos here: http://fedorapeople.org/groups/katello/fakerepos/ This should be single point of our fake repos now. Please add your own, copy to /project/katello/fakerepos on fedorahosted and then run fix-perms script to set correct group to "gitkatello". Or ping me I can copy there for you. Please put only "stable" and final versions of your fake repositories there. :-) LZ On Tue, Oct 09, 2012 at 01:38:15PM +0200, Lukas Zapletal wrote: > On Tue, Oct 09, 2012 at 12:15:21PM +0200, Miroslav Suchy wrote: > > Although you can use yum repositories directly from Koji, please prefer > > http://fedorapeople.org/groups/katello/ > > because IP traffic on Koji itself is not unlimited. > > The repos are mirrored several times a day (right after repogen on Koji) > and also we keep 2-3 months history on fedorapeople.org site, therefore > there is less chance you get 404 when your metadata are not up to date. > > If you are in gitkatello fedora account group, you have write access to > these files by the way. > > LZ > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > 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 Oct 10 09:16:27 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 10 Oct 2012 11:16:27 +0200 Subject: [katello-devel] Testing migrations Message-ID: <20121010091626.GC4202@lzapx.brq.redhat.com> Hello, when you are changing/adding a migration, please test it properly: rake db:migrate rake db:migrate VERSION=0 rake db:migrate Often down methods are not working properly. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Wed Oct 10 12:06:59 2012 From: daviddavis at redhat.com (David Davis) Date: Wed, 10 Oct 2012 08:06:59 -0400 (EDT) Subject: [katello-devel] Testing migrations In-Reply-To: <20121010091626.GC4202@lzapx.brq.redhat.com> Message-ID: <744110515.9756703.1349870819694.JavaMail.root@redhat.com> I always just run "rake db:migrate:redo" so that I don't lose all my data. David ----- Original Message ----- From: "Lukas Zapletal" To: katello-devel at redhat.com Sent: Wednesday, October 10, 2012 5:16:27 AM Subject: [katello-devel] Testing migrations Hello, when you are changing/adding a migration, please test it properly: rake db:migrate rake db:migrate VERSION=0 rake db:migrate Often down methods are not working properly. LZ -- 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 Oct 10 12:31:05 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 10 Oct 2012 14:31:05 +0200 Subject: [katello-devel] Branching of Katello 1.1 tomorrow (Oct 11) Message-ID: <20121010123105.GE4202@lzapx.brq.redhat.com> Team, as a Katello 1.1 release nanny I will be branching tomorrow. Quickly looking on our pull requests, we did a good job and there are only 8, from which 4 are bugs, one DNM. Please walk trough them, comment, merge. I'd like NOT to have foreman integration change in the release. Since there is live discussion in the request, I guess it will take some time to merge it, which is good for me. Therefore if the nightly build tomorrow will look fine, I will go ahead and start the process of branching. Comments? Opinions? Pending bugs you think should be there? LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From thomasmckay at redhat.com Wed Oct 10 13:46:27 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 10 Oct 2012 09:46:27 -0400 (EDT) Subject: [katello-devel] Allowing user names w/ ., _, and @ In-Reply-To: <506C9620.8030605@redhat.com> Message-ID: <665368531.6733404.1349876787838.JavaMail.root@redhat.com> Eric, Justin - Can you give pulp v2 a try? What's the best way to get this changed in pulp, if possible? ----- Original Message ----- > From: "Ivan Ne?as" > To: katello-devel at redhat.com > Sent: Wednesday, October 3, 2012 3:46:40 PM > Subject: Re: [katello-devel] Allowing user names w/ ., _, and @ > > On 10/03/2012 09:09 PM, Tom McKay wrote: > > Speak up now if you know of problems allowing user names containing > > ., _, and @ in them. > > foo_bar at acme.org > I don't have problems with it. But it seems Pulp has (at least > 1.1.12): > > InvalidDocument: key 'me at inec.us' must not contain '.' > > Or is this already known issue and we have a plan for this? > > -- Ivan > > > > _______________________________________________ > > 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 jsherril at redhat.com Wed Oct 10 13:49:45 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 10 Oct 2012 09:49:45 -0400 Subject: [katello-devel] Allowing user names w/ ., _, and @ In-Reply-To: <665368531.6733404.1349876787838.JavaMail.root@redhat.com> References: <665368531.6733404.1349876787838.JavaMail.root@redhat.com> Message-ID: <50757CF9.7040901@redhat.com> On 10/10/2012 09:46 AM, Tom McKay wrote: > Eric, Justin - Can you give pulp v2 a try? What's the best way to get this changed in pulp, if possible? Pulpv2 does not allow '.' or '@' (I just tested). I can file an rfe for this. -Justin > > ----- Original Message ----- >> From: "Ivan Ne?as" >> To: katello-devel at redhat.com >> Sent: Wednesday, October 3, 2012 3:46:40 PM >> Subject: Re: [katello-devel] Allowing user names w/ ., _, and @ >> >> On 10/03/2012 09:09 PM, Tom McKay wrote: >>> Speak up now if you know of problems allowing user names containing >>> ., _, and @ in them. >>> foo_bar at acme.org >> I don't have problems with it. But it seems Pulp has (at least >> 1.1.12): >> >> InvalidDocument: key 'me at inec.us' must not contain '.' >> >> Or is this already known issue and we have a plan for this? >> >> -- Ivan >>> _______________________________________________ >>> 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 ehelms at redhat.com Wed Oct 10 14:00:56 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 10 Oct 2012 10:00:56 -0400 (EDT) Subject: [katello-devel] Allowing user names w/ ., _, and @ In-Reply-To: <184685733.4323437.1349291341699.JavaMail.root@redhat.com> Message-ID: <1512239777.6738412.1349877656660.JavaMail.root@redhat.com> +1 Since this is a common paradigm these days for usernames. -Eric ----- Original Message ----- From: "Tom McKay" To: "katello-devel" Sent: Wednesday, October 3, 2012 3:09:01 PM Subject: [katello-devel] Allowing user names w/ ., _, and @ Speak up now if you know of problems allowing user names containing ., _, and @ in them. foo_bar at acme.org _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From jason.dobies at redhat.com Wed Oct 10 14:00:48 2012 From: jason.dobies at redhat.com (Jay Dobies) Date: Wed, 10 Oct 2012 10:00:48 -0400 Subject: [katello-devel] Allowing user names w/ ., _, and @ In-Reply-To: <50757CF9.7040901@redhat.com> References: <665368531.6733404.1349876787838.JavaMail.root@redhat.com> <50757CF9.7040901@redhat.com> Message-ID: <50757F90.8060806@redhat.com> On 10/10/2012 09:49 AM, Justin Sherrill wrote: > On 10/10/2012 09:46 AM, Tom McKay wrote: >> Eric, Justin - Can you give pulp v2 a try? What's the best way to get >> this changed in pulp, if possible? > > Pulpv2 does not allow '.' or '@' (I just tested). I can file an rfe for > this. Ya, file an RFE. I'd normally argue back against that in an ID, but the idea of a login that's an e-mail address is pretty appealing. > -Justin > >> >> ----- Original Message ----- >>> From: "Ivan Ne?as" >>> To: katello-devel at redhat.com >>> Sent: Wednesday, October 3, 2012 3:46:40 PM >>> Subject: Re: [katello-devel] Allowing user names w/ ., _, and @ >>> >>> On 10/03/2012 09:09 PM, Tom McKay wrote: >>>> Speak up now if you know of problems allowing user names containing >>>> ., _, and @ in them. >>>> foo_bar at acme.org >>> I don't have problems with it. But it seems Pulp has (at least >>> 1.1.12): >>> >>> InvalidDocument: key 'me at inec.us' must not contain '.' >>> >>> Or is this already known issue and we have a plan for this? >>> >>> -- Ivan >>>> _______________________________________________ >>>> 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 >>> > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Jay Dobies Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org From jrist at redhat.com Wed Oct 10 14:12:57 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 10 Oct 2012 08:12:57 -0600 Subject: [katello-devel] Branching of Katello 1.1 tomorrow (Oct 11) In-Reply-To: <20121010123105.GE4202@lzapx.brq.redhat.com> References: <20121010123105.GE4202@lzapx.brq.redhat.com> Message-ID: <50758269.7080501@redhat.com> On Wed 10 Oct 2012 06:31:05 AM MDT, Lukas Zapletal wrote: > Team, > > as a Katello 1.1 release nanny I will be branching tomorrow. Quickly > looking on our pull requests, we did a good job and there are only 8, > from which 4 are bugs, one DNM. Please walk trough them, comment, merge. > > I'd like NOT to have foreman integration change in the release. Since > there is live discussion in the request, I guess it will take some time > to merge it, which is good for me. > > Therefore if the nightly build tomorrow will look fine, I will go ahead > and start the process of branching. > > Comments? Opinions? Pending bugs you think should be there? > > LZ > So here's a thought I just randomly had. What if we did a smaller point release instead of a one point one? Why not 1.0.1? Something like that? Without the Foreman integration PR. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From bkearney at redhat.com Wed Oct 10 14:21:01 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 10 Oct 2012 10:21:01 -0400 Subject: [katello-devel] Branching of Katello 1.1 tomorrow (Oct 11) In-Reply-To: <50758269.7080501@redhat.com> References: <20121010123105.GE4202@lzapx.brq.redhat.com> <50758269.7080501@redhat.com> Message-ID: <5075844D.4020909@redhat.com> On 10/10/2012 10:12 AM, Jason Rist wrote: > On Wed 10 Oct 2012 06:31:05 AM MDT, Lukas Zapletal wrote: >> Team, >> >> as a Katello 1.1 release nanny I will be branching tomorrow. Quickly >> looking on our pull requests, we did a good job and there are only 8, >> from which 4 are bugs, one DNM. Please walk trough them, comment, merge. >> >> I'd like NOT to have foreman integration change in the release. Since >> there is live discussion in the request, I guess it will take some time >> to merge it, which is good for me. >> >> Therefore if the nightly build tomorrow will look fine, I will go ahead >> and start the process of branching. >> >> Comments? Opinions? Pending bugs you think should be there? >> >> LZ >> > > So here's a thought I just randomly had. What if we did a smaller > point release instead of a one point one? Why not 1.0.1? Something > like that? Without the Foreman integration PR. What benefit is that as opposed to 1.1? -- bk From thomasmckay at redhat.com Wed Oct 10 14:30:45 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 10 Oct 2012 10:30:45 -0400 (EDT) Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <1923481111.6749408.1349879198695.JavaMail.root@redhat.com> Message-ID: <1807114499.6751058.1349879445796.JavaMail.root@redhat.com> I understand the logic of adding this item to the Administer menu: The Synchronization status page spans orgs. However, it seems very out of place there and I am strongly voting against it. My suggestion: Make the Dashboard have user scope instead of org scope. By this I mean that the portlets do not have to be tied to a specific org necessarily, though some will of course. Perhaps each portlet could get a decorated header that includes the org name. This would also let an admin of more than one org plop down multiple "System Subscription Status" portlets, one for each org they are monitoring. From thomasmckay at redhat.com Wed Oct 10 14:32:06 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 10 Oct 2012 10:32:06 -0400 (EDT) Subject: [katello-devel] Add the "About" item to the Administer menu Message-ID: <1027631685.6752707.1349879526495.JavaMail.root@redhat.com> With the addition of the awesome About page, I'd like to see it added to the Administer menu. Anyone against this? From kybaker at redhat.com Wed Oct 10 14:57:58 2012 From: kybaker at redhat.com (Kyle Baker) Date: Wed, 10 Oct 2012 10:57:58 -0400 (EDT) Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <1807114499.6751058.1349879445796.JavaMail.root@redhat.com> Message-ID: <317382796.8974997.1349881078113.JavaMail.root@redhat.com> ----- Original Message ----- > > I understand the logic of adding this item to the Administer menu: > The Synchronization status page spans orgs. However, it seems very > out of place there and I am strongly voting against it. > > My suggestion: > > Make the Dashboard have user scope instead of org scope. By this I > mean that the portlets do not have to be tied to a specific org > necessarily, though some will of course. Perhaps each portlet could > get a decorated header that includes the org name. This would also > let an admin of more than one org plop down multiple "System > Subscription Status" portlets, one for each org they are monitoring. I understand your concern. I agree that the Administer tab is not the right place. It does have the correct org context as it is org agnostic, but it's intended as housing for traditional tool administration tasks not for monitoring status. The ideal solution that fits the tools current structure would be filtering the sync status page to only show the sync status for the org you are currently viewing. Your suggestion is interesting as it introduces the idea of having a cross organizational view. Adding the cross org view to the content would involve heavily modifying what we have built as the user has already gone though the process for choosing their org on log in and the informational hierarchy is setup to support that after log in as well. I could see this having it's own area where you could see status on everything or having the ability to add/edit/delete content. The user could have access to this as a "Status" button at the top or even specify all orgs on log in. Though I think for this issue the proper solution with the least dev overhead would be filtering the sync status page to the org selected. -Kyle > From jrist at redhat.com Wed Oct 10 15:02:30 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 10 Oct 2012 09:02:30 -0600 Subject: [katello-devel] Add the "About" item to the Administer menu In-Reply-To: <1027631685.6752707.1349879526495.JavaMail.root@redhat.com> References: <1027631685.6752707.1349879526495.JavaMail.root@redhat.com> Message-ID: <50758E06.2090406@redhat.com> On Wed 10 Oct 2012 08:32:06 AM MDT, Tom McKay wrote: > > With the addition of the awesome About page, I'd like to see it added to the Administer menu. Anyone against this? > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Seems reasonable to me, although it is available from the footer as well. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From jrist at redhat.com Wed Oct 10 15:03:16 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 10 Oct 2012 09:03:16 -0600 Subject: [katello-devel] Branching of Katello 1.1 tomorrow (Oct 11) In-Reply-To: <5075844D.4020909@redhat.com> References: <20121010123105.GE4202@lzapx.brq.redhat.com> <50758269.7080501@redhat.com> <5075844D.4020909@redhat.com> Message-ID: <50758E34.3060704@redhat.com> On Wed 10 Oct 2012 08:21:01 AM MDT, Bryan Kearney wrote: > On 10/10/2012 10:12 AM, Jason Rist wrote: >> On Wed 10 Oct 2012 06:31:05 AM MDT, Lukas Zapletal wrote: >>> Team, >>> >>> as a Katello 1.1 release nanny I will be branching tomorrow. Quickly >>> looking on our pull requests, we did a good job and there are only 8, >>> from which 4 are bugs, one DNM. Please walk trough them, comment, >>> merge. >>> >>> I'd like NOT to have foreman integration change in the release. Since >>> there is live discussion in the request, I guess it will take some time >>> to merge it, which is good for me. >>> >>> Therefore if the nightly build tomorrow will look fine, I will go ahead >>> and start the process of branching. >>> >>> Comments? Opinions? Pending bugs you think should be there? >>> >>> LZ >>> >> >> So here's a thought I just randomly had. What if we did a smaller >> point release instead of a one point one? Why not 1.0.1? Something >> like that? Without the Foreman integration PR. > > What benefit is that as opposed to 1.1? > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel *shrug* 1.1 could be saved for Foreman. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From thomasmckay at redhat.com Wed Oct 10 15:04:30 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 10 Oct 2012 11:04:30 -0400 (EDT) Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <317382796.8974997.1349881078113.JavaMail.root@redhat.com> Message-ID: <1523439536.6765214.1349881470756.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Kyle Baker" > To: "Tom McKay" > Cc: "katello-devel" > Sent: Wednesday, October 10, 2012 10:57:58 AM > Subject: Re: [katello-devel] New "Synchronization" item in Administer menu > > > > ----- Original Message ----- > > > > I understand the logic of adding this item to the Administer menu: > > The Synchronization status page spans orgs. However, it seems very > > out of place there and I am strongly voting against it. > > > > My suggestion: > > > > Make the Dashboard have user scope instead of org scope. By this I > > mean that the portlets do not have to be tied to a specific org > > necessarily, though some will of course. Perhaps each portlet could > > get a decorated header that includes the org name. This would also > > let an admin of more than one org plop down multiple "System > > Subscription Status" portlets, one for each org they are > > monitoring. > > I understand your concern. I agree that the Administer tab is not the > right place. It does have the correct org context as it is org > agnostic, but it's intended as housing for traditional tool > administration tasks not for monitoring status. The ideal solution > that fits the tools current structure would be filtering the sync > status page to only show the sync status for the org you are > currently viewing. > > Your suggestion is interesting as it introduces the idea of having a > cross organizational view. Adding the cross org view to the content > would involve heavily modifying what we have built as the user has > already gone though the process for choosing their org on log in and > the informational hierarchy is setup to support that after log in as > well. I could see this having it's own area where you could see > status on everything or having the ability to add/edit/delete > content. The user could have access to this as a "Status" button at > the top or even specify all orgs on log in. Though I think for this > issue the proper solution with the least dev overhead would be > filtering the sync status page to the org selected. I'm not sure I understand: Are you saying remove it from Administer or not? The final sentence, "filtering the sync status page to the org selected," what does that mean? The Content -> Sync Management -> Sync Status is where the current org's sync status is displayed. The new menu entry shows _all_ orgs. Are you suggesting upgrading the existing Sync Status single org page to allow cross-org views? I'm not against that as I feel the single-org strictness is a rule that deserves to be bent (or thrown out). > > -Kyle > > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jrist at redhat.com Wed Oct 10 15:04:56 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 10 Oct 2012 09:04:56 -0600 Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <1807114499.6751058.1349879445796.JavaMail.root@redhat.com> References: <1807114499.6751058.1349879445796.JavaMail.root@redhat.com> Message-ID: <50758E98.2020104@redhat.com> On 10/10/2012 08:30 AM, Tom McKay wrote: > > I understand the logic of adding this item to the Administer menu: The Synchronization status page spans orgs. However, it seems very out of place there and I am strongly voting against it. > > My suggestion: > > Make the Dashboard have user scope instead of org scope. By this I mean that the portlets do not have to be tied to a specific org necessarily, though some will of course. Perhaps each portlet could get a decorated header that includes the org name. This would also let an admin of more than one org plop down multiple "System Subscription Status" portlets, one for each org they are monitoring. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > Perhaps I misunderstand, does the current Sync Status page link not suffice? Or is that new Synchronization page some combined page? Perhaps the Administer menu needs to be rethought a little bit? -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From msuchy at redhat.com Wed Oct 10 15:06:59 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Wed, 10 Oct 2012 17:06:59 +0200 Subject: [katello-devel] Branching of Katello 1.1 tomorrow (Oct 11) In-Reply-To: <50758E34.3060704@redhat.com> References: <20121010123105.GE4202@lzapx.brq.redhat.com> <50758269.7080501@redhat.com> <5075844D.4020909@redhat.com> <50758E34.3060704@redhat.com> Message-ID: <50758F13.90206@redhat.com> On 10.10.2012 17:03, Jason Rist wrote: > *shrug* 1.1 could be saved for Foreman. It is just numbers Jason. :) And 1.2 will be here in two months. Which will be even better than 1.1 :) Mirek From inecas at redhat.com Wed Oct 10 15:26:47 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 10 Oct 2012 17:26:47 +0200 Subject: [katello-devel] Branching of Katello 1.1 tomorrow (Oct 11) In-Reply-To: <20121010123105.GE4202@lzapx.brq.redhat.com> References: <20121010123105.GE4202@lzapx.brq.redhat.com> Message-ID: <507593B7.2060409@redhat.com> On 10/10/2012 02:31 PM, Lukas Zapletal wrote: > Team, > > as a Katello 1.1 release nanny I will be branching tomorrow. Quickly > looking on our pull requests, we did a good job and there are only 8, > from which 4 are bugs, one DNM. Please walk trough them, comment, merge. > > I'd like NOT to have foreman integration change in the release. Since > there is live discussion in the request, I guess it will take some time > to merge it, which is good for me. > > Therefore if the nightly build tomorrow will look fine, I will go ahead > and start the process of branching. > > Comments? Opinions? Pending bugs you think should be there? > > LZ > I can see 6 system tests failing. Can we get them fixed first? Or we will get the fixes by cherry-picking? Or nobody else is seeing this failure? -- Ivan From kybaker at redhat.com Wed Oct 10 15:34:15 2012 From: kybaker at redhat.com (Kyle Baker) Date: Wed, 10 Oct 2012 11:34:15 -0400 (EDT) Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <50758E98.2020104@redhat.com> Message-ID: <108292036.8994432.1349883255867.JavaMail.root@redhat.com> ----- Original Message ----- > On 10/10/2012 08:30 AM, Tom McKay wrote: > > > > I understand the logic of adding this item to the Administer menu: > > The Synchronization status page spans orgs. However, it seems very > > out of place there and I am strongly voting against it. > > > > My suggestion: > > > > Make the Dashboard have user scope instead of org scope. By this I > > mean that the portlets do not have to be tied to a specific org > > necessarily, though some will of course. Perhaps each portlet > > could get a decorated header that includes the org name. This > > would also let an admin of more than one org plop down multiple > > "System Subscription Status" portlets, one for each org they are > > monitoring. > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > Perhaps I misunderstand, does the current Sync Status page link not > suffice? Or is that new Synchronization page some combined page? > Perhaps the Administer menu needs to be rethought a little bit? Tom is writing a story for this to clear up confusion. > > -J > > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > github/identi.ca: knowncitizen > From bkearney at redhat.com Wed Oct 10 15:50:00 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 10 Oct 2012 11:50:00 -0400 Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <108292036.8994432.1349883255867.JavaMail.root@redhat.com> References: <108292036.8994432.1349883255867.JavaMail.root@redhat.com> Message-ID: <50759928.7010307@redhat.com> On 10/10/2012 11:34 AM, Kyle Baker wrote: > > > ----- Original Message ----- >> On 10/10/2012 08:30 AM, Tom McKay wrote: >>> >>> I understand the logic of adding this item to the Administer menu: >>> The Synchronization status page spans orgs. However, it seems very >>> out of place there and I am strongly voting against it. >>> >>> My suggestion: >>> >>> Make the Dashboard have user scope instead of org scope. By this I >>> mean that the portlets do not have to be tied to a specific org >>> necessarily, though some will of course. Perhaps each portlet >>> could get a decorated header that includes the org name. This >>> would also let an admin of more than one org plop down multiple >>> "System Subscription Status" portlets, one for each org they are >>> monitoring. >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> >> Perhaps I misunderstand, does the current Sync Status page link not >> suffice? Or is that new Synchronization page some combined page? >> Perhaps the Administer menu needs to be rethought a little bit? > > Tom is writing a story for this to clear up confusion. I like the idea of a cross org dashboard. However, I would put foreman integration above that :) -- bk From mmccune at redhat.com Wed Oct 10 16:53:51 2012 From: mmccune at redhat.com (Mike McCune) Date: Wed, 10 Oct 2012 09:53:51 -0700 Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <50758E98.2020104@redhat.com> References: <1807114499.6751058.1349879445796.JavaMail.root@redhat.com> <50758E98.2020104@redhat.com> Message-ID: <5075A81F.2070602@redhat.com> On 10/10/2012 08:04 AM, Jason Rist wrote: > On 10/10/2012 08:30 AM, Tom McKay wrote: >> >> I understand the logic of adding this item to the Administer menu: The Synchronization status page spans orgs. However, it seems very out of place there and I am strongly voting against it. >> >> My suggestion: >> >> Make the Dashboard have user scope instead of org scope. By this I mean that the portlets do not have to be tied to a specific org necessarily, though some will of course. Perhaps each portlet could get a decorated header that includes the org name. This would also let an admin of more than one org plop down multiple "System Subscription Status" portlets, one for each org they are monitoring. >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > > Perhaps I misunderstand, does the current Sync Status page link not > suffice? Or is that new Synchronization page some combined page? > Perhaps the Administer menu needs to be rethought a little bit? the current sync status page here: https://katello.example.com/katello/sync_management/index will only show you syncs based on the current org you are logged into. the new site wide sync status: https://katello.example.com/katello/sync_management/manage shows you *all* syncs across all orgs. Mike From thomasmckay at redhat.com Wed Oct 10 17:26:12 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 10 Oct 2012 13:26:12 -0400 (EDT) Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <1523439536.6765214.1349881470756.JavaMail.root@redhat.com> Message-ID: <1316150220.6820894.1349889972116.JavaMail.root@redhat.com> I think most (all?) would agree that Synchronization is out of place in the Administer menu. What I'll propose is that when switching to an "all orgs" functional category, that the nav structure changes to the attached screenshot. The new Synchronization page would become a portlet (or two) on the all orgs dashboard (I did not mock this up but you get the idea, I hope). You'll also see the All Organizations in the org selector (perhaps could be bold or something to differentiate it further). The existing cross-org features would become first class navigation elements. To return to working in the context of a single org, use the org selector to choose org. The effort to implement this would, hopefully, be low and would leave us with a paradigm to handle future cross-org features. Kyle did mention that the "unified" aeolus/katello UI design work currently underway may impact this. I have no idea what this entails so others will need to chime in if what I'm suggesting steps on that work. P.S. I don't think the "synchronize now" button really belongs on this page. The user should be forced to go to an org to kick off sync jobs. If that's not the case, this opens up a whole new can of worms. ----- Original Message ----- > From: "Tom McKay" > To: "Kyle Baker" > Cc: "katello-devel" > Sent: Wednesday, October 10, 2012 11:04:30 AM > Subject: Re: [katello-devel] New "Synchronization" item in Administer menu > > > > ----- Original Message ----- > > From: "Kyle Baker" > > To: "Tom McKay" > > Cc: "katello-devel" > > Sent: Wednesday, October 10, 2012 10:57:58 AM > > Subject: Re: [katello-devel] New "Synchronization" item in > > Administer menu > > > > > > > > ----- Original Message ----- > > > > > > I understand the logic of adding this item to the Administer > > > menu: > > > The Synchronization status page spans orgs. However, it seems > > > very > > > out of place there and I am strongly voting against it. > > > > > > My suggestion: > > > > > > Make the Dashboard have user scope instead of org scope. By this > > > I > > > mean that the portlets do not have to be tied to a specific org > > > necessarily, though some will of course. Perhaps each portlet > > > could > > > get a decorated header that includes the org name. This would > > > also > > > let an admin of more than one org plop down multiple "System > > > Subscription Status" portlets, one for each org they are > > > monitoring. > > > > I understand your concern. I agree that the Administer tab is not > > the > > right place. It does have the correct org context as it is org > > agnostic, but it's intended as housing for traditional tool > > administration tasks not for monitoring status. The ideal solution > > that fits the tools current structure would be filtering the sync > > status page to only show the sync status for the org you are > > currently viewing. > > > > Your suggestion is interesting as it introduces the idea of having > > a > > cross organizational view. Adding the cross org view to the content > > would involve heavily modifying what we have built as the user has > > already gone though the process for choosing their org on log in > > and > > the informational hierarchy is setup to support that after log in > > as > > well. I could see this having it's own area where you could see > > status on everything or having the ability to add/edit/delete > > content. The user could have access to this as a "Status" button at > > the top or even specify all orgs on log in. Though I think for this > > issue the proper solution with the least dev overhead would be > > filtering the sync status page to the org selected. > > I'm not sure I understand: Are you saying remove it from Administer > or not? > > The final sentence, "filtering the sync status page to the org > selected," what does that mean? The Content -> Sync Management -> > Sync Status is where the current org's sync status is displayed. The > new menu entry shows _all_ orgs. Are you suggesting upgrading the > existing Sync Status single org page to allow cross-org views? I'm > not against that as I feel the single-org strictness is a rule that > deserves to be bent (or thrown out). > > > > > > -Kyle > > > > > > > > > _______________________________________________ > > 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 -------------- A non-text attachment was scrubbed... Name: allorgs.png Type: image/png Size: 50930 bytes Desc: not available URL: From adprice at redhat.com Wed Oct 10 17:27:57 2012 From: adprice at redhat.com (Adam Price) Date: Wed, 10 Oct 2012 13:27:57 -0400 (EDT) Subject: [katello-devel] failing db migrations Message-ID: <1357645371.12684804.1349890077666.JavaMail.root@redhat.com> lzap, just for you :) https://github.com/Katello/katello/commit/dafbb60f6dfcc94d0685d42807b891a021cf9d81 -- Adam Price adprice at redhat dot com From ehelms at redhat.com Wed Oct 10 17:38:14 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 10 Oct 2012 13:38:14 -0400 (EDT) Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <1316150220.6820894.1349889972116.JavaMail.root@redhat.com> Message-ID: <996713655.6825350.1349890694181.JavaMail.root@redhat.com> Can we incorporate some reference or discussion here about who the 'user' is for cross-org features and the permission set(s) that would be required to view, and/or interact with the cross-org features? I know we have done that to some degree with users and roles, but as we add more functionality to cross-org views I think we should keep authorization in line with the conversation. -Eric ----- Original Message ----- From: "Tom McKay" To: "katello-devel" Sent: Wednesday, October 10, 2012 1:26:12 PM Subject: Re: [katello-devel] New "Synchronization" item in Administer menu I think most (all?) would agree that Synchronization is out of place in the Administer menu. What I'll propose is that when switching to an "all orgs" functional category, that the nav structure changes to the attached screenshot. The new Synchronization page would become a portlet (or two) on the all orgs dashboard (I did not mock this up but you get the idea, I hope). You'll also see the All Organizations in the org selector (perhaps could be bold or something to differentiate it further). The existing cross-org features would become first class navigation elements. To return to working in the context of a single org, use the org selector to choose org. The effort to implement this would, hopefully, be low and would leave us with a paradigm to handle future cross-org features. Kyle did mention that the "unified" aeolus/katello UI design work currently underway may impact this. I have no idea what this entails so others will need to chime in if what I'm suggesting steps on that work. P.S. I don't think the "synchronize now" button really belongs on this page. The user should be forced to go to an org to kick off sync jobs. If that's not the case, this opens up a whole new can of worms. ----- Original Message ----- > From: "Tom McKay" > To: "Kyle Baker" > Cc: "katello-devel" > Sent: Wednesday, October 10, 2012 11:04:30 AM > Subject: Re: [katello-devel] New "Synchronization" item in Administer menu > > > > ----- Original Message ----- > > From: "Kyle Baker" > > To: "Tom McKay" > > Cc: "katello-devel" > > Sent: Wednesday, October 10, 2012 10:57:58 AM > > Subject: Re: [katello-devel] New "Synchronization" item in > > Administer menu > > > > > > > > ----- Original Message ----- > > > > > > I understand the logic of adding this item to the Administer > > > menu: > > > The Synchronization status page spans orgs. However, it seems > > > very > > > out of place there and I am strongly voting against it. > > > > > > My suggestion: > > > > > > Make the Dashboard have user scope instead of org scope. By this > > > I > > > mean that the portlets do not have to be tied to a specific org > > > necessarily, though some will of course. Perhaps each portlet > > > could > > > get a decorated header that includes the org name. This would > > > also > > > let an admin of more than one org plop down multiple "System > > > Subscription Status" portlets, one for each org they are > > > monitoring. > > > > I understand your concern. I agree that the Administer tab is not > > the > > right place. It does have the correct org context as it is org > > agnostic, but it's intended as housing for traditional tool > > administration tasks not for monitoring status. The ideal solution > > that fits the tools current structure would be filtering the sync > > status page to only show the sync status for the org you are > > currently viewing. > > > > Your suggestion is interesting as it introduces the idea of having > > a > > cross organizational view. Adding the cross org view to the content > > would involve heavily modifying what we have built as the user has > > already gone though the process for choosing their org on log in > > and > > the informational hierarchy is setup to support that after log in > > as > > well. I could see this having it's own area where you could see > > status on everything or having the ability to add/edit/delete > > content. The user could have access to this as a "Status" button at > > the top or even specify all orgs on log in. Though I think for this > > issue the proper solution with the least dev overhead would be > > filtering the sync status page to the org selected. > > I'm not sure I understand: Are you saying remove it from Administer > or not? > > The final sentence, "filtering the sync status page to the org > selected," what does that mean? The Content -> Sync Management -> > Sync Status is where the current org's sync status is displayed. The > new menu entry shows _all_ orgs. Are you suggesting upgrading the > existing Sync Status single org page to allow cross-org views? I'm > not against that as I feel the single-org strictness is a rule that > deserves to be bent (or thrown out). > > > > > > -Kyle > > > > > > > > > _______________________________________________ > > 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 thomasmckay at redhat.com Wed Oct 10 17:39:49 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 10 Oct 2012 13:39:49 -0400 (EDT) Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <996713655.6825350.1349890694181.JavaMail.root@redhat.com> Message-ID: <1203418704.6825796.1349890789214.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eric Helms" > To: "Tom McKay" > Cc: "katello-devel" > Sent: Wednesday, October 10, 2012 1:38:14 PM > Subject: Re: [katello-devel] New "Synchronization" item in Administer menu > > Can we incorporate some reference or discussion here about who the > 'user' is for cross-org features and the permission set(s) that > would be required to view, and/or interact with the cross-org > features? I know we have done that to some degree with users and > roles, but as we add more functionality to cross-org views I think > we should keep authorization in line with the conversation. I've been assuming that the cross-org would act just use the existing roles/perms. If you can see an org's sync status, you get it, etc. Is there more complexity? > > -Eric > > ----- Original Message ----- > From: "Tom McKay" > To: "katello-devel" > Sent: Wednesday, October 10, 2012 1:26:12 PM > Subject: Re: [katello-devel] New "Synchronization" item in Administer > menu > > > I think most (all?) would agree that Synchronization is out of place > in the Administer menu. > > What I'll propose is that when switching to an "all orgs" functional > category, that the nav structure changes to the attached screenshot. > > The new Synchronization page would become a portlet (or two) on the > all orgs dashboard (I did not mock this up but you get the idea, I > hope). > > You'll also see the All Organizations in the org selector (perhaps > could be bold or something to differentiate it further). The > existing cross-org features would become first class navigation > elements. > > To return to working in the context of a single org, use the org > selector to choose org. > > The effort to implement this would, hopefully, be low and would leave > us with a paradigm to handle future cross-org features. > > Kyle did mention that the "unified" aeolus/katello UI design work > currently underway may impact this. I have no idea what this entails > so others will need to chime in if what I'm suggesting steps on that > work. > > P.S. I don't think the "synchronize now" button really belongs on > this page. The user should be forced to go to an org to kick off > sync jobs. If that's not the case, this opens up a whole new can of > worms. > > ----- Original Message ----- > > From: "Tom McKay" > > To: "Kyle Baker" > > Cc: "katello-devel" > > Sent: Wednesday, October 10, 2012 11:04:30 AM > > Subject: Re: [katello-devel] New "Synchronization" item in > > Administer menu > > > > > > > > ----- Original Message ----- > > > From: "Kyle Baker" > > > To: "Tom McKay" > > > Cc: "katello-devel" > > > Sent: Wednesday, October 10, 2012 10:57:58 AM > > > Subject: Re: [katello-devel] New "Synchronization" item in > > > Administer menu > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > I understand the logic of adding this item to the Administer > > > > menu: > > > > The Synchronization status page spans orgs. However, it seems > > > > very > > > > out of place there and I am strongly voting against it. > > > > > > > > My suggestion: > > > > > > > > Make the Dashboard have user scope instead of org scope. By > > > > this > > > > I > > > > mean that the portlets do not have to be tied to a specific org > > > > necessarily, though some will of course. Perhaps each portlet > > > > could > > > > get a decorated header that includes the org name. This would > > > > also > > > > let an admin of more than one org plop down multiple "System > > > > Subscription Status" portlets, one for each org they are > > > > monitoring. > > > > > > I understand your concern. I agree that the Administer tab is not > > > the > > > right place. It does have the correct org context as it is org > > > agnostic, but it's intended as housing for traditional tool > > > administration tasks not for monitoring status. The ideal > > > solution > > > that fits the tools current structure would be filtering the sync > > > status page to only show the sync status for the org you are > > > currently viewing. > > > > > > Your suggestion is interesting as it introduces the idea of > > > having > > > a > > > cross organizational view. Adding the cross org view to the > > > content > > > would involve heavily modifying what we have built as the user > > > has > > > already gone though the process for choosing their org on log in > > > and > > > the informational hierarchy is setup to support that after log in > > > as > > > well. I could see this having it's own area where you could see > > > status on everything or having the ability to add/edit/delete > > > content. The user could have access to this as a "Status" button > > > at > > > the top or even specify all orgs on log in. Though I think for > > > this > > > issue the proper solution with the least dev overhead would be > > > filtering the sync status page to the org selected. > > > > I'm not sure I understand: Are you saying remove it from Administer > > or not? > > > > The final sentence, "filtering the sync status page to the org > > selected," what does that mean? The Content -> Sync Management -> > > Sync Status is where the current org's sync status is displayed. > > The > > new menu entry shows _all_ orgs. Are you suggesting upgrading the > > existing Sync Status single org page to allow cross-org views? I'm > > not against that as I feel the single-org strictness is a rule that > > deserves to be bent (or thrown out). > > > > > > > > > > -Kyle > > > > > > > > > > > > > _______________________________________________ > > > 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 lzap at redhat.com Thu Oct 11 07:55:33 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 11 Oct 2012 09:55:33 +0200 Subject: [katello-devel] Add the "About" item to the Administer menu In-Reply-To: <50758E06.2090406@redhat.com> References: <1027631685.6752707.1349879526495.JavaMail.root@redhat.com> <50758E06.2090406@redhat.com> Message-ID: <20121011075533.GA4728@lzapx.brq.redhat.com> I am in, and I would vote for removing it from the footer. LZ On Wed, Oct 10, 2012 at 09:02:30AM -0600, Jason Rist wrote: > On Wed 10 Oct 2012 08:32:06 AM MDT, Tom McKay wrote: > > > > With the addition of the awesome About page, I'd like to see it added to the Administer menu. Anyone against this? > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > Seems reasonable to me, although it is available from the footer as > well. > > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > github/identi.ca: knowncitizen > > _______________________________________________ > 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 Thu Oct 11 08:13:21 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 11 Oct 2012 10:13:21 +0200 Subject: [katello-devel] Branching of Katello 1.1 tomorrow (Oct 11) In-Reply-To: <507593B7.2060409@redhat.com> References: <20121010123105.GE4202@lzapx.brq.redhat.com> <507593B7.2060409@redhat.com> Message-ID: <20121011081320.GB4728@lzapx.brq.redhat.com> That is right, 6 tests are failing: http://pastebin.com/31HJsKCV rhsm set releasever add product to ak 1 system subscribe (multiple times, somebody touched format of cli output width) If you start working on any, please inform others here. LZ On Wed, Oct 10, 2012 at 05:26:47PM +0200, Ivan Necas wrote: > On 10/10/2012 02:31 PM, Lukas Zapletal wrote: > >Team, > > > >as a Katello 1.1 release nanny I will be branching tomorrow. Quickly > >looking on our pull requests, we did a good job and there are only 8, > >from which 4 are bugs, one DNM. Please walk trough them, comment, merge. > > > >I'd like NOT to have foreman integration change in the release. Since > >there is live discussion in the request, I guess it will take some time > >to merge it, which is good for me. > > > >Therefore if the nightly build tomorrow will look fine, I will go ahead > >and start the process of branching. > > > >Comments? Opinions? Pending bugs you think should be there? > > > >LZ > > > I can see 6 system tests failing. Can we get them fixed first? Or we > will get the fixes by cherry-picking? Or nobody else is seeing this > failure? > > -- > 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 pchalupa at redhat.com Thu Oct 11 09:16:03 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Thu, 11 Oct 2012 11:16:03 +0200 Subject: [katello-devel] Runcible - replacing classes with instances Message-ID: <50768E53.1090807@redhat.com> Hi I like what you are doing around Pulp v2, Runcible and usage of vcr is great. I would have one suggestion though to replace class-implementation of runcible with instances. I would suggest to move all the functionality/methods from class (Runcible::Base, Runcible::Resources::*) to instances to avoid some limitations: - gem cannot be used to connect to more then one Pulp instance, config is defined globally - Resources are defined globally, you cannot stub just something in tests Also imho it is good practice not to create singletons unless it is really needed. Singletons can be defined in Katello later (like we did in foreman_architectures, see [1]) without compromising the ability to use different Resource instance in an object if needed, see [2][3]. Petr [1] https://github.com/Katello/katello/blob/0dd082076ff91761e2a03353c9a340754f902749/src/lib/resources/foreman.rb [2] https://github.com/Katello/katello/blob/0dd082076ff91761e2a03353c9a340754f902749/src/lib/resources/abstract_model.rb#L128 [3] https://github.com/Katello/katello/blob/0dd082076ff91761e2a03353c9a340754f902749/src/lib/resources/foreman_model.rb#L15 From msuchy at redhat.com Thu Oct 11 12:17:49 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Thu, 11 Oct 2012 14:17:49 +0200 Subject: [katello-devel] Branching of Katello 1.1 tomorrow (Oct 11) In-Reply-To: <20121011081320.GB4728@lzapx.brq.redhat.com> References: <20121010123105.GE4202@lzapx.brq.redhat.com> <507593B7.2060409@redhat.com> <20121011081320.GB4728@lzapx.brq.redhat.com> Message-ID: <5076B8ED.2040204@redhat.com> On 10/11/2012 10:13 AM, Lukas Zapletal wrote: > add product to ak 1 Taking this one. -- Miroslav Suchy Red Hat Systems Management Engineering From bkearney at redhat.com Thu Oct 11 12:38:16 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 11 Oct 2012 08:38:16 -0400 Subject: [katello-devel] New "Synchronization" item in Administer menu In-Reply-To: <1203418704.6825796.1349890789214.JavaMail.root@redhat.com> References: <1203418704.6825796.1349890789214.JavaMail.root@redhat.com> Message-ID: <5076BDB8.2090300@redhat.com> On 10/10/2012 01:39 PM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Eric Helms" >> To: "Tom McKay" >> Cc: "katello-devel" >> Sent: Wednesday, October 10, 2012 1:38:14 PM >> Subject: Re: [katello-devel] New "Synchronization" item in Administer menu >> >> Can we incorporate some reference or discussion here about who the >> 'user' is for cross-org features and the permission set(s) that >> would be required to view, and/or interact with the cross-org >> features? I know we have done that to some degree with users and >> roles, but as we add more functionality to cross-org views I think >> we should keep authorization in line with the conversation. > > I've been assuming that the cross-org would act just use the existing roles/perms. If you can see an org's sync status, you get it, etc. Is there more complexity? What else is in the organizations tab? One thing I liked about Aeolous was if you were in "Admin" mode, the "normal" menus went away. -- bk From lzap at redhat.com Thu Oct 11 13:42:50 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 11 Oct 2012 15:42:50 +0200 Subject: [katello-devel] NO MERGE window started Message-ID: <20121011134250.GH4728@lzapx.brq.redhat.com> Team, we have been fixing some CLI bugs today. I ask you NOT to merge any work until I branch Katello tomorrow. I expect the following work to be merged: - gpg keys + test fix (dmitri) - cli tests fixes (msuchy) - cli fixes (lzap) - any other bugs you think are blockers for K11 (pls ping me) I am gonna open master for business tomorrow if it turns out nightly is in good condition. I would like to go through the UI and to test it a bit later today - if anyone can help me I'd appreciate (I assume QA folks have no time for that - if there is any chance of running some UI test suite against today's master please do and ping me with results). LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Thu Oct 11 13:55:46 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 11 Oct 2012 14:55:46 +0100 Subject: [katello-devel] NO MERGE window started In-Reply-To: <20121011134250.GH4728@lzapx.brq.redhat.com> References: <20121011134250.GH4728@lzapx.brq.redhat.com> Message-ID: <5076CFE2.7020007@redhat.com> On 11/10/12 02:42 PM, Lukas Zapletal wrote: > Team, > > we have been fixing some CLI bugs today. I ask you NOT to merge any work > until I branch Katello tomorrow. I expect the following work to be > merged: > > - gpg keys + test fix (dmitri) merged in. -d > - cli tests fixes (msuchy) > - cli fixes (lzap) > - any other bugs you think are blockers for K11 (pls ping me) > > I am gonna open master for business tomorrow if it turns out nightly is > in good condition. I would like to go through the UI and to test it a > bit later today - if anyone can help me I'd appreciate (I assume QA > folks have no time for that - if there is any chance of running some UI > test suite against today's master please do and ping me with results). > > LZ > From gkhachik at redhat.com Thu Oct 11 14:04:48 2012 From: gkhachik at redhat.com (Garik Khachikyan) Date: Thu, 11 Oct 2012 16:04:48 +0200 Subject: [katello-devel] NO MERGE window started In-Reply-To: <20121011134250.GH4728@lzapx.brq.redhat.com> References: <20121011134250.GH4728@lzapx.brq.redhat.com> Message-ID: <5076D200.9080700@redhat.com> On 11/10/12 15:42, Lukas Zapletal wrote: > Team, > > we have been fixing some CLI bugs today. I ask you NOT to merge any work > until I branch Katello tomorrow. I expect the following work to be > merged: > > - gpg keys + test fix (dmitri) > - cli tests fixes (msuchy) > - cli fixes (lzap) > - any other bugs you think are blockers for K11 (pls ping me) > > I am gonna open master for business tomorrow if it turns out nightly is > in good condition. I would like to go through the UI and to test it a > bit later today - if anyone can help me I'd appreciate (I assume QA > folks have no time for that - if there is any chance of running some UI > test suite against today's master please do and ping me with results). > > LZ > Lukas, From QE point of view we have run just today the katello from: katello-1.1.13-1.git.161.96aa2bd.el6.noarch katello-cli-1.1.9-1.git.128.d72c83d.el6.noarch and so far all are pretty good! there are just 3 bugs: https://bugzilla.redhat.com/show_bug.cgi?id=862753 https://bugzilla.redhat.com/show_bug.cgi?id=865366 https://bugzilla.redhat.com/show_bug.cgi?id=865397 which I would not consider critical/blocker for the release anyway :) So my "green" for 1.1 Happy release. Garik From bkearney at redhat.com Thu Oct 11 16:05:11 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 11 Oct 2012 12:05:11 -0400 Subject: [katello-devel] Did system moving get in? Message-ID: <5076EE37.20308@redhat.com> Dmitri: Did moving a system cross orgs get it? -- bk From jrist at redhat.com Thu Oct 11 16:08:03 2012 From: jrist at redhat.com (Jason Rist) Date: Thu, 11 Oct 2012 10:08:03 -0600 Subject: [katello-devel] Did system moving get in? In-Reply-To: <5076EE37.20308@redhat.com> References: <5076EE37.20308@redhat.com> Message-ID: <5076EEE3.2090507@redhat.com> On Thu 11 Oct 2012 10:05:11 AM MDT, Bryan Kearney wrote: > Dmitri: > > Did moving a system cross orgs get it? > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Not sure about ORGS but I know he did ENVIRONMENTS in the UI. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From dmitri at redhat.com Thu Oct 11 16:10:00 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 11 Oct 2012 17:10:00 +0100 Subject: [katello-devel] Did system moving get in? In-Reply-To: <5076EE37.20308@redhat.com> References: <5076EE37.20308@redhat.com> Message-ID: <5076EF58.7070104@redhat.com> On 11/10/12 05:05 PM, Bryan Kearney wrote: > Dmitri: > > Did moving a system cross orgs get it? > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Did you mean across environments? Then the answer is yes. I don't think i ever saw a story about moving systems between organizations... -d From dmitri at redhat.com Thu Oct 11 16:10:50 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 11 Oct 2012 17:10:50 +0100 Subject: [katello-devel] Did system moving get in? In-Reply-To: <5076EEE3.2090507@redhat.com> References: <5076EE37.20308@redhat.com> <5076EEE3.2090507@redhat.com> Message-ID: <5076EF8A.5050907@redhat.com> On 11/10/12 05:08 PM, Jason Rist wrote: > On Thu 11 Oct 2012 10:05:11 AM MDT, Bryan Kearney wrote: >> Dmitri: >> >> Did moving a system cross orgs get it? >> >> -- bk >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Not sure about ORGS but I know he did ENVIRONMENTS in the UI. > > -J > > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > github/identi.ca: knowncitizen > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel cli got the love too (it's done via system update). -d From bkearney at redhat.com Thu Oct 11 16:12:21 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 11 Oct 2012 12:12:21 -0400 Subject: [katello-devel] Did system moving get in? In-Reply-To: <5076EF58.7070104@redhat.com> References: <5076EE37.20308@redhat.com> <5076EF58.7070104@redhat.com> Message-ID: <5076EFE5.7030908@redhat.com> On 10/11/2012 12:10 PM, Dmitri Dolguikh wrote: > On 11/10/12 05:05 PM, Bryan Kearney wrote: >> Dmitri: >> >> Did moving a system cross orgs get it? >> >> -- bk >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Did you mean across environments? Then the answer is yes. I don't think > i ever saw a story about moving systems between organizations... > -d > Ok.. I remembered incorrectly. Thanks!.. I see it now. -- bk From thomasmckay at redhat.com Thu Oct 11 16:32:05 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 11 Oct 2012 12:32:05 -0400 (EDT) Subject: [katello-devel] Help! How to turn a production install into development? Message-ID: <1564632466.7356618.1349973125376.JavaMail.root@redhat.com> Editing /etc/sysconfig/katello and setting to development then requires redcarpet gem, which I can't seem to find/install. How do I disable references to redcarpet? I assume it is not required to run our software since it's not needed in production. Help! From msuchy at redhat.com Thu Oct 11 16:54:47 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Thu, 11 Oct 2012 18:54:47 +0200 Subject: [katello-devel] Help! How to turn a production install into development? In-Reply-To: <1564632466.7356618.1349973125376.JavaMail.root@redhat.com> References: <1564632466.7356618.1349973125376.JavaMail.root@redhat.com> Message-ID: <5076F9D7.3080407@redhat.com> On 11.10.2012 18:32, Tom McKay wrote: > then requires redcarpet gem, which I can't seem to find/install. yum install rubygem-redcarpet http://koji.fedoraproject.org/koji/packageinfo?packageID=13835 Mirek From thomasmckay at redhat.com Thu Oct 11 18:06:07 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 11 Oct 2012 14:06:07 -0400 (EDT) Subject: [katello-devel] Help! How to turn a production install into development? In-Reply-To: <5076F9D7.3080407@redhat.com> Message-ID: <2004913417.7387205.1349978767029.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Miroslav Suchy" > To: katello-devel at redhat.com > Sent: Thursday, October 11, 2012 12:54:47 PM > Subject: Re: [katello-devel] Help! How to turn a production install into development? > > On 11.10.2012 18:32, Tom McKay wrote: > > then requires redcarpet gem, which I can't seem to find/install. > > yum install rubygem-redcarpet > > http://koji.fedoraproject.org/koji/packageinfo?packageID=13835 > > Mirek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > Since this is the only missing gem that prevents switching from production to development, can we please include it with the production RPMs? It will be important to easily let support people switch a customer's install to increase debug logging. Thanks! From msuchy at redhat.com Thu Oct 11 18:17:59 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Thu, 11 Oct 2012 20:17:59 +0200 Subject: [katello-devel] bug in commit 5b910dcc5d9b0771bedb28425df0072edee9f659 Message-ID: <50770D57.4070806@redhat.com> Dmitri, in commit 5b910dcc5d9b0771bedb28425df0072edee9f659 you introduced on several places + found = ::Resources::Candlepin::Content.get(id) + ::Candlepin::Content.new(found) + @content = ::Candlepin::Content.new(params[:content] || params["content"]) ... and more and the leading :: does not work (at least on some places). I'm not sure if it should be Candlepin::Content or Resources::Candlepin::Content so I will leave the fix on you. Can you please fix it. Thanks. Mirek From thomasmckay at redhat.com Thu Oct 11 18:19:11 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 11 Oct 2012 14:19:11 -0400 (EDT) Subject: [katello-devel] Help! How to turn a production install into development? In-Reply-To: <2004913417.7387205.1349978767029.JavaMail.root@redhat.com> Message-ID: <1538970164.7389839.1349979551056.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tom McKay" > To: "Miroslav Suchy" > Cc: katello-devel at redhat.com > Sent: Thursday, October 11, 2012 2:06:07 PM > Subject: Re: [katello-devel] Help! How to turn a production install into development? > > > > ----- Original Message ----- > > From: "Miroslav Suchy" > > To: katello-devel at redhat.com > > Sent: Thursday, October 11, 2012 12:54:47 PM > > Subject: Re: [katello-devel] Help! How to turn a production install > > into development? > > > > On 11.10.2012 18:32, Tom McKay wrote: > > > then requires redcarpet gem, which I can't seem to > > > find/install. > > > > yum install rubygem-redcarpet > > > > http://koji.fedoraproject.org/koji/packageinfo?packageID=13835 > > > > Mirek > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > Since this is the only missing gem that prevents switching from > production to development, can we please include it with the > production RPMs? It will be important to easily let support people > switch a customer's install to increase debug logging. I just saw /etc/sysconfig/katello KATELLO_LOGGING so switching to development isn't needed. (Still would vote to include redcarpet if that's the only missing gem.) I didn't see a flag in katello-configure to change this value; worth adding? > > Thanks! > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From daviddavis at redhat.com Thu Oct 11 18:42:42 2012 From: daviddavis at redhat.com (David Davis) Date: Thu, 11 Oct 2012 14:42:42 -0400 (EDT) Subject: [katello-devel] Content view definition command Message-ID: <1430322399.10623803.1349980962079.JavaMail.root@redhat.com> I am working on content view definitions and having a content_view_definition command is starting to cause problems due to its length: https://dl.dropbox.com/u/29929/Screenshot%20at%202012-10-11%2014%3A38%3A42.png It would be nice to shorten it to make it easier to develop the cli command and for the end user to type. I was thinking of some options: cv_definition content_definition view_definition content_view_def definition Anyone have a preference? David From ehelms at redhat.com Thu Oct 11 18:45:30 2012 From: ehelms at redhat.com (Eric Helms) Date: Thu, 11 Oct 2012 14:45:30 -0400 Subject: [katello-devel] Content view definition command In-Reply-To: <1430322399.10623803.1349980962079.JavaMail.root@redhat.com> References: <1430322399.10623803.1349980962079.JavaMail.root@redhat.com> Message-ID: <507713CA.7000608@redhat.com> On 10/11/2012 02:42 PM, David Davis wrote: > I am working on content view definitions and having a content_view_definition command is starting to cause problems due to its length: > > https://dl.dropbox.com/u/29929/Screenshot%20at%202012-10-11%2014%3A38%3A42.png > > It would be nice to shorten it to make it easier to develop the cli command and for the end user to type. I was thinking of some options: > > cv_definition > content_definition > view_definition > content_view_def > definition > > Anyone have a preference? > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Is it possible to do subcommands so all definition related items lived under that? katello content_view definition -Eric From jsherril at redhat.com Thu Oct 11 18:47:33 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 11 Oct 2012 14:47:33 -0400 Subject: [katello-devel] Content view definition command In-Reply-To: <507713CA.7000608@redhat.com> References: <1430322399.10623803.1349980962079.JavaMail.root@redhat.com> <507713CA.7000608@redhat.com> Message-ID: <50771445.9030508@redhat.com> On 10/11/2012 02:45 PM, Eric Helms wrote: > On 10/11/2012 02:42 PM, David Davis wrote: >> I am working on content view definitions and having a >> content_view_definition command is starting to cause problems due to >> its length: >> >> https://dl.dropbox.com/u/29929/Screenshot%20at%202012-10-11%2014%3A38%3A42.png >> >> >> It would be nice to shorten it to make it easier to develop the cli >> command and for the end user to type. I was thinking of some options: >> >> cv_definition >> content_definition >> view_definition >> content_view_def >> definition >> >> Anyone have a preference? >> >> David >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Is it possible to do subcommands so all definition related items lived > under that? > > katello content_view definition > > -Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I thought i remembered our cli didn't support more than a single level of command organization. Is that correct? -Justin From bkearney at redhat.com Thu Oct 11 18:50:48 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 11 Oct 2012 14:50:48 -0400 Subject: [katello-devel] Content view definition command In-Reply-To: <50771445.9030508@redhat.com> References: <1430322399.10623803.1349980962079.JavaMail.root@redhat.com> <507713CA.7000608@redhat.com> <50771445.9030508@redhat.com> Message-ID: <50771508.20105@redhat.com> On 10/11/2012 02:47 PM, Justin Sherrill wrote: > On 10/11/2012 02:45 PM, Eric Helms wrote: >> On 10/11/2012 02:42 PM, David Davis wrote: >>> I am working on content view definitions and having a >>> content_view_definition command is starting to cause problems due to >>> its length: >>> >>> https://dl.dropbox.com/u/29929/Screenshot%20at%202012-10-11%2014%3A38%3A42.png >>> >>> >>> It would be nice to shorten it to make it easier to develop the cli >>> command and for the end user to type. I was thinking of some options: >>> >>> cv_definition >>> content_definition >>> view_definition >>> content_view_def >>> definition >>> >>> Anyone have a preference? >>> >>> David >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> Is it possible to do subcommands so all definition related items lived >> under that? >> >> katello content_view definition >> >> -Eric >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > I thought i remembered our cli didn't support more than a single level > of command organization. Is that correct? > Possibly, but it is fungible enought it may work :) -- bk From mmccune at redhat.com Thu Oct 11 19:02:49 2012 From: mmccune at redhat.com (Mike McCune) Date: Thu, 11 Oct 2012 12:02:49 -0700 Subject: [katello-devel] Content view definition command In-Reply-To: <507713CA.7000608@redhat.com> References: <1430322399.10623803.1349980962079.JavaMail.root@redhat.com> <507713CA.7000608@redhat.com> Message-ID: <507717D9.7010809@redhat.com> On 10/11/2012 11:45 AM, Eric Helms wrote: > On 10/11/2012 02:42 PM, David Davis wrote: >> I am working on content view definitions and having a content_view_definition command is starting to cause problems due to its length: >> >> https://dl.dropbox.com/u/29929/Screenshot%20at%202012-10-11%2014%3A38%3A42.png >> >> It would be nice to shorten it to make it easier to develop the cli command and for the end user to type. I was thinking of some options: >> >> cv_definition >> content_definition >> view_definition >> content_view_def >> definition >> >> Anyone have a preference? >> >> David >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Is it possible to do subcommands so all definition related items lived > under that? > > katello content_view definition > the question too, do we want to really make users have to understand and act on 'content views' and 'content view definitions' as separate objects? Why not just 'content views'? Mike From kybaker at redhat.com Thu Oct 11 20:35:25 2012 From: kybaker at redhat.com (Kyle Baker) Date: Thu, 11 Oct 2012 16:35:25 -0400 (EDT) Subject: [katello-devel] Content Views Content Structure Decision In-Reply-To: <582953935.19424.1349984737773.JavaMail.root@redhat.com> Message-ID: <70958691.36782.1349987725341.JavaMail.root@redhat.com> One decision that has been left up in the air for Content Views is whether the content has to be in the context of a definition or can it be promoted separately. This could mean that there is a default definition that houses all of the content similar to the library. I'm not sure if there are usecases to sway this either way. Any thoughts? Kyle Baker --- UX Team Desk 978 392 3116 IRC kylebaker From mmccune at redhat.com Thu Oct 11 20:55:08 2012 From: mmccune at redhat.com (Mike McCune) Date: Thu, 11 Oct 2012 13:55:08 -0700 Subject: [katello-devel] Content Views Content Structure Decision In-Reply-To: <70958691.36782.1349987725341.JavaMail.root@redhat.com> References: <70958691.36782.1349987725341.JavaMail.root@redhat.com> Message-ID: <5077322C.1080007@redhat.com> On 10/11/2012 01:35 PM, Kyle Baker wrote: > One decision that has been left up in the air for Content Views is whether the content has to be in the context of a definition or can it be promoted separately. This could mean that there is a default definition that houses all of the content similar to the library. I'm not sure if there are usecases to sway this either way. Any thoughts? > for the first pass we are going to support promoting content into an environment in the same way you do now and systems do not need to be associated directly to a view. Content Views will be an additional specification you can use either with an Activation Key or possibly with an additional flag in RHSM, eg: --contentview. If none is specified you get the system registered to the environment just as you do now and the system sees what we are calling the 'Default View': https://fedorahosted.org/katello/wiki/ContentViews#Definitions Eventually we may decide that Content Views are the one and only way to represent content to a system and we end up no longer supporting promotion of content through the standard mechanism we do now. Does that help? Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From kybaker at redhat.com Thu Oct 11 21:02:48 2012 From: kybaker at redhat.com (Kyle Baker) Date: Thu, 11 Oct 2012 17:02:48 -0400 (EDT) Subject: [katello-devel] Content Views Content Structure Decision In-Reply-To: <5077322C.1080007@redhat.com> Message-ID: <1161629452.49581.1349989368677.JavaMail.root@redhat.com> ----- Original Message ----- > On 10/11/2012 01:35 PM, Kyle Baker wrote: > > One decision that has been left up in the air for Content Views is > > whether the content has to be in the context of a definition or > > can it be promoted separately. This could mean that there is a > > default definition that houses all of the content similar to the > > library. I'm not sure if there are usecases to sway this either > > way. Any thoughts? > > > > for the first pass we are going to support promoting content into an > environment in the same way you do now and systems do not need to be > associated directly to a view. Content Views will be an additional > specification you can use either with an Activation Key or possibly > with > an additional flag in RHSM, eg: --contentview. If none is specified > you > get the system registered to the environment just as you do now and > the > system sees what we are calling the 'Default View': > > https://fedorahosted.org/katello/wiki/ContentViews#Definitions > > Eventually we may decide that Content Views are the one and only way > to > represent content to a system and we end up no longer supporting > promotion of content through the standard mechanism we do now. > > Does that help? It sure does. I will update the wireframes to reflect this. > Mike > > -- > Mike McCune > mmccune AT redhat.com > Red Hat Engineering | Portland, OR > Systems Management | 650-254-4248 > From inecas at redhat.com Thu Oct 11 21:07:23 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 11 Oct 2012 23:07:23 +0200 Subject: [katello-devel] Help! How to turn a production install into development? In-Reply-To: <1538970164.7389839.1349979551056.JavaMail.root@redhat.com> References: <1538970164.7389839.1349979551056.JavaMail.root@redhat.com> Message-ID: <5077350B.4070508@redhat.com> On 10/11/2012 08:19 PM, Tom McKay wrote: > > ----- Original Message ----- >> From: "Tom McKay" >> To: "Miroslav Suchy" >> Cc: katello-devel at redhat.com >> Sent: Thursday, October 11, 2012 2:06:07 PM >> Subject: Re: [katello-devel] Help! How to turn a production install into development? >> >> >> >> ----- Original Message ----- >>> From: "Miroslav Suchy" >>> To: katello-devel at redhat.com >>> Sent: Thursday, October 11, 2012 12:54:47 PM >>> Subject: Re: [katello-devel] Help! How to turn a production install >>> into development? >>> >>> On 11.10.2012 18:32, Tom McKay wrote: >>>> then requires redcarpet gem, which I can't seem to >>>> find/install. >>> yum install rubygem-redcarpet >>> >>> http://koji.fedoraproject.org/koji/packageinfo?packageID=13835 >>> >>> Mirek >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> Since this is the only missing gem that prevents switching from >> production to development, can we please include it with the >> production RPMs? It will be important to easily let support people >> switch a customer's install to increase debug logging. > I just saw /etc/sysconfig/katello KATELLO_LOGGING so switching to development isn't needed. (Still would vote to include redcarpet if that's the only missing gem.) Yop, switching to development mode just to increase logging is a bit overkill. I also wouldn't say it's the only gem missing. Just take a look at the Gemfile and all the gems under @@@DEV_ONLY@@@. Many of them are just for running tests, but still. Development mode = begin able to develop. Production machine should never be run in development mode, because it's not the way it should be used. And I'm quite happy that the missing gem causes that to fall before it causes more harm. > > I didn't see a flag in katello-configure to change this value; worth adding? Since we now support rerunning katello-configure more times, this is good point. I vote for it, if there is not something that would cause trouble. -- Ivan > >> Thanks! >> >> _______________________________________________ >> 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 jsherril at redhat.com Thu Oct 11 21:22:22 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 11 Oct 2012 17:22:22 -0400 Subject: [katello-devel] Help! How to turn a production install into development? In-Reply-To: <1538970164.7389839.1349979551056.JavaMail.root@redhat.com> References: <1538970164.7389839.1349979551056.JavaMail.root@redhat.com> Message-ID: <5077388E.1040102@redhat.com> On 10/11/2012 02:19 PM, Tom McKay wrote: > > ----- Original Message ----- >> From: "Tom McKay" >> To: "Miroslav Suchy" >> Cc: katello-devel at redhat.com >> Sent: Thursday, October 11, 2012 2:06:07 PM >> Subject: Re: [katello-devel] Help! How to turn a production install into development? >> >> >> >> ----- Original Message ----- >>> From: "Miroslav Suchy" >>> To: katello-devel at redhat.com >>> Sent: Thursday, October 11, 2012 12:54:47 PM >>> Subject: Re: [katello-devel] Help! How to turn a production install >>> into development? >>> >>> On 11.10.2012 18:32, Tom McKay wrote: >>>> then requires redcarpet gem, which I can't seem to >>>> find/install. >>> yum install rubygem-redcarpet >>> >>> http://koji.fedoraproject.org/koji/packageinfo?packageID=13835 >>> >>> Mirek >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> Since this is the only missing gem that prevents switching from >> production to development, can we please include it with the >> production RPMs? It will be important to easily let support people >> switch a customer's install to increase debug logging. > I just saw /etc/sysconfig/katello KATELLO_LOGGING so switching to development isn't needed. (Still would vote to include redcarpet if that's the only missing gem.) > > I didn't see a flag in katello-configure to change this value; worth adding? We also provide a way to change it in katello.yml: #Allowed log levels: 'debug', 'info', 'warn', 'error', 'fatal' #log_level: warn #log_level_sql: fatal Changing to development is NOT a good way to get additional logging. I'm not sure why we have two ways to set logging. I prefer the katello.yml way myself... -Justin > >> Thanks! >> >> _______________________________________________ >> 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 Fri Oct 12 07:56:54 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 12 Oct 2012 09:56:54 +0200 Subject: [katello-devel] Content view definition command In-Reply-To: <1430322399.10623803.1349980962079.JavaMail.root@redhat.com> References: <1430322399.10623803.1349980962079.JavaMail.root@redhat.com> Message-ID: <20121012075654.GA4739@lzapx.brq.redhat.com> Btw we do have tab completion in both bash cli and shell cli. We may need to update our completion file tho. I am planning to do this for K11 soon. LZ On Thu, Oct 11, 2012 at 02:42:42PM -0400, David Davis wrote: > I am working on content view definitions and having a content_view_definition command is starting to cause problems due to its length: > > https://dl.dropbox.com/u/29929/Screenshot%20at%202012-10-11%2014%3A38%3A42.png > > It would be nice to shorten it to make it easier to develop the cli command and for the end user to type. I was thinking of some options: > > cv_definition > content_definition > view_definition > content_view_def > definition > > Anyone have a preference? > > David > > _______________________________________________ > 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 Oct 12 08:09:03 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 12 Oct 2012 10:09:03 +0200 Subject: [katello-devel] Help! How to turn a production install into development? In-Reply-To: <1538970164.7389839.1349979551056.JavaMail.root@redhat.com> References: <2004913417.7387205.1349978767029.JavaMail.root@redhat.com> <1538970164.7389839.1349979551056.JavaMail.root@redhat.com> Message-ID: <20121012080903.GB4739@lzapx.brq.redhat.com> Ok, let me summarize the status: 1) Default installation does not have any development gems 2) You can switch logging level in /etc/sysconfig/katello, this is the right place to do it. There is no way of configuring this via katello-configure. Just sed it, if you need to, but be prepared the logs can be really big if you set DEBUG! 3) Mirek is working on katello-devel metapackage that will install all the development rubygems I assume. This work is not done yet. LZ On Thu, Oct 11, 2012 at 02:19:11PM -0400, Tom McKay wrote: > > > ----- Original Message ----- > > From: "Tom McKay" > > To: "Miroslav Suchy" > > Cc: katello-devel at redhat.com > > Sent: Thursday, October 11, 2012 2:06:07 PM > > Subject: Re: [katello-devel] Help! How to turn a production install into development? > > > > > > > > ----- Original Message ----- > > > From: "Miroslav Suchy" > > > To: katello-devel at redhat.com > > > Sent: Thursday, October 11, 2012 12:54:47 PM > > > Subject: Re: [katello-devel] Help! How to turn a production install > > > into development? > > > > > > On 11.10.2012 18:32, Tom McKay wrote: > > > > then requires redcarpet gem, which I can't seem to > > > > find/install. > > > > > > yum install rubygem-redcarpet > > > > > > http://koji.fedoraproject.org/koji/packageinfo?packageID=13835 > > > > > > Mirek > > > > > > _______________________________________________ > > > katello-devel mailing list > > > katello-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > > Since this is the only missing gem that prevents switching from > > production to development, can we please include it with the > > production RPMs? It will be important to easily let support people > > switch a customer's install to increase debug logging. > > I just saw /etc/sysconfig/katello KATELLO_LOGGING so switching to development isn't needed. (Still would vote to include redcarpet if that's the only missing gem.) > > I didn't see a flag in katello-configure to change this value; worth adding? > > > > > Thanks! > > > > _______________________________________________ > > 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 Fri Oct 12 08:50:34 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 12 Oct 2012 10:50:34 +0200 Subject: [katello-devel] We have 28 failing cli tests Message-ID: <20121012085034.GC4739@lzapx.brq.redhat.com> 325 tests, 28 failed http://pastebin.com/raw.php?i=Excxi2Fa This is not good for K11. Anyone whos code was merged recently please check it out and note here If we fix it until 12:30 GMT (07:30 EDT) I can re-test next nightly build and try to release this week. Otherwise I will be testing this on Monday. Please do not merge anything than test fixes (or the three bugs Garik mentioned yesterday). LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Oct 12 08:51:15 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 12 Oct 2012 10:51:15 +0200 Subject: [katello-devel] NO MERGE window started In-Reply-To: <5076D200.9080700@redhat.com> References: <20121011134250.GH4728@lzapx.brq.redhat.com> <5076D200.9080700@redhat.com> Message-ID: <20121012085115.GD4739@lzapx.brq.redhat.com> Thanks Garik! I will look into the bugs. LZ On Thu, Oct 11, 2012 at 04:04:48PM +0200, Garik Khachikyan wrote: > On 11/10/12 15:42, Lukas Zapletal wrote: > >Team, > > > >we have been fixing some CLI bugs today. I ask you NOT to merge any work > >until I branch Katello tomorrow. I expect the following work to be > >merged: > > > >- gpg keys + test fix (dmitri) > >- cli tests fixes (msuchy) > >- cli fixes (lzap) > >- any other bugs you think are blockers for K11 (pls ping me) > > > >I am gonna open master for business tomorrow if it turns out nightly is > >in good condition. I would like to go through the UI and to test it a > >bit later today - if anyone can help me I'd appreciate (I assume QA > >folks have no time for that - if there is any chance of running some UI > >test suite against today's master please do and ping me with results). > > > >LZ > > > Lukas, > > From QE point of view we have run just today the katello from: > > katello-1.1.13-1.git.161.96aa2bd.el6.noarch > katello-cli-1.1.9-1.git.128.d72c83d.el6.noarch > > > and so far all are pretty good! > > there are just 3 bugs: > https://bugzilla.redhat.com/show_bug.cgi?id=862753 > https://bugzilla.redhat.com/show_bug.cgi?id=865366 > https://bugzilla.redhat.com/show_bug.cgi?id=865397 > > which I would not consider critical/blocker for the release anyway :) > > So my "green" for 1.1 > > Happy release. > Garik > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From mbacovsk at redhat.com Fri Oct 12 10:21:34 2012 From: mbacovsk at redhat.com (Martin Bacovsky) Date: Fri, 12 Oct 2012 12:21:34 +0200 Subject: [katello-devel] We have 28 failing cli tests In-Reply-To: <20121012085034.GC4739@lzapx.brq.redhat.com> References: <20121012085034.GC4739@lzapx.brq.redhat.com> Message-ID: <5077EF2E.7000806@redhat.com> On 10/12/2012 10:50 AM, Lukas Zapletal wrote: > 325 tests, 28 failed > > http://pastebin.com/raw.php?i=Excxi2Fa > > This is not good for K11. Anyone whos code was merged recently please > check it out and note here > > If we fix it until 12:30 GMT (07:30 EDT) I can re-test next nightly > build and try to release this week. Otherwise I will be testing this on > Monday. > > Please do not merge anything than test fixes (or the three bugs Garik > mentioned yesterday). > > LZ > Yesterday I experienced strange behavior of cli tests. Repetitive running the same tests on same instance resulted in 18, 16, 5, and 17 failing tests respectively. Most of the issues was traced to yum complaining to sync some repos. Today it worked well on fresh instance. May that be related? Martin From lzap at redhat.com Fri Oct 12 12:06:59 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 12 Oct 2012 14:06:59 +0200 Subject: [katello-devel] NO MERGE window started In-Reply-To: <5076D200.9080700@redhat.com> References: <20121011134250.GH4728@lzapx.brq.redhat.com> <5076D200.9080700@redhat.com> Message-ID: <20121012120659.GE4739@lzapx.brq.redhat.com> On Thu, Oct 11, 2012 at 04:04:48PM +0200, Garik Khachikyan wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=862753 Not important for K 1.1, I agree. > https://bugzilla.redhat.com/show_bug.cgi?id=865366 Dmitri fixed it already. > https://bugzilla.redhat.com/show_bug.cgi?id=865397 I am going to fix now, not a blocker too. LZ Thanks, right now we just generated new repo which should contain much better build, I am gonna test it now. -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Fri Oct 12 12:15:43 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 12 Oct 2012 08:15:43 -0400 Subject: [katello-devel] Content view definition command In-Reply-To: <507717D9.7010809@redhat.com> References: <1430322399.10623803.1349980962079.JavaMail.root@redhat.com> <507713CA.7000608@redhat.com> <507717D9.7010809@redhat.com> Message-ID: <507809EF.8000408@redhat.com> On 10/11/2012 03:02 PM, Mike McCune wrote: > On 10/11/2012 11:45 AM, Eric Helms wrote: >> On 10/11/2012 02:42 PM, David Davis wrote: >>> I am working on content view definitions and having a >>> content_view_definition command is starting to cause problems due to >>> its length: >>> >>> https://dl.dropbox.com/u/29929/Screenshot%20at%202012-10-11%2014%3A38%3A42.png >>> >>> >>> It would be nice to shorten it to make it easier to develop the cli >>> command and for the end user to type. I was thinking of some options: >>> >>> cv_definition >>> content_definition >>> view_definition >>> content_view_def >>> definition >>> >>> Anyone have a preference? >>> >>> David >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> Is it possible to do subcommands so all definition related items lived >> under that? >> >> katello content_view definition >> > > the question too, do we want to really make users have to understand and > act on 'content views' and 'content view definitions' as separate objects? > > Why not just 'content views'? I think if if you set up rules, you will be able to splat out 2 different snapshots from that rules. So, we will need names for the splatter and the splatee. -- bk From lzap at redhat.com Fri Oct 12 12:34:36 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 12 Oct 2012 14:34:36 +0200 Subject: [katello-devel] We have 28 failing cli tests In-Reply-To: <5077EF2E.7000806@redhat.com> References: <20121012085034.GC4739@lzapx.brq.redhat.com> <5077EF2E.7000806@redhat.com> Message-ID: <20121012123436.GF4739@lzapx.brq.redhat.com> On Fri, Oct 12, 2012 at 12:21:34PM +0200, Martin Bacovsky wrote: > Yesterday I experienced strange behavior of cli tests. Repetitive > running the same tests on same instance resulted in 18, 16, 5, and > 17 failing tests respectively. Most of the issues was traced to yum > complaining to sync some repos. Today it worked well on fresh > instance. May that be related? > Cli tests sometimes fail because Pulp reports "repo already exists", its like fith test or something. Than many of them fails, we have been tracking this several times. But this is not the case. I just built nightly from master, installed clean instance and tests are still failing. Most of them are related to Candlepin and GPG: undefined method `gpgUrl' for nil:NilClass or uninitialized constant Candlepin Mirek reported this too - we need to get these fixed. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Fri Oct 12 13:13:45 2012 From: daviddavis at redhat.com (David Davis) Date: Fri, 12 Oct 2012 09:13:45 -0400 (EDT) Subject: [katello-devel] Content view definition command In-Reply-To: <507809EF.8000408@redhat.com> Message-ID: <939335792.11361682.1350047625710.JavaMail.root@redhat.com> I think you could access the two separately but they would all be under the content_view command. Just to throw out something to illustrate this point: katello content_view definitions (list all the content_view_definitions) katello content_view publish --definition=Database (create a new content view from the content view defininition) katello content_view define or katello content_view create_definition (create a new content view definition) katello content_view update_definition --definition=Database --add_filter=stable (or something) katello content_view promote --view=MongoDB --env=Dev (promote the content view to the Dev environment) katello content_view list --env=Dev (see the content views in Dev) So you could access the definitions and views separately but you'd still call the same content_view command. David ----- Original Message ----- > From: "Bryan Kearney" > To: katello-devel at redhat.com > Sent: Friday, October 12, 2012 8:15:43 AM > Subject: Re: [katello-devel] Content view definition command > > On 10/11/2012 03:02 PM, Mike McCune wrote: > > On 10/11/2012 11:45 AM, Eric Helms wrote: > >> On 10/11/2012 02:42 PM, David Davis wrote: > >>> I am working on content view definitions and having a > >>> content_view_definition command is starting to cause problems due > >>> to > >>> its length: > >>> > >>> https://dl.dropbox.com/u/29929/Screenshot%20at%202012-10-11%2014%3A38%3A42.png > >>> > >>> > >>> It would be nice to shorten it to make it easier to develop the > >>> cli > >>> command and for the end user to type. I was thinking of some > >>> options: > >>> > >>> cv_definition > >>> content_definition > >>> view_definition > >>> content_view_def > >>> definition > >>> > >>> Anyone have a preference? > >>> > >>> David > >>> > >>> _______________________________________________ > >>> katello-devel mailing list > >>> katello-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/katello-devel > >> Is it possible to do subcommands so all definition related items > >> lived > >> under that? > >> > >> katello content_view definition > >> > > > > the question too, do we want to really make users have to > > understand and > > act on 'content views' and 'content view definitions' as separate > > objects? > > > > Why not just 'content views'? > > I think if if you set up rules, you will be able to splat out 2 > different snapshots from that rules. So, we will need names for the > splatter and the splatee. > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Fri Oct 12 13:30:50 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 12 Oct 2012 15:30:50 +0200 Subject: [katello-devel] bug in commit 5b910dcc5d9b0771bedb28425df0072edee9f659 In-Reply-To: <50770D57.4070806@redhat.com> References: <50770D57.4070806@redhat.com> Message-ID: <20121012133050.GG4739@lzapx.brq.redhat.com> We have fixed this. LZ On Thu, Oct 11, 2012 at 08:17:59PM +0200, Miroslav Suchy wrote: > Dmitri, > in commit 5b910dcc5d9b0771bedb28425df0072edee9f659 > you introduced on several places > > + found = ::Resources::Candlepin::Content.get(id) > + ::Candlepin::Content.new(found) > > + @content = ::Candlepin::Content.new(params[:content] || > params["content"]) > > ... and more > > and the leading :: does not work (at least on some places). > I'm not sure if it should be > Candlepin::Content > or > Resources::Candlepin::Content > > so I will leave the fix on you. > > Can you please fix it. Thanks. > > 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 lzap at redhat.com Fri Oct 12 13:42:43 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 12 Oct 2012 15:42:43 +0200 Subject: [katello-devel] NO MERGE window started In-Reply-To: <20121011134250.GH4728@lzapx.brq.redhat.com> References: <20121011134250.GH4728@lzapx.brq.redhat.com> Message-ID: <20121012134243.GH4739@lzapx.brq.redhat.com> We have fixed all important bugs, I am working on the release. PLEASE DO NOT MERGE ANYTHING I hope I will manage to do the release today, if not, I will finish with this Monday morning. LZ On Thu, Oct 11, 2012 at 03:42:50PM +0200, Lukas Zapletal wrote: > Team, > > we have been fixing some CLI bugs today. I ask you NOT to merge any work > until I branch Katello tomorrow. I expect the following work to be > merged: > > - gpg keys + test fix (dmitri) > - cli tests fixes (msuchy) > - cli fixes (lzap) > - any other bugs you think are blockers for K11 (pls ping me) > > I am gonna open master for business tomorrow if it turns out nightly is > in good condition. I would like to go through the UI and to test it a > bit later today - if anyone can help me I'd appreciate (I assume QA > folks have no time for that - if there is any chance of running some UI > test suite against today's master please do and ping me with results). > > LZ > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > 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 Oct 12 15:05:07 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 12 Oct 2012 17:05:07 +0200 Subject: [katello-devel] Repoclosure for Katello 1.1 Message-ID: <20121012150507.GJ4739@lzapx.brq.redhat.com> Hello, once build is done in Koji I will announce Katello 1.1 RC1 and it should be hopefully the last candidate. Here are repoclosure logs for F16 and RHEL6: [root at aa ~]# repoclosure -r katello -l fedora -l candlepin -l foreman -lpulp Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 5 candlepin fedora foreman katello pulp Num Packages in Repos: 25211 package: katello-agent-1.1.2-1.fc16.noarch from katello unresolved deps: subscription-manager package: katello-cli-unit-tests-1.1.9-1.git.130.28f5d12.fc16.noarch from katello unresolved deps: [root at aa ~]# [root at aa ~]# repoclosure -r katello -l fedora -l candlepin -l foreman -l pulp Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 5 candlepin fedora foreman katello pulp Num Packages in Repos: 25211 package: katello-agent-1.1.2-1.fc16.noarch from katello unresolved deps: subscription-manager package: katello-cli-unit-tests-1.1.9-1.git.130.28f5d12.fc16.noarch from katello unresolved deps: python-mock package: katello-devel-1.1.13-1.git.177.3e34f2e.fc16.noarch from katello unresolved deps: rubygem(ZenTest) >= 0:4.4.0 rubygem(autotest-rails) >= 0:4.1.0 rubygem(js-routes) rubygem(logical-insight) rubygem(minitest-rails) rubygem(minitest_tu_shim) rubygem(newrelic_rpm) rubygem(rails-dev-boost) rubygem(redcarpet) package: katello-devel-jshintrb-1.1.13-1.git.177.3e34f2e.fc16.noarch from katello unresolved deps: rubygem(logical-insight) rubygem(newrelic_rpm) package: katello-devel-profiling-1.1.13-1.git.177.3e34f2e.fc16.noarch from katello unresolved deps: rubygem(ruby-prof) package: rubygem-pdf-writer-1.1.8-6.fc16.noarch from katello unresolved deps: rubygem(transaction-simple) >= 0:1.3 package: rubygem-prawn-1.0.0-3.rc1.fc16.noarch from katello unresolved deps: rubygem(pdf-reader) >= 0:0.9.0 rubygem(ttfunk) >= 0:1.0.2 rubygem(ttfunk) < 0:1.1 package: rubygem-tire-0.3.13-5.fc16.noarch from katello unresolved deps: rubygem(hashr) >= 0:0.0.16 [root at bb ~]# repoclosure -r katello -l eng-Server -l eng-optional-x86_64-os -l epel -l candlepin -l foreman -l pulp Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 7 candlepin eng-Server eng-optional-x86_64-os epel foreman katello pulp Num Packages in Repos: 14294 package: katello-devel-1.1.13-1.git.177.3e34f2e.el6.noarch from katello unresolved deps: rubygem(ZenTest) >= 0:4.4.0 rubygem(autotest-rails) >= 0:4.1.0 rubygem(js-routes) rubygem(logical-insight) rubygem(minitest-rails) rubygem(minitest_tu_shim) rubygem(newrelic_rpm) rubygem(rails-dev-boost) rubygem(rspec-rails) >= 0:2.0.0 rubygem(webrat) >= 0:0.7.3 rubygem(yard) >= 0:0.5.3 package: katello-devel-jshintrb-1.1.13-1.git.177.3e34f2e.el6.noarch from katello unresolved deps: rubygem(logical-insight) rubygem(newrelic_rpm) package: katello-devel-profiling-1.1.13-1.git.177.3e34f2e.el6.noarch from katello unresolved deps: rubygem(ruby-prof) package: katello-devel-test-1.1.13-1.git.177.3e34f2e.el6.noarch from katello unresolved deps: rubygem(vcr) rubygem(webmock) I need to test if the missing deps for rubygem-prawn are not an issue. RHEL is fine. -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Fri Oct 12 15:45:29 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 12 Oct 2012 16:45:29 +0100 Subject: [katello-devel] Summary: Katello slow tests Message-ID: <50783B19.3020708@redhat.com> A spent a couple of days in total looking at our developer tests and their performance (I managed to get ruby-prof to profile a few test suites, which was a great help. I have the files for those who are interested). Some stats: we have 2280 or so tests. The total execution time of all specs on my machine is about 14 minutes. About two thirds of tests are slower than 0.1 sec. Majority, if not all tests in spec/controllers access the db. In some test suites time spent on db operations amounts to high 40-ties of total test run time. Tests in spec/models have no clear separation between model and glue-layer tests, besides context changes. Some areas of improvement: - Turn controller tests into real unit tests - isolate them from the db. This will be easier if something like Factory-Girl [1] was used for object graph generation. - we have a few tests that exercise views, perhaps they should be moved out into a separate module, as they can be quite slow. - Break up model tests into: - tests that access db (test queries, etc) - tests that exercise orchestration logic. These will effectively be unit-tests. Bryan: I think the stories can be broken by type of tests, either one story per test-suite (ie controller tests, model tests), with work broken up by model/controller. Alternatively, we could have one story per test (ie modify systems_controller_spec, etc). Please let me which is more convenient for you. Thoughts, opinions? -d [1] https://github.com/thoughtbot/factory_girl -------------- next part -------------- An HTML attachment was scrubbed... URL: From lzap at redhat.com Fri Oct 12 15:56:29 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 12 Oct 2012 17:56:29 +0200 Subject: [katello-devel] Announcing Katello 1.1 RC1 Message-ID: <20121012155629.GK4739@lzapx.brq.redhat.com> Hello, the nightly repository currently contains Katello 1.1 RC1 build. Please test it, if there are no major issues I will branch Monday morning and release Katello 1.1! This release will be available only for Fedora 16 and RHEL6. ps - there is one cli test failing: add product to ak activation_key update --add_subscription= --name=ak1_xj1yX0rFHXpw --environment=env_rhsm_xj1yX0rFHXpw --org=org_rhsm_xj1yX0rFHXpw undefined method `[]' for nil:NilClass we will fix this on Monday LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Fri Oct 12 16:52:34 2012 From: daviddavis at redhat.com (David Davis) Date: Fri, 12 Oct 2012 12:52:34 -0400 (EDT) Subject: [katello-devel] Summary: Katello slow tests In-Reply-To: <50783B19.3020708@redhat.com> Message-ID: <818773905.11632919.1350060754970.JavaMail.root@redhat.com> Dimitri, Currently Mike has a change that he is working on adding to master that incorporates the parallel_tests gem into the code. Using that, he was able to bring the total test time from 12-14 minutes to 2 minutes in the test/jenkins environment and to about 4 minutes on his local environment. Also, Eric and I have added FactoryGirl to the code on our pulpv2 branch. I'll probably give a demo of how to use it to speed up tests at the next Deep Dive. Your other ideas sound good too. Let me know if you want to coordinate something as I could help modifying the existing tests to access the database less. From previous experience, IO operations during testing tend to be the bottleneck. Thanks. David ----- Original Message ----- > From: "Dmitri Dolguikh" > To: "katello-devel" > Sent: Friday, October 12, 2012 11:45:29 AM > Subject: [katello-devel] Summary: Katello slow tests > > > A spent a couple of days in total looking at our developer tests and > their performance (I managed to get ruby-prof to profile a few test > suites, which was a great help. I have the files for those who are > interested). > > > Some stats: we have 2280 or so tests. The total execution time of all > specs on my machine is about 14 minutes. About two thirds of tests > are slower than 0.1 sec. Majority, if not all tests in > spec/controllers access the db. In some test suites time spent on db > operations amounts to high 40-ties of total test run time. Tests in > spec/models have no clear separation between model and glue-layer > tests, besides context changes. > > > Some areas of improvement: > - Turn controller tests into real unit tests - isolate them from the > db. This will be easier if something like Factory-Girl [1] was used > for object graph generation. > - we have a few tests that exercise views, perhaps they should be > moved out into a separate module, as they can be quite slow. > - Break up model tests into: > - tests that access db (test queries, etc) > - tests that exercise orchestration logic. These will effectively be > unit-tests. > > > Bryan: I think the stories can be broken by type of tests, either one > story per test-suite (ie controller tests, model tests), with work > broken up by model/controller. Alternatively, we could have one > story per test (ie modify systems_controller_spec, etc). Please let > me which is more convenient for you. > > > Thoughts, opinions? > -d > > > > [1] https://github.com/thoughtbot/factory_girl > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From msuchy at redhat.com Fri Oct 12 17:14:01 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Fri, 12 Oct 2012 19:14:01 +0200 Subject: [katello-devel] Repoclosure for Katello 1.1 In-Reply-To: <20121012150507.GJ4739@lzapx.brq.redhat.com> References: <20121012150507.GJ4739@lzapx.brq.redhat.com> Message-ID: <50784FD9.2000002@redhat.com> On 12.10.2012 17:05, Lukas Zapletal wrote: > I need to test if the missing deps for rubygem-prawn are not an issue. RHEL is fine. And so is Fedora. I know it because I get it into Fedora - all of them. Mirek From ehelms at redhat.com Fri Oct 12 17:15:03 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 12 Oct 2012 13:15:03 -0400 Subject: [katello-devel] Runcible - replacing classes with instances In-Reply-To: <50768E53.1090807@redhat.com> References: <50768E53.1090807@redhat.com> Message-ID: <50785017.80400@redhat.com> On 10/11/2012 05:16 AM, Petr Chalupa wrote: > Hi > > I like what you are doing around Pulp v2, Runcible and usage of vcr is > great. > > I would have one suggestion though to replace class-implementation of > runcible with instances. I would suggest to move all the > functionality/methods from class (Runcible::Base, > Runcible::Resources::*) to instances to avoid some limitations: > > - gem cannot be used to connect to more then one Pulp instance, config > is defined globally While the config is in theory defined globally, you could easily set the config before a call to point to another pulp instance. Which, as I understand it, would be the same if we were using an instance based approach. Instead we'd just be passing the config data to the instance at creation time and then making the API call for every place there was an API call. > - Resources are defined globally, you cannot stub just something in tests > This I don't entirely follow - if you wouldn't mind expounding a bit. > Also imho it is good practice not to create singletons unless it is > really needed. Singletons can be defined in Katello later (like we did > in foreman_architectures, see [1]) without compromising the ability to > use different Resource instance in an object if needed, see [2][3]. > > Petr > > [1] > https://github.com/Katello/katello/blob/0dd082076ff91761e2a03353c9a340754f902749/src/lib/resources/foreman.rb > [2] > https://github.com/Katello/katello/blob/0dd082076ff91761e2a03353c9a340754f902749/src/lib/resources/abstract_model.rb#L128 > [3] > https://github.com/Katello/katello/blob/0dd082076ff91761e2a03353c9a340754f902749/src/lib/resources/foreman_model.rb#L15 > From msuchy at redhat.com Fri Oct 12 17:16:37 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Fri, 12 Oct 2012 19:16:37 +0200 Subject: [katello-devel] Summary: Katello slow tests In-Reply-To: <50783B19.3020708@redhat.com> References: <50783B19.3020708@redhat.com> Message-ID: <50785075.6060701@redhat.com> On 12.10.2012 17:45, Dmitri Dolguikh wrote: > In some test suites time spent on db operations amounts to high 40-ties > of total test run time. Tests in spec/models have no clear separation > between model and glue-layer tests, besides context changes. > > > Some areas of improvement: * Add indexes to speed up slow queries. Mirek From bkearney at redhat.com Fri Oct 12 17:27:20 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 12 Oct 2012 13:27:20 -0400 Subject: [katello-devel] Summary: Katello slow tests In-Reply-To: <50785075.6060701@redhat.com> References: <50783B19.3020708@redhat.com> <50785075.6060701@redhat.com> Message-ID: <507852F8.4090605@redhat.com> On 10/12/2012 01:16 PM, Miroslav Suchy wrote: > On 12.10.2012 17:45, Dmitri Dolguikh wrote: >> In some test suites time spent on db operations amounts to high 40-ties >> of total test run time. Tests in spec/models have no clear separation >> between model and glue-layer tests, besides context changes. >> >> >> Some areas of improvement: > > * Add indexes to speed up slow queries. I believe we did that this release. -- bk From msuchy at redhat.com Fri Oct 12 17:41:09 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Fri, 12 Oct 2012 19:41:09 +0200 Subject: [katello-devel] Summary: Katello slow tests In-Reply-To: <507852F8.4090605@redhat.com> References: <50783B19.3020708@redhat.com> <50785075.6060701@redhat.com> <507852F8.4090605@redhat.com> Message-ID: <50785635.1000009@redhat.com> On 12.10.2012 19:27, Bryan Kearney wrote: > I believe we did that this release. No, we add indexes only to *_id columns, which is good start, but it is still far from finished. Mirek From bkearney at redhat.com Fri Oct 12 17:44:38 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 12 Oct 2012 13:44:38 -0400 Subject: [katello-devel] Summary: Katello slow tests In-Reply-To: <50785635.1000009@redhat.com> References: <50783B19.3020708@redhat.com> <50785075.6060701@redhat.com> <507852F8.4090605@redhat.com> <50785635.1000009@redhat.com> Message-ID: <50785706.5000508@redhat.com> On 10/12/2012 01:41 PM, Miroslav Suchy wrote: > On 12.10.2012 19:27, Bryan Kearney wrote: >> I believe we did that this release. > > No, we add indexes only to *_id columns, which is good start, but it is > still far from finished. I thought we got all ID and FK? -- bk From msuchy at redhat.com Fri Oct 12 17:44:03 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Fri, 12 Oct 2012 19:44:03 +0200 Subject: [katello-devel] Announcing Katello 1.1 RC1 In-Reply-To: <20121012155629.GK4739@lzapx.brq.redhat.com> References: <20121012155629.GK4739@lzapx.brq.redhat.com> Message-ID: <507856E3.4080009@redhat.com> On 12.10.2012 17:56, Lukas Zapletal wrote: > add product to ak > activation_key update --add_subscription= --name=ak1_xj1yX0rFHXpw > --environment=env_rhsm_xj1yX0rFHXpw --org=org_rhsm_xj1yX0rFHXpw > undefined method `[]' for nil:NilClass > > we will fix this on Monday I thought I got it with: diff --git a/src/app/models/glue/candlepin/pool.rb b/src/app/models/glue/candlepin/pool.rb index ac5b066..a62295c 100644 --- a/src/app/models/glue/candlepin/pool.rb +++ b/src/app/models/glue/candlepin/pool.rb @@ -53,7 +53,7 @@ module Glue::Candlepin::Pool end def organization - Organization.find_by_name(owner["key"]) + Organization.find_by_name(@owner["key"]) end # if defined +load_remote_data+ will be used by +lazy_accessors+ but even with this patch (which I believe should be applied anyway) it is still failing with the same error. :( Mirek From adprice at redhat.com Fri Oct 12 17:57:53 2012 From: adprice at redhat.com (Adam Price) Date: Fri, 12 Oct 2012 13:57:53 -0400 (EDT) Subject: [katello-devel] Custom Info! In-Reply-To: <473095639.14225165.1350064450603.JavaMail.root@redhat.com> Message-ID: <552463768.14226962.1350064673691.JavaMail.root@redhat.com> hello folks, I just submitted a pull-request [1] for fixes to the Custom Info code which include: 1. enforcing unique keynames (makes things a lot easier/simpler) 2. allowing null values and i finished up the default custom info keys for systems by orgs with the ability to: 1. add custom keys to an org 2. remove custom keys to an org 3. apply keys to currently existing systems 4. automatically add default custom keys to newly created systems with tests for all. you'll need to run 'rake db:migrate'. Please review the pull-request and make some comments! Thanks. [1] https://github.com/Katello/katello/pull/847 -- Adam Price adprice at redhat dot com From daviddavis at redhat.com Fri Oct 12 18:15:43 2012 From: daviddavis at redhat.com (David Davis) Date: Fri, 12 Oct 2012 14:15:43 -0400 (EDT) Subject: [katello-devel] Updated Ruby style guide Message-ID: <536465031.11669283.1350065743464.JavaMail.root@redhat.com> Hi all, I've updated the Ruby style guide mostly by fixing up the grammar problems. Also, I changed the wording regarding parentheses after method calls from being a must to being highly recommended (I think this is more inline with our code). Lastly, I pointed the linked style guide to Github's Ruby Style Guide instead of using the previous outdated one. If you have a chance, please check it out and let me know if you have any feedback. https://fedorahosted.org/katello/wiki/RubyCodeConventions I'm also thinking of reiterating the 80 characters or less per line rule in our style guide. It's currently in the Github guide and I think it's great rule given that it's in our Python guide as well and Github cuts off commits after about 80 characters (you have to scroll over). Thanks. David From lzap at redhat.com Mon Oct 15 07:11:25 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 15 Oct 2012 09:11:25 +0200 Subject: [katello-devel] Custom Info! In-Reply-To: <552463768.14226962.1350064673691.JavaMail.root@redhat.com> References: <473095639.14225165.1350064450603.JavaMail.root@redhat.com> <552463768.14226962.1350064673691.JavaMail.root@redhat.com> Message-ID: <20121015071125.GA10587@lzapx.brq.redhat.com> Unit tests did not run for me, can you check? https://gist.github.com/3889206 LZ On Fri, Oct 12, 2012 at 01:57:53PM -0400, Adam Price wrote: > hello folks, > > I just submitted a pull-request [1] for fixes to the Custom Info code which include: > 1. enforcing unique keynames (makes things a lot easier/simpler) > 2. allowing null values > > and i finished up the default custom info keys for systems by orgs with the ability to: > 1. add custom keys to an org > 2. remove custom keys to an org > 3. apply keys to currently existing systems > 4. automatically add default custom keys to newly created systems > > > with tests for all. > > you'll need to run 'rake db:migrate'. > > Please review the pull-request and make some comments! Thanks. > > > [1] https://github.com/Katello/katello/pull/847 > > -- > Adam Price > adprice at redhat dot com > > _______________________________________________ > 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 Mon Oct 15 07:22:13 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 15 Oct 2012 09:22:13 +0200 Subject: [katello-devel] Updated Ruby style guide In-Reply-To: <536465031.11669283.1350065743464.JavaMail.root@redhat.com> References: <536465031.11669283.1350065743464.JavaMail.root@redhat.com> Message-ID: <20121015072213.GB10587@lzapx.brq.redhat.com> On Fri, Oct 12, 2012 at 02:15:43PM -0400, David Davis wrote: > I'm also thinking of reiterating the 80 characters or less per line rule in our style guide. It's currently in the Github guide and I think it's great rule given that it's in our Python guide as well and Github cuts off commits after about 80 characters (you have to scroll over). Why you think it's great? I think it's evil, because nobody no longer uses fixed eighty columns anymore and it's quite limiting. I mean, xterm opens up with 80, but everyone can resize it if needed. There are many theoretical reasons why to wrap at 80 (like if a line is that long you should consider refactoring it blah blah). Crap. Give me practical reasons. IMHO longer lines are sometimes better to read. And I personally very often need a line between 80 and let's say 100 which is very readable, but when wrapped it's awful. I vote for not giving explicit limit and let it be: use reasonable line lengths. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Mon Oct 15 07:30:20 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 15 Oct 2012 09:30:20 +0200 Subject: [katello-devel] Summary: Katello slow tests In-Reply-To: <818773905.11632919.1350060754970.JavaMail.root@redhat.com> References: <50783B19.3020708@redhat.com> <818773905.11632919.1350060754970.JavaMail.root@redhat.com> Message-ID: <20121015073020.GC10587@lzapx.brq.redhat.com> On Fri, Oct 12, 2012 at 12:52:34PM -0400, David Davis wrote: > Your other ideas sound good too. Let me know if you want to coordinate something as I could help modifying the existing tests to access the database less. From previous experience, IO operations during testing tend to be the bottleneck. Not much in our case unfortunately, if you configure pgsql to run more or less in memory, it does not give any boost: cat >> /usr/share/katello/install/puppet/modules/postgres/templates/postgresql.conf.erb < References: <50783B19.3020708@redhat.com> <50785075.6060701@redhat.com> Message-ID: <20121015073210.GD10587@lzapx.brq.redhat.com> On Fri, Oct 12, 2012 at 07:16:37PM +0200, Miroslav Suchy wrote: > On 12.10.2012 17:45, Dmitri Dolguikh wrote: > >In some test suites time spent on db operations amounts to high 40-ties > >of total test run time. Tests in spec/models have no clear separation > >between model and glue-layer tests, besides context changes. > > > > > >Some areas of improvement: > > * Add indexes to speed up slow queries. > Mirek, in our tests indexes would actually slower things down. We do have tens of records max in each test. Indexes does not help at all, in fact DB systems do not use them when there are less records than hundreds practically slowing down inserts... I totally agree we need to optimize indexes for production users. -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Mon Oct 15 07:36:25 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 15 Oct 2012 09:36:25 +0200 Subject: [katello-devel] Updated Ruby style guide In-Reply-To: <20121015072213.GB10587@lzapx.brq.redhat.com> References: <536465031.11669283.1350065743464.JavaMail.root@redhat.com> <20121015072213.GB10587@lzapx.brq.redhat.com> Message-ID: <507BBCF9.8020701@redhat.com> On 10/15/2012 09:22 AM, Lukas Zapletal wrote: > I vote for not giving explicit limit and let it be: use reasonable line > lengths. In Spacewalk we agreed on limit of 120 characters and I find it as very sane limit. -- Miroslav Suchy Red Hat Systems Management Engineering From lzap at redhat.com Mon Oct 15 07:49:35 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 15 Oct 2012 09:49:35 +0200 Subject: [katello-devel] Branching Katello 1.1 Message-ID: <20121015074935.GF10587@lzapx.brq.redhat.com> Guys, I am currently branching, building and stuff - please hold on your merging intentions until lunch or something. I will announce this very soon. Thanks LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Mon Oct 15 09:27:16 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 15 Oct 2012 10:27:16 +0100 Subject: [katello-devel] Summary: Katello slow tests In-Reply-To: <50785075.6060701@redhat.com> References: <50783B19.3020708@redhat.com> <50785075.6060701@redhat.com> Message-ID: <507BD6F4.8000509@redhat.com> On 12/10/12 06:16 PM, Miroslav Suchy wrote: > On 12.10.2012 17:45, Dmitri Dolguikh wrote: >> In some test suites time spent on db operations amounts to high 40-ties >> of total test run time. Tests in spec/models have no clear separation >> between model and glue-layer tests, besides context changes. >> >> >> Some areas of improvement: > > * Add indexes to speed up slow queries. > > Mirek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Queries need to be dealt with, there are no doubts about that. However, we don't know what queries are "slow" atm (we need to collect this statistic first), and there's a story in the backlog for that. The issue with access to the db in tests, is that we do it a *lot*. There's a test that creates a hundred object graphs, for example. -d From lzap at redhat.com Mon Oct 15 10:51:46 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 15 Oct 2012 12:51:46 +0200 Subject: [katello-devel] Katello master OPEN FOR BUSINESS again Message-ID: <20121015105146.GG10587@lzapx.brq.redhat.com> SSIA I will be releasing K 1.1 later today. Still signing packages. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From gkhachik at redhat.com Mon Oct 15 11:42:51 2012 From: gkhachik at redhat.com (Garik Khachikyan) Date: Mon, 15 Oct 2012 13:42:51 +0200 Subject: [katello-devel] Branching Katello 1.1 In-Reply-To: <20121015074935.GF10587@lzapx.brq.redhat.com> References: <20121015074935.GF10587@lzapx.brq.redhat.com> Message-ID: <507BF6BB.5080207@redhat.com> On 15/10/12 09:49, Lukas Zapletal wrote: > Guys, > > I am currently branching, building and stuff - please hold on your > merging intentions until lunch or something. I will announce this very > soon. > > Thanks > > LZ > Hey Lukas, Seems we do have an issue with `yum`-ing the stuff when the client is subscribed to Katello repo (I tried the custom repo case). My automation run shows: Error parsing config: Error parsing "proxy = ''": URL must be http, ftp or https not "" Right now there is still running the automation. I will try to reproduce the scenario manually - but for the first shot: it's not working for me! Garik. From jrist at redhat.com Mon Oct 15 12:08:09 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 15 Oct 2012 06:08:09 -0600 Subject: [katello-devel] Updated Ruby style guide In-Reply-To: <20121015072213.GB10587@lzapx.brq.redhat.com> References: <536465031.11669283.1350065743464.JavaMail.root@redhat.com> <20121015072213.GB10587@lzapx.brq.redhat.com> Message-ID: <507BFCA9.1010007@redhat.com> On 10/15/2012 01:22 AM, Lukas Zapletal wrote: > On Fri, Oct 12, 2012 at 02:15:43PM -0400, David Davis wrote: >> I'm also thinking of reiterating the 80 characters or less per line rule in our style guide. It's currently in the Github guide and I think it's great rule given that it's in our Python guide as well and Github cuts off commits after about 80 characters (you have to scroll over). > > Why you think it's great? I think it's evil, because nobody no longer > uses fixed eighty columns anymore and it's quite limiting. I mean, xterm > opens up with 80, but everyone can resize it if needed. > > There are many theoretical reasons why to wrap at 80 (like if a line is > that long you should consider refactoring it blah blah). Crap. Give me > practical reasons. > > IMHO longer lines are sometimes better to read. And I personally very > often need a line between 80 and let's say 100 which is very readable, > but when wrapped it's awful. > > I vote for not giving explicit limit and let it be: use reasonable line > lengths. > I personally like the no limits rule as well. I would rather be able to read the whole line than see it split with concatenation characters. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From daviddavis at redhat.com Mon Oct 15 12:09:36 2012 From: daviddavis at redhat.com (David Davis) Date: Mon, 15 Oct 2012 08:09:36 -0400 (EDT) Subject: [katello-devel] Updated Ruby style guide In-Reply-To: <20121015072213.GB10587@lzapx.brq.redhat.com> Message-ID: <2010340732.12281795.1350302976881.JavaMail.root@redhat.com> 80 characters is often the standard used on many projects and in many guides. For example, the Ruby guide we were linking to in our Ruby Conventions page said to limit lines to 80 characters [1] and even the Github style guide that we're linking to now says to use 80 characters. Moreover, 80 characters per line is recommended in our Python wiki pages by way of pep8 [2] and the 80 char limit warning. For me personally though, I often develop in vim or in the console where I have split windows open and can't view more than 80 or so characters. That said, there are definitely instances where you can't limit a line to any number of characters like when using regular expressions. 100 characters though still seems reasonable to me--it's more about the lines of 150+ characters we have in katello. Not even github by default shows 150 chars in commit diffs (you have to scroll over after about 120). [1] http://www.caliban.org/ruby/rubyguide.shtml#style [2] http://www.python.org/dev/peps/pep-0008/#maximum-line-length David ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Monday, October 15, 2012 3:22:13 AM > Subject: Re: [katello-devel] Updated Ruby style guide > > On Fri, Oct 12, 2012 at 02:15:43PM -0400, David Davis wrote: > > I'm also thinking of reiterating the 80 characters or less per line > > rule in our style guide. It's currently in the Github guide and I > > think it's great rule given that it's in our Python guide as well > > and Github cuts off commits after about 80 characters (you have to > > scroll over). > > Why you think it's great? I think it's evil, because nobody no longer > uses fixed eighty columns anymore and it's quite limiting. I mean, > xterm > opens up with 80, but everyone can resize it if needed. > > There are many theoretical reasons why to wrap at 80 (like if a line > is > that long you should consider refactoring it blah blah). Crap. Give > me > practical reasons. > > IMHO longer lines are sometimes better to read. And I personally very > often need a line between 80 and let's say 100 which is very > readable, > but when wrapped it's awful. > > I vote for not giving explicit limit and let it be: use reasonable > line > lengths. > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From daviddavis at redhat.com Mon Oct 15 12:14:41 2012 From: daviddavis at redhat.com (David Davis) Date: Mon, 15 Oct 2012 08:14:41 -0400 (EDT) Subject: [katello-devel] Updated Ruby style guide In-Reply-To: <507BFCA9.1010007@redhat.com> Message-ID: <982908727.12293283.1350303281150.JavaMail.root@redhat.com> I would tend to agree with you in this case. I'm more apt to accept a line with 100+ characters if splitting it would mean having to add concatenation. However, like this is a line from our project: before_filter :find_role, :except => [:index, :items, :new, :create, :verbs_and_scopes, :auto_complete_search, :create_ldap_group, :destroy_ldap_group] There's no reason why this line couldn't be: before_filter :find_role, :except => [:index, :items, :new, :create, :verbs_and_scopes, :auto_complete_search, :create_ldap_group, :destroy_ldap_group] David ----- Original Message ----- > From: "Jason Rist" > To: katello-devel at redhat.com > Sent: Monday, October 15, 2012 8:08:09 AM > Subject: Re: [katello-devel] Updated Ruby style guide > > On 10/15/2012 01:22 AM, Lukas Zapletal wrote: > > On Fri, Oct 12, 2012 at 02:15:43PM -0400, David Davis wrote: > >> I'm also thinking of reiterating the 80 characters or less per > >> line rule in our style guide. It's currently in the Github guide > >> and I think it's great rule given that it's in our Python guide > >> as well and Github cuts off commits after about 80 characters > >> (you have to scroll over). > > > > Why you think it's great? I think it's evil, because nobody no > > longer > > uses fixed eighty columns anymore and it's quite limiting. I mean, > > xterm > > opens up with 80, but everyone can resize it if needed. > > > > There are many theoretical reasons why to wrap at 80 (like if a > > line is > > that long you should consider refactoring it blah blah). Crap. Give > > me > > practical reasons. > > > > IMHO longer lines are sometimes better to read. And I personally > > very > > often need a line between 80 and let's say 100 which is very > > readable, > > but when wrapped it's awful. > > > > I vote for not giving explicit limit and let it be: use reasonable > > line > > lengths. > > > > > I personally like the no limits rule as well. I would rather be able > to > read the whole line than see it split with concatenation characters. > > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > github/identi.ca: knowncitizen > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From msuchy at redhat.com Mon Oct 15 13:08:33 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 15 Oct 2012 15:08:33 +0200 Subject: [katello-devel] Updated Ruby style guide In-Reply-To: <2010340732.12281795.1350302976881.JavaMail.root@redhat.com> References: <2010340732.12281795.1350302976881.JavaMail.root@redhat.com> Message-ID: <507C0AD1.8010900@redhat.com> On 10/15/2012 02:09 PM, David Davis wrote: > 80 characters is often the standard used on many projects and in many guides. It is repeated again again since very old ages: http://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_formats_and_character_codes -- Miroslav Suchy Red Hat Systems Management Engineering From gregswift at gmail.com Mon Oct 15 13:16:37 2012 From: gregswift at gmail.com (Greg Swift) Date: Mon, 15 Oct 2012 08:16:37 -0500 Subject: [katello-devel] Updated Ruby style guide In-Reply-To: <20121015072213.GB10587@lzapx.brq.redhat.com> References: <536465031.11669283.1350065743464.JavaMail.root@redhat.com> <20121015072213.GB10587@lzapx.brq.redhat.com> Message-ID: On Mon, Oct 15, 2012 at 2:22 AM, Lukas Zapletal wrote: > On Fri, Oct 12, 2012 at 02:15:43PM -0400, David Davis wrote: >> I'm also thinking of reiterating the 80 characters or less per line rule in our style guide. It's currently in the Github guide and I think it's great rule given that it's in our Python guide as well and Github cuts off commits after about 80 characters (you have to scroll over). > > Why you think it's great? I think it's evil, because nobody no longer > uses fixed eighty columns anymore and it's quite limiting. I mean, xterm > opens up with 80, but everyone can resize it if needed. > > There are many theoretical reasons why to wrap at 80 (like if a line is > that long you should consider refactoring it blah blah). Crap. Give me > practical reasons. practical reason: troubleshooting from a non-resizable console sucks with >80characters. that being said, I guess I'm not likely to be doing that with katello, but it makes a lot of sense in a lot of places for that reason. From lzap at redhat.com Mon Oct 15 14:08:51 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 15 Oct 2012 16:08:51 +0200 Subject: [katello-devel] Katello 1.1 released Message-ID: <20121015140851.GH10587@lzapx.brq.redhat.com> Everyone! We are happy to announce the release 1.1 of Katello, a systems management solution. https://fedorahosted.org/katello/wiki/ReleaseNotes11 The download locations are * http://fedorapeople.org/groups/katello/releases/yum/1.1/RHEL/$releasever/x86_64 * http://fedorapeople.org/groups/katello/releases/yum/1.1/Fedora/$releasever/x86_64 with client repositories under: * http://fedorapeople.org/groups/katello/releases/yum/1.1-client/RHEL/$releasever/x86_64 * http://fedorapeople.org/groups/katello/releases/yum/1.1-client/Fedora/$releasever/x86_64 For fresh installations, please use steps from * https://fedorahosted.org/katello/wiki/Install == Features & Enhancements in Katello 1.1 == * Initial Foreman packaging integration * Object labels and auto "labelization" * Added --default_locale to CLI for user creation * Added permissions for content delete * Adding a new changeset model for Content Deletion * Allow user to update his/her own localevia cli. * Available subscriptions on systems page now allow filtering * New documentation of API * Content deletion improvements * Systems custom info new feature * Fixed an issue when it was impossible to remove a repos without promoted content * No longer possible to delete a repository if it's been promoted * Make string more translator friendly * Prawn integration for PDF generation * Corrected i18n strings * Validation of locale during update handled by model Notable bug fixes: * 746765 - Systems can be referenced by UUID * 825858 - Implementing proxy permissions * 825858 - Use organizations.label instead of cp_key * 845995 - Add local and server side checks * 846321 - Support creating permissions for all tags from the API and the CLI * 853056 - Improve 404 generic error message * 857576 - Package filter name can be edited by CLI * 860421 - Not verifying ldap roles for auth-less API calls == Contributors == * Adam Price * Brad Buckingham * Bryan Kearney * David Davis * Dmitri Dolguikh * Eric D Helms * Eric Sammons * Ivan Necas * Jan Bla?ek * Jakub Hadvig * Jason E. Rist * Jordan OMara * Justin Sherrill * Lukas Zapletal * Martin Ba?ovsk? * Mike McCune * Miroslav Such? * Og B. Maciel * Partha Aji * Pavel Pokorny * Petr Chalupa * Tomas Strachota * Tom McKay Our thanks go to the community members who contributed to this release: * Gerhard Stoeckel * Chris Alfonso https://fedorahosted.org/katello/wiki/ContributorList == Some statistics == In Katello 1.1, we've seen * 141 bugs fixed * 1444 changesets committed * 1500 commits done == Known Issues == === No Fedora 17 build === We are currently working on Fedora 17 port (Ruby 1.9) and we have decided to release Katello 1.1 without support for Fedora 17. As Fedora 16 will be end of life soon, it is recommended to install Katello 1.1 on RHEL6. === Undefined method when adding product to activation key === {{{ activation_key update --add_subscription= ... undefined method `[]' for nil:NilClass }}} No resolution yet. == Reporting errors == To report issues with Katello, please use mailing list https://lists.fedorahosted.org/mailman/listinfo/katello to reach the user community. We might ask you to file bugzilla at https://bugzilla.redhat.com/enter_bug.cgi?product=Katello with more details or full logs. Thank you for using Katello. -- Later, Lukas "lzap" Zapletal #katello #systemengine From ifarkas at redhat.com Mon Oct 15 15:13:27 2012 From: ifarkas at redhat.com (Imre Farkas) Date: Mon, 15 Oct 2012 17:13:27 +0200 Subject: [katello-devel] New forms and integration with simple_form In-Reply-To: <449449727.232080.1350312690338.JavaMail.root@redhat.com> References: <449449727.232080.1350312690338.JavaMail.root@redhat.com> Message-ID: <507C2817.6080802@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 2495 bytes Desc: not available URL: From inecas at redhat.com Tue Oct 16 07:36:31 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 16 Oct 2012 09:36:31 +0200 Subject: [katello-devel] Branching Katello 1.1 In-Reply-To: <507BF6BB.5080207@redhat.com> References: <20121015074935.GF10587@lzapx.brq.redhat.com> <507BF6BB.5080207@redhat.com> Message-ID: <507D0E7F.2060508@redhat.com> On 10/15/2012 01:42 PM, Garik Khachikyan wrote: > On 15/10/12 09:49, Lukas Zapletal wrote: >> Guys, >> >> I am currently branching, building and stuff - please hold on your >> merging intentions until lunch or something. I will announce this very >> soon. >> >> Thanks >> >> LZ >> > Hey Lukas, > > Seems we do have an issue with `yum`-ing the stuff when the client is > subscribed to Katello repo (I tried the custom repo case). > > My automation run shows: > > Error parsing config: Error parsing "proxy = ''": URL must be http, > ftp or https not "" > > > Right now there is still running the automation. > > I will try to reproduce the scenario manually - but for the first > shot: it's not working for me! This seems like a bug on subscription-manager side. I've seen this as well. I will talk to rhsm guys. -- Ivan > > Garik. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From lzap at redhat.com Tue Oct 16 09:16:35 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 16 Oct 2012 11:16:35 +0200 Subject: [katello-devel] Updated Ruby style guide In-Reply-To: <982908727.12293283.1350303281150.JavaMail.root@redhat.com> References: <507BFCA9.1010007@redhat.com> <982908727.12293283.1350303281150.JavaMail.root@redhat.com> Message-ID: <20121016091634.GG8476@lzapx.brq.redhat.com> On Mon, Oct 15, 2012 at 08:14:41AM -0400, David Davis wrote: > There's no reason why this line couldn't be: > > before_filter :find_role, :except => [:index, :items, :new, :create, > :verbs_and_scopes, :auto_complete_search, :create_ldap_group, > :destroy_ldap_group] > TBH I'd go for: before_filter :find_role, :except => [ :index, :items, :new, ... Easier edits and still readable. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Tue Oct 16 12:08:03 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 16 Oct 2012 08:08:03 -0400 Subject: [katello-devel] Branching Katello 1.1 In-Reply-To: <507D0E7F.2060508@redhat.com> References: <20121015074935.GF10587@lzapx.brq.redhat.com> <507BF6BB.5080207@redhat.com> <507D0E7F.2060508@redhat.com> Message-ID: <507D4E23.1090503@redhat.com> On 10/16/2012 03:36 AM, Ivan Ne?as wrote: > On 10/15/2012 01:42 PM, Garik Khachikyan wrote: >> On 15/10/12 09:49, Lukas Zapletal wrote: >>> Guys, >>> >>> I am currently branching, building and stuff - please hold on your >>> merging intentions until lunch or something. I will announce this very >>> soon. >>> >>> Thanks >>> >>> LZ >>> >> Hey Lukas, >> >> Seems we do have an issue with `yum`-ing the stuff when the client is >> subscribed to Katello repo (I tried the custom repo case). >> >> My automation run shows: >> >> Error parsing config: Error parsing "proxy = ''": URL must be http, >> ftp or https not "" >> >> >> Right now there is still running the automation. >> >> I will try to reproduce the scenario manually - but for the first >> shot: it's not working for me! > This seems like a bug on subscription-manager side. I've seen this as > well. I will talk to rhsm guys. Yeah.. bug the chainsaw list. -- bk From lzap at redhat.com Tue Oct 16 13:20:48 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 16 Oct 2012 15:20:48 +0200 Subject: [katello-devel] Branching Katello 1.1 In-Reply-To: <507D4E23.1090503@redhat.com> References: <20121015074935.GF10587@lzapx.brq.redhat.com> <507BF6BB.5080207@redhat.com> <507D0E7F.2060508@redhat.com> <507D4E23.1090503@redhat.com> Message-ID: <20121016132048.GM8476@lzapx.brq.redhat.com> On Tue, Oct 16, 2012 at 08:08:03AM -0400, Bryan Kearney wrote: > On 10/16/2012 03:36 AM, Ivan Ne?as wrote: > >On 10/15/2012 01:42 PM, Garik Khachikyan wrote: > >>On 15/10/12 09:49, Lukas Zapletal wrote: > >>>Guys, > >>> > >>>I am currently branching, building and stuff - please hold on your > >>>merging intentions until lunch or something. I will announce this very > >>>soon. > >>> > >>>Thanks > >>> > >>>LZ > >>> > >>Hey Lukas, > >> > >>Seems we do have an issue with `yum`-ing the stuff when the client is > >>subscribed to Katello repo (I tried the custom repo case). > >> > >>My automation run shows: > >> > >>Error parsing config: Error parsing "proxy = ''": URL must be http, > >>ftp or https not "" > >> > >> > >>Right now there is still running the automation. > >> > >>I will try to reproduce the scenario manually - but for the first > >>shot: it's not working for me! > >This seems like a bug on subscription-manager side. I've seen this as > >well. I will talk to rhsm guys. > > Yeah.. bug the chainsaw list. Katello 1.1 is affected with this bug, this is blocker-like bug. Is there a BZ for that? I'd love to track this one. Thanks. -- Later, Lukas "lzap" Zapletal #katello #systemengine From jsherril at redhat.com Tue Oct 16 15:13:39 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 16 Oct 2012 11:13:39 -0400 Subject: [katello-devel] Custom callbacks for optional backend services Message-ID: <507D79A3.6070103@redhat.com> While we are working on the pulpv2 stuff, we are breaking apart our models a bit more and trying separate duties out more. As part of this we should expect models to be able to operate on their own when backend services are disabled (even if they dont' do a whole lot). One such example where this breaks is in Systems and System Groups: https://github.com/jlsherrill/katello/blob/pulpv2/src/app/models/system_group.rb#L24 You can see here that we've broken up System even more, splitting out the elastic search code and authorization (in addition to the glue modules). That specific line though will not function properly without Pulp and Elastic search being present. You will get an error trying to add a system to a system group because "add_pulp_consumer_group" will have not been defined. Since SAM is talking about adding system this will become more of a problem. An interesting solution would be to use custom callbacks: http://www.intridea.com/blog/2012/3/22/define-custom-callbacks-for-activerecord-and-more# So we could define our own events that get triggered (for example 'before_system_group_added') and pulp glue layer could simply define a trigger on that callback. In the SAM case that trigger'd method would never be defined, so it could go on its way happily. Thoughts? -Justin From mmccune at redhat.com Tue Oct 16 16:03:24 2012 From: mmccune at redhat.com (Mike McCune) Date: Tue, 16 Oct 2012 09:03:24 -0700 Subject: [katello-devel] parallel_tests pull request and howto Message-ID: <507D854C.5030605@redhat.com> I sent a PR yesterday to add parallel_tests to our setup. I found when running parallel_tests with our spec tests on my 4-core workstation my execution went from ~12 minutes down to around 4 minutes. The pull request is here: https://github.com/Katello/katello/pull/859 To setup your system to run parallel_tests[1] you can for now check out my pull request then do: $ bundle install $ rake parallel:create $ rake parallel:prepare then to run the tests: $ rake parallel:spec it automatically detects the number of cores you have and spins up a separate chunk of tests on each CPU. Mike [1] https://github.com/grosser/parallel_tests -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From lzap at redhat.com Tue Oct 16 16:09:03 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 16 Oct 2012 18:09:03 +0200 Subject: [katello-devel] Ozzak unit test runner Message-ID: <20121016160903.GD4869@lzapx.brq.redhat.com> Hey, you may already noticed for each git pull request new "member" of our family runs the test for us putting results in a gist. This is a small&dirty script I created in couple of hours this weekend, it runs on our "ozzak" server in Brno (search the internal list for the hostname), the VM is called utest and it's running under username utest from a crontab. I did not want to comment pulls using my account, because I want to be notified too. Basically what it does it every 10 minutes it checks all Katello pull requests and for each new one it executes the tests: - clean database - bundle install - migrate - unit tests - unmigrate If a pull request was already tested, it skips it. I'd like to add making RPM scratch builds in koji too, this is also easy. Once a pull request is tested, ozzak never tests again. What I can do is to trigger manually deleting a log directory. If there is demand, I can modify it to test every new commit. I know Eric is working on much more robust solution (Hudson instance on an OpenShift integrated with github.com more tightly), but until we get there and if you have no objections, I will keep it running. And yeah, those citations when test succeeds are fortune output. Take them as a reward when your patch is clean. :-) ps - if anything bad happens (like never ending flood, omg), ssh to ozzak and shut the instance down, then blame me (in this order :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Tue Oct 16 16:36:43 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 16 Oct 2012 12:36:43 -0400 Subject: [katello-devel] Custom callbacks for optional backend services In-Reply-To: <507D79A3.6070103@redhat.com> References: <507D79A3.6070103@redhat.com> Message-ID: <507D8D1B.6090703@redhat.com> On 10/16/2012 11:13 AM, Justin Sherrill wrote: > > > > While we are working on the pulpv2 stuff, we are breaking apart our > models a bit more and trying separate duties out more. As part of this > we should expect models to be able to operate on their own when backend > services are disabled (even if they dont' do a whole lot). What about items which only exist in the backend system? Repos is an example I think. > > One such example where this breaks is in Systems and System Groups: > > > https://github.com/jlsherrill/katello/blob/pulpv2/src/app/models/system_group.rb#L24 > > > You can see here that we've broken up System even more, splitting out > the elastic search code and authorization (in addition to the glue > modules). That specific line though will not function properly without > Pulp and Elastic search being present. You will get an error trying to > add a system to a system group because "add_pulp_consumer_group" will > have not been defined. Since SAM is talking about adding system this > will become more of a problem. > > An interesting solution would be to use custom callbacks: > > http://www.intridea.com/blog/2012/3/22/define-custom-callbacks-for-activerecord-and-more# > > > So we could define our own events that get triggered (for example > 'before_system_group_added') and pulp glue layer could simply define a > trigger on that callback. In the SAM case that trigger'd method would > never be defined, so it could go on its way happily. Isnt that what the glue code does today with before_save and before create? Are you just thinking of extending that? > > Thoughts? > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jsherril at redhat.com Tue Oct 16 16:44:40 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 16 Oct 2012 12:44:40 -0400 Subject: [katello-devel] Custom callbacks for optional backend services In-Reply-To: <507D8D1B.6090703@redhat.com> References: <507D79A3.6070103@redhat.com> <507D8D1B.6090703@redhat.com> Message-ID: <507D8EF8.4080706@redhat.com> On 10/16/2012 12:36 PM, Bryan Kearney wrote: > On 10/16/2012 11:13 AM, Justin Sherrill wrote: >> >> >> >> While we are working on the pulpv2 stuff, we are breaking apart our >> models a bit more and trying separate duties out more. As part of this >> we should expect models to be able to operate on their own when backend >> services are disabled (even if they dont' do a whole lot). > > What about items which only exist in the backend system? Repos is an > example I think. I don't think you would use it for things that only exist in backend systems. Repos actually exist in katello too, but content, packages, & errata are all examples. If something just exists in a single backend system it wouldn't be usefull. If it exists in more than one (or in katello itself) i think it might. > >> >> One such example where this breaks is in Systems and System Groups: >> >> >> https://github.com/jlsherrill/katello/blob/pulpv2/src/app/models/system_group.rb#L24 >> >> >> >> You can see here that we've broken up System even more, splitting out >> the elastic search code and authorization (in addition to the glue >> modules). That specific line though will not function properly without >> Pulp and Elastic search being present. You will get an error trying to >> add a system to a system group because "add_pulp_consumer_group" will >> have not been defined. Since SAM is talking about adding system this >> will become more of a problem. >> >> An interesting solution would be to use custom callbacks: >> >> http://www.intridea.com/blog/2012/3/22/define-custom-callbacks-for-activerecord-and-more# >> >> >> >> So we could define our own events that get triggered (for example >> 'before_system_group_added') and pulp glue layer could simply define a >> trigger on that callback. In the SAM case that trigger'd method would >> never be defined, so it could go on its way happily. > > > Isnt that what the glue code does today with before_save and before > create? Are you just thinking of extending that? It is, those are just callbacks defined by active record. We would be extending it for custom callbacks for other types of actions. -Justin > >> >> Thoughts? >> >> -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 mmccune at redhat.com Tue Oct 16 18:31:29 2012 From: mmccune at redhat.com (Mike McCune) Date: Tue, 16 Oct 2012 11:31:29 -0700 Subject: [katello-devel] Content view definition command In-Reply-To: <939335792.11361682.1350047625710.JavaMail.root@redhat.com> References: <939335792.11361682.1350047625710.JavaMail.root@redhat.com> Message-ID: <507DA801.1000901@redhat.com> how about a common use case of 1) create, 2) publish and 3) promote with the removal of a separate concept of 'definition vs view' to the end user which may just be too confusing. This is just an idea, it may be important to expose the separation to the end user. 1) create $ katello content_view create --name=MyView (creates a new CV in the Library that is now only view-able by my user since it is unpublished) 2) add stuff to the view $ katello content_view update --name=MyView --add_filter=stable $ katello content_view update --name=MyView --add_product=product1 $ katello content_view update --name=MyView --add_repo=repo1 (adds new things to the definition behind the scenes and always operating on the stuff in Library) 3) publish the view to the Library $ katello content_view publish --name=MyView (view is now available to everyone in the Library) $ katello changeset create --name=changeset-1 --environment=Dev $ katello changeset update --name=changeset-1 --environment=Dev --add_content_view=MyView $ katello changeset apply --name=changeset-1 --environment=Dev (view is now promoted into Dev) alternate shortcut to create a changeset and promote in 1 step: $ katello content_view promote --view=MyView --env=Dev (creates a machine-generated changeset and promotes the view and associated content) $ katello content_view list --env=Dev (see the content views in Dev) (shows "MyView" now in dev) $ katello content_view list --env=Library (shows all published views in the Library) Another usecase would be to combine 2 views: ** Create a new view $ katello content_view create --name=View2Sub $ katello content_view update --name=View2Sub --add_repo=repo3 $ katello content_view publish --name=View2Sub (now we have a new view avail) ** Update view from above to include the other view $ katello content_view update --name=MyView --include_view=View2Sub $ katello content_view publish --name=MyView (now MyView includes its own definitions as well as those from View2Sub) not sure if this is completely going against the design of CVs but I'm trying to think how to simplify it to the user so they don't have to worry so much about the 'views' vs the 'definitions' and just deal only with Content Views. Mike On 10/12/2012 06:13 AM, David Davis wrote: > I think you could access the two separately but they would all be under the content_view command. Just to throw out something to illustrate this point: > > katello content_view definitions (list all the content_view_definitions) > katello content_view publish --definition=Database (create a new content view from the content view defininition) > katello content_view define or katello content_view create_definition (create a new content view definition) > katello content_view update_definition --definition=Database --add_filter=stable (or something) > katello content_view promote --view=MongoDB --env=Dev (promote the content view to the Dev environment) > katello content_view list --env=Dev (see the content views in Dev) > > So you could access the definitions and views separately but you'd still call the same content_view command. > > David > > ----- Original Message ----- >> From: "Bryan Kearney" >> To: katello-devel at redhat.com >> Sent: Friday, October 12, 2012 8:15:43 AM >> Subject: Re: [katello-devel] Content view definition command >> >> On 10/11/2012 03:02 PM, Mike McCune wrote: >>> On 10/11/2012 11:45 AM, Eric Helms wrote: >>>> On 10/11/2012 02:42 PM, David Davis wrote: >>>>> I am working on content view definitions and having a >>>>> content_view_definition command is starting to cause problems due >>>>> to >>>>> its length: >>>>> >>>>> https://dl.dropbox.com/u/29929/Screenshot%20at%202012-10-11%2014%3A38%3A42.png >>>>> >>>>> >>>>> It would be nice to shorten it to make it easier to develop the >>>>> cli >>>>> command and for the end user to type. I was thinking of some >>>>> options: >>>>> >>>>> cv_definition >>>>> content_definition >>>>> view_definition >>>>> content_view_def >>>>> definition >>>>> >>>>> Anyone have a preference? >>>>> >>>>> David >>>>> >>>>> _______________________________________________ >>>>> katello-devel mailing list >>>>> katello-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> Is it possible to do subcommands so all definition related items >>>> lived >>>> under that? >>>> >>>> katello content_view definition >>>> >>> >>> the question too, do we want to really make users have to >>> understand and >>> act on 'content views' and 'content view definitions' as separate >>> objects? >>> >>> Why not just 'content views'? >> >> I think if if you set up rules, you will be able to splat out 2 >> different snapshots from that rules. So, we will need names for the >> splatter and the splatee. >> >> -- 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 -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From dgoodwin at rm-rf.ca Tue Oct 16 18:34:45 2012 From: dgoodwin at rm-rf.ca (Devan Goodwin) Date: Tue, 16 Oct 2012 15:34:45 -0300 Subject: [katello-devel] Manifest Conflicts And How To Override Them Message-ID: New code we demo'ed awhile back is completed and in candlepin since candlepin-0.7.14-1. When importing manifests, in a 409 conflict the translated displayMessage may now be newline separated (if multiple conflicts occurred), and will usually also include a list of keys you can programatically check and adjust behaviour accordingly. (assuming the conflict is one that can be overridden) You override by appending ?force=key1&force=key2 to the import URL, using the exact same keys given by the conflict exception. $ curl -k -u admin:admin -F upload=@/home/dgoodwin/src/candlepin/manifest1.zip "https://hostname:8443/candlepin/owners/testorg/imports?force=DISTRIBUTOR_CONFLICT" { "displayMessage" : "Import is older than existing data", "conflicts" : [ "MANIFEST_OLD" ] }% We now differentiate between an older manifest and the same manifest. (MANIFEST_OLD vs MANIFEST_SAME) Brad requested this so you could detect if a manifest was imported successfully in candlepin but then failed in pulp, and needs to be retried. If you see this manifest conflict, you can override it, but there's really no point, you can just proceed with the import in pulp. We added DISTRIBUTOR_CONFLICT at Tom's request, which will let you import a manifest from a new distributor. If that new distributor is in the same upstream org, and using roughly the same quantities from the exact same pools, forcing this manifest will not harm your existing entitlements. However if it's from another org, or using different pools, or using drastically less quantities, your systems may have their entitlements revoked. This is very much something the user will need to be warned about in Katello before overriding because it could wreak havoc. WARNING: make sure not to force these by default, a slip in which manifest is used could do serious damage to existing entitlements. SIGNATURE_CONFLICT is not yet enabled, I had a terrible time getting it to work at all regardless what upstream cert I setup, but it became clear Katello is not yet fetching or distributing the upstream cert in any fashion, so we're simply not ready to re-enable this yet. Let me know if you have questions. Cheers, Devan From thomasmckay at redhat.com Tue Oct 16 19:28:41 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 16 Oct 2012 15:28:41 -0400 (EDT) Subject: [katello-devel] Review of delete manifest (headpin mode) pull-request In-Reply-To: <1544894405.8931328.1350415516632.JavaMail.root@redhat.com> Message-ID: <1594725638.8943560.1350415721491.JavaMail.root@redhat.com> https://github.com/Katello/katello/pull/857 Any volunteers? From msuchy at redhat.com Wed Oct 17 07:06:51 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Wed, 17 Oct 2012 09:06:51 +0200 Subject: [katello-devel] Custom callbacks for optional backend services In-Reply-To: <507D79A3.6070103@redhat.com> References: <507D79A3.6070103@redhat.com> Message-ID: <507E590B.1030707@redhat.com> On 16.10.2012 17:13, Justin Sherrill wrote: > > > While we are working on the pulpv2 stuff, we are breaking apart our > models a bit more and trying separate duties out more. As part of this > we should expect models to be able to operate on their own when backend > services are disabled (even if they dont' do a whole lot). Generally +1 By disabled you mean temporary or in configuration? What if pulp is generally enabled, but it is just in some moment unreachable for whatever reason? Mirek From msuchy at redhat.com Wed Oct 17 07:15:32 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Wed, 17 Oct 2012 09:15:32 +0200 Subject: [katello-devel] Ozzak unit test runner In-Reply-To: <20121016160903.GD4869@lzapx.brq.redhat.com> References: <20121016160903.GD4869@lzapx.brq.redhat.com> Message-ID: <507E5B14.8070902@redhat.com> On 16.10.2012 18:09, Lukas Zapletal wrote: > but until we get > there and if you have no objections, I will keep it running. /me claps hands Thanks. Mirek P.S. Can you set avatar image for Ozzak, please? :) From lzap at redhat.com Wed Oct 17 09:26:35 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 17 Oct 2012 11:26:35 +0200 Subject: [katello-devel] Manifest Conflicts And How To Override Them In-Reply-To: References: Message-ID: <20121017092635.GB8532@lzapx.brq.redhat.com> Thanks Devan, team, is this linked with our sprint task or bz? LZ On Tue, Oct 16, 2012 at 03:34:45PM -0300, Devan Goodwin wrote: > New code we demo'ed awhile back is completed and in candlepin since > candlepin-0.7.14-1. > > When importing manifests, in a 409 conflict the translated > displayMessage may now be newline separated (if multiple conflicts > occurred), and will usually also include a list of keys you can > programatically check and adjust behaviour accordingly. (assuming the > conflict is one that can be overridden) > > You override by appending ?force=key1&force=key2 to the import URL, > using the exact same keys given by the conflict exception. > > $ curl -k -u admin:admin -F > upload=@/home/dgoodwin/src/candlepin/manifest1.zip > "https://hostname:8443/candlepin/owners/testorg/imports?force=DISTRIBUTOR_CONFLICT" > > { > "displayMessage" : "Import is older than existing data", > "conflicts" : [ "MANIFEST_OLD" ] > }% > > > We now differentiate between an older manifest and the same manifest. > (MANIFEST_OLD vs MANIFEST_SAME) Brad requested this so you could > detect if a manifest was imported successfully in candlepin but then > failed in pulp, and needs to be retried. If you see this manifest > conflict, you can override it, but there's really no point, you can > just proceed with the import in pulp. > > We added DISTRIBUTOR_CONFLICT at Tom's request, which will let you > import a manifest from a new distributor. If that new distributor is > in the same upstream org, and using roughly the same quantities from > the exact same pools, forcing this manifest will not harm your > existing entitlements. However if it's from another org, or using > different pools, or using drastically less quantities, your systems > may have their entitlements revoked. This is very much something the > user will need to be warned about in Katello before overriding because > it could wreak havoc. > > WARNING: make sure not to force these by default, a slip in which > manifest is used could do serious damage to existing entitlements. > > SIGNATURE_CONFLICT is not yet enabled, I had a terrible time getting > it to work at all regardless what upstream cert I setup, but it became > clear Katello is not yet fetching or distributing the upstream cert in > any fashion, so we're simply not ready to re-enable this yet. > > Let me know if you have questions. > > Cheers, > > Devan > > _______________________________________________ > 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 Wed Oct 17 12:24:07 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 17 Oct 2012 08:24:07 -0400 (EDT) Subject: [katello-devel] Manifest Conflicts And How To Override Them In-Reply-To: <20121017092635.GB8532@lzapx.brq.redhat.com> Message-ID: <1977371492.9271203.1350476647773.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, October 17, 2012 5:26:35 AM > Subject: Re: [katello-devel] Manifest Conflicts And How To Override Them > > Thanks Devan, > > team, is this linked with our sprint task or bz? Stories related to this are in Team Headpin bucket. > > LZ > > On Tue, Oct 16, 2012 at 03:34:45PM -0300, Devan Goodwin wrote: > > New code we demo'ed awhile back is completed and in candlepin since > > candlepin-0.7.14-1. > > > > When importing manifests, in a 409 conflict the translated > > displayMessage may now be newline separated (if multiple conflicts > > occurred), and will usually also include a list of keys you can > > programatically check and adjust behaviour accordingly. (assuming > > the > > conflict is one that can be overridden) > > > > You override by appending ?force=key1&force=key2 to the import URL, > > using the exact same keys given by the conflict exception. > > > > $ curl -k -u admin:admin -F > > upload=@/home/dgoodwin/src/candlepin/manifest1.zip > > "https://hostname:8443/candlepin/owners/testorg/imports?force=DISTRIBUTOR_CONFLICT" > > > > { > > "displayMessage" : "Import is older than existing data", > > "conflicts" : [ "MANIFEST_OLD" ] > > }% > > > > > > We now differentiate between an older manifest and the same > > manifest. > > (MANIFEST_OLD vs MANIFEST_SAME) Brad requested this so you could > > detect if a manifest was imported successfully in candlepin but > > then > > failed in pulp, and needs to be retried. If you see this manifest > > conflict, you can override it, but there's really no point, you can > > just proceed with the import in pulp. > > > > We added DISTRIBUTOR_CONFLICT at Tom's request, which will let you > > import a manifest from a new distributor. If that new distributor > > is > > in the same upstream org, and using roughly the same quantities > > from > > the exact same pools, forcing this manifest will not harm your > > existing entitlements. However if it's from another org, or using > > different pools, or using drastically less quantities, your systems > > may have their entitlements revoked. This is very much something > > the > > user will need to be warned about in Katello before overriding > > because > > it could wreak havoc. > > > > WARNING: make sure not to force these by default, a slip in which > > manifest is used could do serious damage to existing entitlements. > > > > SIGNATURE_CONFLICT is not yet enabled, I had a terrible time > > getting > > it to work at all regardless what upstream cert I setup, but it > > became > > clear Katello is not yet fetching or distributing the upstream cert > > in > > any fashion, so we're simply not ready to re-enable this yet. > > > > Let me know if you have questions. > > > > Cheers, > > > > Devan > > > > _______________________________________________ > > 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 lzap at redhat.com Wed Oct 17 13:50:10 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 17 Oct 2012 15:50:10 +0200 Subject: [katello-devel] Ozzak unit test runner In-Reply-To: <507E5B14.8070902@redhat.com> References: <20121016160903.GD4869@lzapx.brq.redhat.com> <507E5B14.8070902@redhat.com> Message-ID: <20121017135009.GD8532@lzapx.brq.redhat.com> On Wed, Oct 17, 2012 at 09:15:32AM +0200, Miroslav Suchy wrote: > P.S. Can you set avatar image for Ozzak, please? :) Ah I gave him my e-mail so its using my Avatar. Not going to play with this anymore. ps - ozzak is a name of a guy from one of weird Czech series, he drinks beer and have fat quotes... -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Wed Oct 17 15:37:22 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 17 Oct 2012 16:37:22 +0100 Subject: [katello-devel] moving to ruby 1.9.3 Message-ID: <507ED0B2.2020503@redhat.com> As part of port to Ruby 1.9.3, I'd suggest moving away from custom ruby repository for bundler-based installs, and switch to rubygems.org repository instead. Folks still would rather use Fedora-provided gems can do so, since Fedora 17 versions of 'bundler' and 'gem' are yum-aware. This would simplify dependency management during development. As the next step I'd like to propose to switch to rails 3.2 (the version of Rails that's going to be shipped with f18) in master (which is what Aeolus folks did). -d From mmccune at redhat.com Wed Oct 17 15:46:27 2012 From: mmccune at redhat.com (Mike McCune) Date: Wed, 17 Oct 2012 08:46:27 -0700 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507ED0B2.2020503@redhat.com> References: <507ED0B2.2020503@redhat.com> Message-ID: <507ED2D3.7080800@redhat.com> On 10/17/2012 08:37 AM, Dmitri Dolguikh wrote: > As part of port to Ruby 1.9.3, I'd suggest moving away from custom ruby > repository for bundler-based installs, and switch to rubygems.org > repository instead. Folks still would rather use Fedora-provided gems > can do so, since Fedora 17 versions of 'bundler' and 'gem' are > yum-aware. This would simplify dependency management during development. this sounds appealing, what is the best way to 'try it out' from a fresh install perspective? > > As the next step I'd like to propose to switch to rails 3.2 (the version > of Rails that's going to be shipped with f18) in master (which is what > Aeolus folks did). > +1 Mike From ehelms at redhat.com Wed Oct 17 15:52:52 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 17 Oct 2012 11:52:52 -0400 (EDT) Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507ED0B2.2020503@redhat.com> Message-ID: <379262041.9357607.1350489172226.JavaMail.root@redhat.com> I recently migrated a Rails 3.0 application to Rails 3.2 and the only thing I really had to change was with regards to the asset pipeline and for Katello I imagine this will be a significant chunk as well. If and when we decide to go the Rails 3.2 route I'd like to help out with that side of the conversion. -Eric ----- Original Message ----- From: "Dmitri Dolguikh" To: "katello-devel" Sent: Wednesday, October 17, 2012 11:37:22 AM Subject: [katello-devel] moving to ruby 1.9.3 As part of port to Ruby 1.9.3, I'd suggest moving away from custom ruby repository for bundler-based installs, and switch to rubygems.org repository instead. Folks still would rather use Fedora-provided gems can do so, since Fedora 17 versions of 'bundler' and 'gem' are yum-aware. This would simplify dependency management during development. As the next step I'd like to propose to switch to rails 3.2 (the version of Rails that's going to be shipped with f18) in master (which is what Aeolus folks did). -d _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From jrist at redhat.com Wed Oct 17 16:04:56 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 17 Oct 2012 10:04:56 -0600 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507ED0B2.2020503@redhat.com> References: <507ED0B2.2020503@redhat.com> Message-ID: <507ED728.90505@redhat.com> On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: > As part of port to Ruby 1.9.3, I'd suggest moving away from custom ruby > repository for bundler-based installs, and switch to rubygems.org > repository instead. Folks still would rather use Fedora-provided gems > can do so, since Fedora 17 versions of 'bundler' and 'gem' are > yum-aware. This would simplify dependency management during development. > > > As the next step I'd like to propose to switch to rails 3.2 (the version > of Rails that's going to be shipped with f18) in master (which is what > Aeolus folks did). > > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I think this is what we should have been doing. Can we not develop upstream in a more normal rails fashion and then deal with packaging and the like downstream? Or is that too much work? -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From dmitri at redhat.com Wed Oct 17 16:19:09 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 17 Oct 2012 17:19:09 +0100 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507ED728.90505@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> Message-ID: <507EDA7D.6090308@redhat.com> On 17/10/12 05:04 PM, Jason Rist wrote: > On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: >> As part of port to Ruby 1.9.3, I'd suggest moving away from custom ruby >> repository for bundler-based installs, and switch to rubygems.org >> repository instead. Folks still would rather use Fedora-provided gems >> can do so, since Fedora 17 versions of 'bundler' and 'gem' are >> yum-aware. This would simplify dependency management during development. >> >> >> As the next step I'd like to propose to switch to rails 3.2 (the version >> of Rails that's going to be shipped with f18) in master (which is what >> Aeolus folks did). >> >> >> -d >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > I think this is what we should have been doing. Can we not develop > upstream in a more normal rails fashion and then deal with packaging and > the like downstream? Or is that too much work? > I'm not sure why we aren't doing this atm. Considering that we have a suite of integration tests that is being run *after* katello has been packaged, it's safe to split development and packaging - we are able to catch the issues. -d From hbrock at redhat.com Wed Oct 17 17:18:35 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 17 Oct 2012 13:18:35 -0400 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507EDA7D.6090308@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> Message-ID: <20121017171834.GS12308@redhat.com> On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote: > On 17/10/12 05:04 PM, Jason Rist wrote: > >On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: > >>As part of port to Ruby 1.9.3, I'd suggest moving away from custom ruby > >>repository for bundler-based installs, and switch to rubygems.org > >>repository instead. Folks still would rather use Fedora-provided gems > >>can do so, since Fedora 17 versions of 'bundler' and 'gem' are > >>yum-aware. This would simplify dependency management during development. > >> > >> > >>As the next step I'd like to propose to switch to rails 3.2 (the version > >>of Rails that's going to be shipped with f18) in master (which is what > >>Aeolus folks did). > >> > >> > >>-d > >> > >>_______________________________________________ > >>katello-devel mailing list > >>katello-devel at redhat.com > >>https://www.redhat.com/mailman/listinfo/katello-devel > > > >I think this is what we should have been doing. Can we not develop > >upstream in a more normal rails fashion and then deal with packaging and > >the like downstream? Or is that too much work? > > > > I'm not sure why we aren't doing this atm. Considering that we have > a suite of integration tests that is being run *after* katello has > been packaged, it's safe to split development and packaging - we are > able to catch the issues. > > -d Yes, Aeolus is already doing this and IMO it is the only sane way to develop upstream. There is a natural split between upstream gem-only and distro-specific product packaging, let's let it happen. This means that some unlucky set of souls from each team is going to have to deal with the packaging each release, but that's the price we're going to pay regardless. We'll just rotate the personnel and let everyone feel the pain equally (this will also help keep a lid on the inclination to add things to Gemfile willy-nilly). --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 thomasmckay at redhat.com Wed Oct 17 18:58:44 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 17 Oct 2012 14:58:44 -0400 (EDT) Subject: [katello-devel] Retrieving "listing" files from pulp In-Reply-To: <961474112.9409707.1350499251311.JavaMail.root@redhat.com> Message-ID: <841981768.9415878.1350500324650.JavaMail.root@redhat.com> Working on a BZ [1] where the available releases are not being displayed in subscription-manager. These are fetched from the CDN, which in the case of katello is pulp, via the /listing files /content/dist/rhel/server/6/listing 6.1 6.2 6.3 6Server This is what sub-mgr is effectively doing: % curl --stderr /dev/null --insecure --tlsv1 --cert /etc/pki/entitlement/1203469290095408448.pem --key /etc/pki/entitlement/1203469290095408448-key.pem https://se-rhelbox.usersys.redhat.com/pulp/repos/Test_Org_1349760599/Dev//content/dist/rhel/server/5/listing But this results in a 403. A second issue is that there are no listing files at all in the pulp repos. ie. server/5/listing does not exist compared to what's in production and stage cdn. Help? [1] https://bugzilla.redhat.com/show_bug.cgi?id=832118 From tkolhar at redhat.com Thu Oct 18 05:53:44 2012 From: tkolhar at redhat.com (Tazim Kolhar) Date: Thu, 18 Oct 2012 01:53:44 -0400 (EDT) Subject: [katello-devel] Facing issues in headpin installation issue In-Reply-To: <1012024510.6613956.1350539099787.JavaMail.root@redhat.com> Message-ID: <1152848948.6615909.1350539624166.JavaMail.root@redhat.com> Hi, I have been using the below steps (manual setup for headpin) for headpin installation : 1. The repo contents : # cat /etc/yum.repos.d/headpin.repo [headpin] name=headpin baseurl=http://fedorapeople.org/groups/katello/releases/yum/nightly/RHEL/6Server/x86_64/ enabled=1 gpgcheck=0 skip_if_unavailable=1 # cat /etc/yum.repos.d/candlepin.repo [candlepin] name=candlepin baseurl=http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/RHEL/6Server/x86_64/ enabled=1 gpgcheck=0 skip_if_unavailable=1 2. Registering the system to RHN : # subscription-manager register --username qa at redhat.com --password 'X)U at 1K2o?9rsDUL' --autosubscribe --force 3. The installation : # yum install -y katello-headpin-all 4. But with the new repos I am getting the below errors although I have been following the same procedure for installation: --> Finished Dependency Resolution Error: Package: rubygem-mail-2.3.0-2.el6.noarch (headpin) Requires: rubygem(mime-types) < 2 Error: Package: rubygem-prawn-1.0.0-3.rc1.el6.noarch (headpin) Requires: rubygem(ttfunk) < 1.1 Error: Package: rubygem-prawn-1.0.0-3.rc1.el6.noarch (headpin) Requires: rubygem(pdf-reader) >= 0.9.0 Error: Package: rubygem-erubis-2.6.6-2.el6.noarch (headpin) Requires: rubygem(abstract) >= 1.0.0 Error: Package: rubygem-mail-2.3.0-2.el6.noarch (headpin) Requires: rubygem(treetop) >= 1.4.8 Error: Package: rubygem-mail-2.3.0-2.el6.noarch (headpin) Requires: rubygem(mime-types) >= 1.16 Error: Package: katello-common-1.2.1-1.git.0.8da47e6.el6.noarch (headpin) Requires: rubygem(uuidtools) Error: Package: rubygem-pdf-writer-1.1.8-6.el6.noarch (headpin) Requires: rubygem(transaction-simple) >= 1.3 Error: Package: katello-common-1.2.1-1.git.0.8da47e6.el6.noarch (headpin) Requires: rubygem(json) Error: Package: rubygem-rest-client-1.6.1-2.el6.noarch (headpin) Requires: rubygem(mime-types) >= 1.16 Error: Package: rubygem-prawn-1.0.0-3.rc1.el6.noarch (headpin) Requires: rubygem(ttfunk) >= 1.0.2 Error: Package: katello-common-1.2.1-1.git.0.8da47e6.el6.noarch (headpin) Requires: rubygem(thin) Error: Package: rubygem-tire-0.3.13-5.el6.noarch (headpin) Requires: rubygem(hashr) >= 0.0.16 Error: Package: candlepin-0.7.15-1.el6.noarch (candlepin) Requires: liquibase >= 2.0.3 Error: Package: katello-common-1.2.1-1.git.0.8da47e6.el6.noarch (headpin) Requires: rubygem(pg) Error: Package: katello-configure-1.2.0-1.git.27.840ee56.el6.noarch (headpin) Requires: puppet >= 2.6.6 Error: Package: rubygem-mail-2.3.0-2.el6.noarch (headpin) Requires: rubygem(treetop) < 1.5 Error: Package: rubygem-ruport-1.7.0-1.el6.noarch (headpin) Requires: rubygem(fastercsv) >= 0 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Please, go through this once and let me know is there are any steps missing . Thanks & Regards, Tazim. From inecas at redhat.com Thu Oct 18 08:20:11 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 18 Oct 2012 10:20:11 +0200 Subject: [katello-devel] Retrieving "listing" files from pulp In-Reply-To: <841981768.9415878.1350500324650.JavaMail.root@redhat.com> References: <841981768.9415878.1350500324650.JavaMail.root@redhat.com> Message-ID: <507FBBBB.6030206@redhat.com> On 10/17/2012 08:58 PM, Tom McKay wrote: > Working on a BZ [1] where the available releases are not being displayed in subscription-manager. These are fetched from the CDN, which in the case of katello is pulp, via the /listing files > > /content/dist/rhel/server/6/listing > 6.1 > 6.2 > 6.3 > 6Server > > This is what sub-mgr is effectively doing: > > % curl --stderr /dev/null --insecure --tlsv1 --cert /etc/pki/entitlement/1203469290095408448.pem --key /etc/pki/entitlement/1203469290095408448-key.pem https://se-rhelbox.usersys.redhat.com/pulp/repos/Test_Org_1349760599/Dev//content/dist/rhel/server/5/listing > > But this results in a 403. > > A second issue is that there are no listing files at all in the pulp repos. ie. server/5/listing does not exist compared to what's in production and stage cdn. That's the issue. Pulp doesn't support listing files. However, Katello provides the api returning the available releases. [1] [1] - http://www.katello.org/apidoc/environments/releases.html -- Ivan > > Help? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=832118 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From inecas at redhat.com Thu Oct 18 08:22:24 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 18 Oct 2012 10:22:24 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121017171834.GS12308@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> Message-ID: <507FBC40.9060509@redhat.com> On 10/17/2012 07:18 PM, Hugh Brock wrote: > On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote: >> On 17/10/12 05:04 PM, Jason Rist wrote: >>> On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: >>>> As part of port to Ruby 1.9.3, I'd suggest moving away from custom ruby >>>> repository for bundler-based installs, and switch to rubygems.org >>>> repository instead. Folks still would rather use Fedora-provided gems >>>> can do so, since Fedora 17 versions of 'bundler' and 'gem' are >>>> yum-aware. This would simplify dependency management during development. >>>> >>>> >>>> As the next step I'd like to propose to switch to rails 3.2 (the version >>>> of Rails that's going to be shipped with f18) in master (which is what >>>> Aeolus folks did). Let's call it Fedora 18 support :) >>>> >>>> >>>> -d >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> I think this is what we should have been doing. Can we not develop >>> upstream in a more normal rails fashion and then deal with packaging and >>> the like downstream? Or is that too much work? >>> >> I'm not sure why we aren't doing this atm. Considering that we have >> a suite of integration tests that is being run *after* katello has >> been packaged, it's safe to split development and packaging - we are >> able to catch the issues. Here are some reasons why we care about RPM packages from the beginning: 1. Katello as a working thing by far isn't just a Rails app and outside of the Ruby word gems mean nothing. 2. The installation process is part of the whole project. Using the installation process that will be used in production from start means catching the issues sooner than just before release 3. Creating an RPM forces you to thing about the license soon. It's not pleasant to find out that your code is not shipable because of the licensing issues 4. The code has to work on the target platform (which is Fedora an RHEL for us), and (as Metallica sings) nothing else matters 5. Things like selinux need to be solved as well. 6. This approach is Continuous Delivery compliant: and now we are having 2-months CR release cycle You can do whatever you want on the development machine. And I have nothing against improvements that will make development on non-Fedora based systems easier. But when you want to merge into the master, you have to count on the fact that somebody will want to install it on test or production machine. Unlike Aeolus, we don't try to get Katello into Fedora official repos yet (though our client packages are already there). And getting the packages to Fedora it the thing that makes the packaging harder and slows down the process: waiting for 2 weeks till the library can be used is just too much. Therefore we have our own Koji instance, where the deps go in the first place, and then we can work on getting them to Fedora later while development goes on. So what I'm saying is: it would be great if someone clones our repo, runs bundle install and the server runs on every platform (though I don't thing forcing the developer to run all the deps (like Pulp, Candlepin, Katello-Cli) from source would make the Rails developer happy. But giving up our nightly builds and all the good things that go with it just for this reason is really huge step backward. And I don't see a reason that this two things couldn't co-exist together. -- Ivan >> >> -d > Yes, Aeolus is already doing this and IMO it is the only sane way to > develop upstream. There is a natural split between upstream gem-only and > distro-specific product packaging, let's let it happen. > > This means that some unlucky set of souls from each team is going to > have to deal with the packaging each release, but that's the price we're > going to pay regardless. We'll just rotate the personnel and let > everyone feel the pain equally (this will also help keep a lid on the > inclination to add things to Gemfile willy-nilly). > > --Hugh > -- Ivan From tkolhar at redhat.com Thu Oct 18 09:10:27 2012 From: tkolhar at redhat.com (Tazim Kolhar) Date: Thu, 18 Oct 2012 05:10:27 -0400 (EDT) Subject: [katello-devel] [tkolhar@redhat.com: Request to change the password for RHN accounts:] In-Reply-To: <742467699.6647430.1350551225025.JavaMail.root@redhat.com> Message-ID: <802952976.6648174.1350551427794.JavaMail.root@redhat.com> Hi, Sorry, actually I just came to know, there are lot of machines using that account that will stop working if the password is changed. Please, DO NOT change the account passwords to avoid any further issues. Please, ignore the request to change passwords. Thanks & Regards, Tazim. > Please don't change the password, there are hundreds of machines using that account that will stop working if the password is changed. >-Jeff ----- Original Message ----- From: "Ladislav Jozsa" To: infosec at redhat.com Cc: tkolhar at redhat.com Sent: Thursday, October 18, 2012 2:20:03 PM Subject: [tkolhar at redhat.com: Request to change the password for RHN accounts:] Hi, could you please arrange password change for RHN QA due to its compromise in Bugzilla? Many thanks, Ladislav ----- Forwarded message from Tazim Kolhar ----- Date: Thu, 18 Oct 2012 04:12:13 -0400 (EDT) From: Tazim Kolhar To: Ladislav Jozsa Cc: Tazim Kolhar Subject: Request to change the password for RHN accounts: Hi, I have been using the below doc to register my system to rhn : https://docspace.corp.redhat.com/docs/DOC-64963 While, discussing a Bug with the team I somehow made the password 'public' by mistake. Requesting, you to please change the password for the above accounts in order to avoid free subscriptions. Also, please modify the doc accordingly. Thanks & Regards, Tazim. ----- End forwarded message ----- -- Ladislav Jozsa Release Test Team Quality Assurance Engineer Red Hat, Inc., Brno Office +420 608 73 7620 From dmitri at redhat.com Thu Oct 18 09:34:41 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 18 Oct 2012 10:34:41 +0100 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507FBC40.9060509@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> Message-ID: <507FCD31.4070700@redhat.com> On 18/10/12 09:22 AM, Ivan Ne?as wrote: > On 10/17/2012 07:18 PM, Hugh Brock wrote: >> On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote: >>> On 17/10/12 05:04 PM, Jason Rist wrote: >>>> On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: >>>>> As part of port to Ruby 1.9.3, I'd suggest moving away from custom >>>>> ruby >>>>> repository for bundler-based installs, and switch to rubygems.org >>>>> repository instead. Folks still would rather use Fedora-provided gems >>>>> can do so, since Fedora 17 versions of 'bundler' and 'gem' are >>>>> yum-aware. This would simplify dependency management during >>>>> development. >>>>> >>>>> >>>>> As the next step I'd like to propose to switch to rails 3.2 (the >>>>> version >>>>> of Rails that's going to be shipped with f18) in master (which is >>>>> what >>>>> Aeolus folks did). > Let's call it Fedora 18 support :) >>>>> >>>>> >>>>> -d >>>>> >>>>> _______________________________________________ >>>>> katello-devel mailing list >>>>> katello-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> I think this is what we should have been doing. Can we not develop >>>> upstream in a more normal rails fashion and then deal with >>>> packaging and >>>> the like downstream? Or is that too much work? >>>> >>> I'm not sure why we aren't doing this atm. Considering that we have >>> a suite of integration tests that is being run *after* katello has >>> been packaged, it's safe to split development and packaging - we are >>> able to catch the issues. > Here are some reasons why we care about RPM packages from the beginning: > > 1. Katello as a working thing by far isn't just a Rails app and > outside of the Ruby word gems mean nothing. > 2. The installation process is part of the whole project. Using the > installation process that will be used in production from start means > catching the issues sooner than just before release > 3. Creating an RPM forces you to thing about the license soon. It's > not pleasant to find out that your code is not shipable because of the > licensing issues > 4. The code has to work on the target platform (which is Fedora an > RHEL for us), and (as Metallica sings) nothing else matters > 5. Things like selinux need to be solved as well. > 6. This approach is Continuous Delivery compliant: and now we are > having 2-months CR release cycle > > You can do whatever you want on the development machine. And I have > nothing against improvements that will make development on non-Fedora > based systems easier. But when you want to merge into the master, you > have to count on the fact that somebody will want to install it on > test or production machine. > > Unlike Aeolus, we don't try to get Katello into Fedora official repos > yet (though our client packages are already there). And getting the > packages to Fedora it the thing that makes the packaging harder and > slows down the process: waiting for 2 weeks till the library can be > used is just too much. Therefore we have our own Koji instance, where > the deps go in the first place, and then we can work on getting them > to Fedora later while development goes on. > > So what I'm saying is: it would be great if someone clones our repo, > runs bundle install and the server runs on every platform (though I > don't thing forcing the developer to run all the deps (like Pulp, > Candlepin, Katello-Cli) from source would make the Rails developer > happy. But giving up our nightly builds and all the good things that > go with it just for this reason is really huge step backward. And I > don't see a reason that this two things couldn't co-exist together. > > -- Ivan I think we need to standardize on whether replies go above or below the original comment :) I don't think anybody participating in this thread suggests that packaging is not important. Nor is anyone talking about about abandoning nightly builds, etc. I'm suggesting that we remove development process dependency on build artifacts. Let's use rubygems.org in development (I know of several people who are doing this already; it's *very* useful to be able to add new dependencies in development quickly). Let's use system-provided gems in packaged Katello. -d >>> >>> -d >> Yes, Aeolus is already doing this and IMO it is the only sane way to >> develop upstream. There is a natural split between upstream gem-only and >> distro-specific product packaging, let's let it happen. >> >> This means that some unlucky set of souls from each team is going to >> have to deal with the packaging each release, but that's the price we're >> going to pay regardless. We'll just rotate the personnel and let >> everyone feel the pain equally (this will also help keep a lid on the >> inclination to add things to Gemfile willy-nilly). >> >> --Hugh >> > > From thomasmckay at redhat.com Thu Oct 18 11:47:36 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 18 Oct 2012 07:47:36 -0400 (EDT) Subject: [katello-devel] Retrieving "listing" files from pulp In-Reply-To: <507FBBBB.6030206@redhat.com> Message-ID: <1663385178.9647761.1350560856570.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ivan Ne?as" > To: katello-devel at redhat.com > Sent: Thursday, October 18, 2012 4:20:11 AM > Subject: Re: [katello-devel] Retrieving "listing" files from pulp > > On 10/17/2012 08:58 PM, Tom McKay wrote: > > Working on a BZ [1] where the available releases are not being > > displayed in subscription-manager. These are fetched from the CDN, > > which in the case of katello is pulp, via the /listing files > > > > /content/dist/rhel/server/6/listing > > 6.1 > > 6.2 > > 6.3 > > 6Server > > > > This is what sub-mgr is effectively doing: > > > > % curl --stderr /dev/null --insecure --tlsv1 --cert > > /etc/pki/entitlement/1203469290095408448.pem --key > > /etc/pki/entitlement/1203469290095408448-key.pem > > https://se-rhelbox.usersys.redhat.com/pulp/repos/Test_Org_1349760599/Dev//content/dist/rhel/server/5/listing > > > > But this results in a 403. > > > > A second issue is that there are no listing files at all in the > > pulp repos. ie. server/5/listing does not exist compared to what's > > in production and stage cdn. > That's the issue. Pulp doesn't support listing files. However, > Katello > provides the api returning the available releases. [1] > > [1] - http://www.katello.org/apidoc/environments/releases.html This will not work. subscription-manager does not call through katello to get the available releases, but instead hits the CDN directly. So, unless it's possible to catch the calls to /pulp/repos and pass it to katello, there is no work-around for this. Yes, there is a disconnect between what the user will see through subscription-manager and what katello offers up as available releases through its UI/CLI. Katello only shows the releases that have been promoted to the environment the system is registered to. Subscription-manager shows the releases that match the systems installed products. > > -- Ivan > > > > Help? > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=832118 > > > > _______________________________________________ > > 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 thomasmckay at redhat.com Thu Oct 18 11:53:57 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 18 Oct 2012 07:53:57 -0400 (EDT) Subject: [katello-devel] [tkolhar@redhat.com: Request to change the password for RHN accounts:] In-Reply-To: <802952976.6648174.1350551427794.JavaMail.root@redhat.com> Message-ID: <1013018230.9648665.1350561237568.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tazim Kolhar" > To: "Ladislav Jozsa" > Cc: katello-devel at redhat.com, infosec at redhat.com > Sent: Thursday, October 18, 2012 5:10:27 AM > Subject: Re: [katello-devel] [tkolhar at redhat.com: Request to change the password for RHN accounts:] > > Hi, > > Sorry, actually I just came to know, there are lot of machines > using that account that will stop working if the password is > changed. > Please, DO NOT change the account passwords to avoid any further > issues. > Please, ignore the request to change passwords. > > > Thanks & Regards, > Tazim. > > > > Please don't change the password, there are hundreds of machines > > using that account that will stop working if the password is > > changed. > > >-Jeff I would bump this a bit higher up the chain. The password went out to a publicly archived email list. You can choose to live with that hole with the potential of anyone registering and subscribing to real Red Hat content, or you can close it. > > ----- Original Message ----- > From: "Ladislav Jozsa" > To: infosec at redhat.com > Cc: tkolhar at redhat.com > Sent: Thursday, October 18, 2012 2:20:03 PM > Subject: [tkolhar at redhat.com: Request to change the password for RHN > accounts:] > > Hi, > > could you please arrange password change for RHN QA due to its > compromise in Bugzilla? > > Many thanks, > Ladislav > > ----- Forwarded message from Tazim Kolhar ----- > > Date: Thu, 18 Oct 2012 04:12:13 -0400 (EDT) > From: Tazim Kolhar > To: Ladislav Jozsa > Cc: Tazim Kolhar > Subject: Request to change the password for RHN accounts: > > Hi, > > I have been using the below doc to register my system to rhn : > https://docspace.corp.redhat.com/docs/DOC-64963 > > While, discussing a Bug with the team I somehow made the password > 'public' by mistake. > > Requesting, you to please change the password for the above > accounts in order to avoid free subscriptions. > Also, please modify the doc accordingly. > > > Thanks & Regards, > Tazim. > > ----- End forwarded message ----- > > -- > Ladislav Jozsa > Release Test Team > Quality Assurance Engineer > Red Hat, Inc., Brno Office > +420 608 73 7620 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From bkearney at redhat.com Thu Oct 18 12:14:42 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 18 Oct 2012 08:14:42 -0400 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507FCD31.4070700@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> Message-ID: <507FF2B2.8070004@redhat.com> On 10/18/2012 05:34 AM, Dmitri Dolguikh wrote: > On 18/10/12 09:22 AM, Ivan Ne?as wrote: >> On 10/17/2012 07:18 PM, Hugh Brock wrote: >>> On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote: >>>> On 17/10/12 05:04 PM, Jason Rist wrote: >>>>> On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: >>>>>> As part of port to Ruby 1.9.3, I'd suggest moving away from custom >>>>>> ruby >>>>>> repository for bundler-based installs, and switch to rubygems.org >>>>>> repository instead. Folks still would rather use Fedora-provided gems >>>>>> can do so, since Fedora 17 versions of 'bundler' and 'gem' are >>>>>> yum-aware. This would simplify dependency management during >>>>>> development. >>>>>> >>>>>> >>>>>> As the next step I'd like to propose to switch to rails 3.2 (the >>>>>> version >>>>>> of Rails that's going to be shipped with f18) in master (which is >>>>>> what >>>>>> Aeolus folks did). >> Let's call it Fedora 18 support :) >>>>>> >>>>>> >>>>>> -d >>>>>> >>>>>> _______________________________________________ >>>>>> katello-devel mailing list >>>>>> katello-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>> I think this is what we should have been doing. Can we not develop >>>>> upstream in a more normal rails fashion and then deal with >>>>> packaging and >>>>> the like downstream? Or is that too much work? >>>>> >>>> I'm not sure why we aren't doing this atm. Considering that we have >>>> a suite of integration tests that is being run *after* katello has >>>> been packaged, it's safe to split development and packaging - we are >>>> able to catch the issues. >> Here are some reasons why we care about RPM packages from the beginning: >> >> 1. Katello as a working thing by far isn't just a Rails app and >> outside of the Ruby word gems mean nothing. >> 2. The installation process is part of the whole project. Using the >> installation process that will be used in production from start means >> catching the issues sooner than just before release >> 3. Creating an RPM forces you to thing about the license soon. It's >> not pleasant to find out that your code is not shipable because of the >> licensing issues >> 4. The code has to work on the target platform (which is Fedora an >> RHEL for us), and (as Metallica sings) nothing else matters >> 5. Things like selinux need to be solved as well. >> 6. This approach is Continuous Delivery compliant: and now we are >> having 2-months CR release cycle >> >> You can do whatever you want on the development machine. And I have >> nothing against improvements that will make development on non-Fedora >> based systems easier. But when you want to merge into the master, you >> have to count on the fact that somebody will want to install it on >> test or production machine. >> >> Unlike Aeolus, we don't try to get Katello into Fedora official repos >> yet (though our client packages are already there). And getting the >> packages to Fedora it the thing that makes the packaging harder and >> slows down the process: waiting for 2 weeks till the library can be >> used is just too much. Therefore we have our own Koji instance, where >> the deps go in the first place, and then we can work on getting them >> to Fedora later while development goes on. >> >> So what I'm saying is: it would be great if someone clones our repo, >> runs bundle install and the server runs on every platform (though I >> don't thing forcing the developer to run all the deps (like Pulp, >> Candlepin, Katello-Cli) from source would make the Rails developer >> happy. But giving up our nightly builds and all the good things that >> go with it just for this reason is really huge step backward. And I >> don't see a reason that this two things couldn't co-exist together. >> >> -- Ivan > > I think we need to standardize on whether replies go above or below the > original comment :) > > > I don't think anybody participating in this thread suggests that > packaging is not important. Nor is anyone talking about about abandoning > nightly builds, etc. > > I'm suggesting that we remove development process dependency on build > artifacts. Let's use rubygems.org in development (I know of several > people who are doing this already; it's *very* useful to be able to add > new dependencies in development quickly). Let's use system-provided gems > in packaged Katello. > +1 -- bk From thomasmckay at redhat.com Thu Oct 18 12:15:42 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 18 Oct 2012 08:15:42 -0400 (EDT) Subject: [katello-devel] Retrieving "listing" files from pulp In-Reply-To: <841981768.9415878.1350500324650.JavaMail.root@redhat.com> Message-ID: <1212980704.9652554.1350562542836.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tom McKay" > To: pulp-list at redhat.com, "katello-devel" > Cc: "John Sefler" > Sent: Wednesday, October 17, 2012 2:58:44 PM > Subject: [katello-devel] Retrieving "listing" files from pulp > > > Working on a BZ [1] where the available releases are not being > displayed in subscription-manager. These are fetched from the CDN, > which in the case of katello is pulp, via the /listing files > > /content/dist/rhel/server/6/listing > 6.1 > 6.2 > 6.3 > 6Server > > This is what sub-mgr is effectively doing: > > % curl --stderr /dev/null --insecure --tlsv1 --cert > /etc/pki/entitlement/1203469290095408448.pem --key > /etc/pki/entitlement/1203469290095408448-key.pem > https://se-rhelbox.usersys.redhat.com/pulp/repos/Test_Org_1349760599/Dev//content/dist/rhel/server/5/listing > > But this results in a 403. > > A second issue is that there are no listing files at all in the pulp > repos. ie. server/5/listing does not exist compared to what's in > production and stage cdn. > > Help? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=832118 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > So we've discovered why there are no listing files, however, what credentials should be used when curl'ing against pulp in a katello setting? QE needs this to work since they compare what subscription-manager returns versus what is really there. From hbrock at redhat.com Thu Oct 18 12:22:47 2012 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 18 Oct 2012 08:22:47 -0400 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507FF2B2.8070004@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> Message-ID: <20121018122247.GZ12308@redhat.com> On Thu, Oct 18, 2012 at 08:14:42AM -0400, Bryan Kearney wrote: > On 10/18/2012 05:34 AM, Dmitri Dolguikh wrote: > >On 18/10/12 09:22 AM, Ivan Ne?as wrote: > >>On 10/17/2012 07:18 PM, Hugh Brock wrote: > >>>On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote: > >>>>On 17/10/12 05:04 PM, Jason Rist wrote: > >>>>>On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: > >>>>>>As part of port to Ruby 1.9.3, I'd suggest moving away from custom > >>>>>>ruby > >>>>>>repository for bundler-based installs, and switch to rubygems.org > >>>>>>repository instead. Folks still would rather use Fedora-provided gems > >>>>>>can do so, since Fedora 17 versions of 'bundler' and 'gem' are > >>>>>>yum-aware. This would simplify dependency management during > >>>>>>development. > >>>>>> > >>>>>> > >>>>>>As the next step I'd like to propose to switch to rails 3.2 (the > >>>>>>version > >>>>>>of Rails that's going to be shipped with f18) in master (which is > >>>>>>what > >>>>>>Aeolus folks did). > >>Let's call it Fedora 18 support :) > >>>>>> > >>>>>> > >>>>>>-d > >>>>>> > >>>>>>_______________________________________________ > >>>>>>katello-devel mailing list > >>>>>>katello-devel at redhat.com > >>>>>>https://www.redhat.com/mailman/listinfo/katello-devel > >>>>>I think this is what we should have been doing. Can we not develop > >>>>>upstream in a more normal rails fashion and then deal with > >>>>>packaging and > >>>>>the like downstream? Or is that too much work? > >>>>> > >>>>I'm not sure why we aren't doing this atm. Considering that we have > >>>>a suite of integration tests that is being run *after* katello has > >>>>been packaged, it's safe to split development and packaging - we are > >>>>able to catch the issues. > >>Here are some reasons why we care about RPM packages from the beginning: > >> > >>1. Katello as a working thing by far isn't just a Rails app and > >>outside of the Ruby word gems mean nothing. > >>2. The installation process is part of the whole project. Using the > >>installation process that will be used in production from start means > >>catching the issues sooner than just before release > >>3. Creating an RPM forces you to thing about the license soon. It's > >>not pleasant to find out that your code is not shipable because of the > >>licensing issues > >>4. The code has to work on the target platform (which is Fedora an > >>RHEL for us), and (as Metallica sings) nothing else matters > >>5. Things like selinux need to be solved as well. > >>6. This approach is Continuous Delivery compliant: and now we are > >>having 2-months CR release cycle > >> > >>You can do whatever you want on the development machine. And I have > >>nothing against improvements that will make development on non-Fedora > >>based systems easier. But when you want to merge into the master, you > >>have to count on the fact that somebody will want to install it on > >>test or production machine. > >> > >>Unlike Aeolus, we don't try to get Katello into Fedora official repos > >>yet (though our client packages are already there). And getting the > >>packages to Fedora it the thing that makes the packaging harder and > >>slows down the process: waiting for 2 weeks till the library can be > >>used is just too much. Therefore we have our own Koji instance, where > >>the deps go in the first place, and then we can work on getting them > >>to Fedora later while development goes on. > >> > >>So what I'm saying is: it would be great if someone clones our repo, > >>runs bundle install and the server runs on every platform (though I > >>don't thing forcing the developer to run all the deps (like Pulp, > >>Candlepin, Katello-Cli) from source would make the Rails developer > >>happy. But giving up our nightly builds and all the good things that > >>go with it just for this reason is really huge step backward. And I > >>don't see a reason that this two things couldn't co-exist together. > >> > >>-- Ivan > > > >I think we need to standardize on whether replies go above or below the > >original comment :) > > > > > >I don't think anybody participating in this thread suggests that > >packaging is not important. Nor is anyone talking about about abandoning > >nightly builds, etc. > > > >I'm suggesting that we remove development process dependency on build > >artifacts. Let's use rubygems.org in development (I know of several > >people who are doing this already; it's *very* useful to be able to add > >new dependencies in development quickly). Let's use system-provided gems > >in packaged Katello. > > > +1 This is exactly the mode we are pushing to in Aeolus. I should point out that it is not only the normal mode for upstream Ruby projects, it is the normal mode for *almost all* upstream projects that are not completely Red-Hat centric. libvirt is a good example of this. It is a C project, as you know, and Red Hat delivers it entirely packaged as RPM. But Daniel Veillard, the libvirt maintainer, *will not even allow rpm spec files* in the libvirt tree upstream, just as he does not allow debian package instructions. libvirt upstream is delivered and installed with tar -xvzf libvirt.tgz; ./configure; make; make install. The libvirt crew, because they work for Red Hat, also get to spend a good bit of time maintaining the Fedora and RHEL rpm specs. This is an overhead investment that is worth the effort because it makes it easier for Red Hat to deliver libvirt. The libvirt crew *also* spend some amount of time maintaining the .deb build, becasue it's good for community adoption, but this is also done out of band. Core libvirt contributors however do not get concerned with packaging. I see no reason why any of our Ruby projects should follow a different development mode than this. --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 Thu Oct 18 12:25:16 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 18 Oct 2012 08:25:16 -0400 Subject: [katello-devel] Retrieving "listing" files from pulp In-Reply-To: <507FBBBB.6030206@redhat.com> References: <841981768.9415878.1350500324650.JavaMail.root@redhat.com> <507FBBBB.6030206@redhat.com> Message-ID: <507FF52C.4050109@redhat.com> On 10/18/2012 04:20 AM, Ivan Ne?as wrote: > On 10/17/2012 08:58 PM, Tom McKay wrote: >> Working on a BZ [1] where the available releases are not being >> displayed in subscription-manager. These are fetched from the CDN, >> which in the case of katello is pulp, via the /listing files >> >> /content/dist/rhel/server/6/listing >> 6.1 >> 6.2 >> 6.3 >> 6Server >> >> This is what sub-mgr is effectively doing: >> >> % curl --stderr /dev/null --insecure --tlsv1 --cert >> /etc/pki/entitlement/1203469290095408448.pem --key >> /etc/pki/entitlement/1203469290095408448-key.pem >> https://se-rhelbox.usersys.redhat.com/pulp/repos/Test_Org_1349760599/Dev//content/dist/rhel/server/5/listing >> >> >> But this results in a 403. >> >> A second issue is that there are no listing files at all in the pulp >> repos. ie. server/5/listing does not exist compared to what's in >> production and stage cdn. > That's the issue. Pulp doesn't support listing files. However, Katello > provides the api returning the available releases. [1] > I thought pulp pulled this down? -- bk From thomasmckay at redhat.com Thu Oct 18 12:32:11 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 18 Oct 2012 08:32:11 -0400 (EDT) Subject: [katello-devel] Retrieving "listing" files from pulp In-Reply-To: <1212980704.9652554.1350562542836.JavaMail.root@redhat.com> Message-ID: <884195591.9657484.1350563531709.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tom McKay" > To: "katello-devel" > Cc: "John Sefler" > Sent: Thursday, October 18, 2012 8:15:42 AM > Subject: Re: [katello-devel] Retrieving "listing" files from pulp > > > > ----- Original Message ----- > > From: "Tom McKay" > > To: pulp-list at redhat.com, "katello-devel" > > > > Cc: "John Sefler" > > Sent: Wednesday, October 17, 2012 2:58:44 PM > > Subject: [katello-devel] Retrieving "listing" files from pulp > > > > > > Working on a BZ [1] where the available releases are not being > > displayed in subscription-manager. These are fetched from the CDN, > > which in the case of katello is pulp, via the /listing files > > > > /content/dist/rhel/server/6/listing > > 6.1 > > 6.2 > > 6.3 > > 6Server > > > > This is what sub-mgr is effectively doing: > > > > % curl --stderr /dev/null --insecure --tlsv1 --cert > > /etc/pki/entitlement/1203469290095408448.pem --key > > /etc/pki/entitlement/1203469290095408448-key.pem > > https://se-rhelbox.usersys.redhat.com/pulp/repos/Test_Org_1349760599/Dev//content/dist/rhel/server/5/listing > > > > But this results in a 403. > > > > A second issue is that there are no listing files at all in the > > pulp > > repos. ie. server/5/listing does not exist compared to what's in > > production and stage cdn. > > > > Help? > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=832118 > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > So we've discovered why there are no listing files, however, what > credentials should be used when curl'ing against pulp in a katello > setting? QE needs this to work since they compare what > subscription-manager returns versus what is really there. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > Sorry, the reason there are no listing files is that pulp does not sync those; BZ/RFE submitted. From daviddavis at redhat.com Thu Oct 18 12:45:06 2012 From: daviddavis at redhat.com (David Davis) Date: Thu, 18 Oct 2012 08:45:06 -0400 (EDT) Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121018122247.GZ12308@redhat.com> Message-ID: <767004935.14032999.1350564306445.JavaMail.root@redhat.com> +10 David ----- Original Message ----- > From: "Hugh Brock" > To: "Bryan Kearney" > Cc: katello-devel at redhat.com > Sent: Thursday, October 18, 2012 8:22:47 AM > Subject: Re: [katello-devel] moving to ruby 1.9.3 > > On Thu, Oct 18, 2012 at 08:14:42AM -0400, Bryan Kearney wrote: > > On 10/18/2012 05:34 AM, Dmitri Dolguikh wrote: > > >On 18/10/12 09:22 AM, Ivan Ne?as wrote: > > >>On 10/17/2012 07:18 PM, Hugh Brock wrote: > > >>>On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote: > > >>>>On 17/10/12 05:04 PM, Jason Rist wrote: > > >>>>>On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: > > >>>>>>As part of port to Ruby 1.9.3, I'd suggest moving away from > > >>>>>>custom > > >>>>>>ruby > > >>>>>>repository for bundler-based installs, and switch to > > >>>>>>rubygems.org > > >>>>>>repository instead. Folks still would rather use > > >>>>>>Fedora-provided gems > > >>>>>>can do so, since Fedora 17 versions of 'bundler' and 'gem' > > >>>>>>are > > >>>>>>yum-aware. This would simplify dependency management during > > >>>>>>development. > > >>>>>> > > >>>>>> > > >>>>>>As the next step I'd like to propose to switch to rails 3.2 > > >>>>>>(the > > >>>>>>version > > >>>>>>of Rails that's going to be shipped with f18) in master > > >>>>>>(which is > > >>>>>>what > > >>>>>>Aeolus folks did). > > >>Let's call it Fedora 18 support :) > > >>>>>> > > >>>>>> > > >>>>>>-d > > >>>>>> > > >>>>>>_______________________________________________ > > >>>>>>katello-devel mailing list > > >>>>>>katello-devel at redhat.com > > >>>>>>https://www.redhat.com/mailman/listinfo/katello-devel > > >>>>>I think this is what we should have been doing. Can we not > > >>>>>develop > > >>>>>upstream in a more normal rails fashion and then deal with > > >>>>>packaging and > > >>>>>the like downstream? Or is that too much work? > > >>>>> > > >>>>I'm not sure why we aren't doing this atm. Considering that we > > >>>>have > > >>>>a suite of integration tests that is being run *after* katello > > >>>>has > > >>>>been packaged, it's safe to split development and packaging - > > >>>>we are > > >>>>able to catch the issues. > > >>Here are some reasons why we care about RPM packages from the > > >>beginning: > > >> > > >>1. Katello as a working thing by far isn't just a Rails app and > > >>outside of the Ruby word gems mean nothing. > > >>2. The installation process is part of the whole project. Using > > >>the > > >>installation process that will be used in production from start > > >>means > > >>catching the issues sooner than just before release > > >>3. Creating an RPM forces you to thing about the license soon. > > >>It's > > >>not pleasant to find out that your code is not shipable because > > >>of the > > >>licensing issues > > >>4. The code has to work on the target platform (which is Fedora > > >>an > > >>RHEL for us), and (as Metallica sings) nothing else matters > > >>5. Things like selinux need to be solved as well. > > >>6. This approach is Continuous Delivery compliant: and now we are > > >>having 2-months CR release cycle > > >> > > >>You can do whatever you want on the development machine. And I > > >>have > > >>nothing against improvements that will make development on > > >>non-Fedora > > >>based systems easier. But when you want to merge into the master, > > >>you > > >>have to count on the fact that somebody will want to install it > > >>on > > >>test or production machine. > > >> > > >>Unlike Aeolus, we don't try to get Katello into Fedora official > > >>repos > > >>yet (though our client packages are already there). And getting > > >>the > > >>packages to Fedora it the thing that makes the packaging harder > > >>and > > >>slows down the process: waiting for 2 weeks till the library can > > >>be > > >>used is just too much. Therefore we have our own Koji instance, > > >>where > > >>the deps go in the first place, and then we can work on getting > > >>them > > >>to Fedora later while development goes on. > > >> > > >>So what I'm saying is: it would be great if someone clones our > > >>repo, > > >>runs bundle install and the server runs on every platform (though > > >>I > > >>don't thing forcing the developer to run all the deps (like Pulp, > > >>Candlepin, Katello-Cli) from source would make the Rails > > >>developer > > >>happy. But giving up our nightly builds and all the good things > > >>that > > >>go with it just for this reason is really huge step backward. And > > >>I > > >>don't see a reason that this two things couldn't co-exist > > >>together. > > >> > > >>-- Ivan > > > > > >I think we need to standardize on whether replies go above or > > >below the > > >original comment :) > > > > > > > > >I don't think anybody participating in this thread suggests that > > >packaging is not important. Nor is anyone talking about about > > >abandoning > > >nightly builds, etc. > > > > > >I'm suggesting that we remove development process dependency on > > >build > > >artifacts. Let's use rubygems.org in development (I know of > > >several > > >people who are doing this already; it's *very* useful to be able > > >to add > > >new dependencies in development quickly). Let's use > > >system-provided gems > > >in packaged Katello. > > > > > +1 > > This is exactly the mode we are pushing to in Aeolus. I should point > out > that it is not only the normal mode for upstream Ruby projects, it is > the normal mode for *almost all* upstream projects that are not > completely Red-Hat centric. > > libvirt is a good example of this. It is a C project, as you know, > and > Red Hat delivers it entirely packaged as RPM. But Daniel Veillard, > the > libvirt maintainer, *will not even allow rpm spec files* in the > libvirt > tree upstream, just as he does not allow debian package > instructions. libvirt upstream is delivered and installed with tar > -xvzf > libvirt.tgz; ./configure; make; make install. > > The libvirt crew, because they work for Red Hat, also get to spend a > good bit of time maintaining the Fedora and RHEL rpm specs. This is > an > overhead investment that is worth the effort because it makes it > easier > for Red Hat to deliver libvirt. The libvirt crew *also* spend some > amount of time maintaining the .deb build, becasue it's good for > community adoption, but this is also done out of band. Core libvirt > contributors however do not get concerned with packaging. > > I see no reason why any of our Ruby projects should follow a > different > development mode than this. > > --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 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From inecas at redhat.com Thu Oct 18 13:05:01 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 18 Oct 2012 15:05:01 +0200 Subject: [katello-devel] Retrieving "listing" files from pulp In-Reply-To: <884195591.9657484.1350563531709.JavaMail.root@redhat.com> References: <884195591.9657484.1350563531709.JavaMail.root@redhat.com> Message-ID: <507FFE7D.7010803@redhat.com> On 10/18/2012 02:32 PM, Tom McKay wrote: > > ----- Original Message ----- >> From: "Tom McKay" >> To: "katello-devel" >> Cc: "John Sefler" >> Sent: Thursday, October 18, 2012 8:15:42 AM >> Subject: Re: [katello-devel] Retrieving "listing" files from pulp >> >> >> >> ----- Original Message ----- >>> From: "Tom McKay" >>> To: pulp-list at redhat.com, "katello-devel" >>> >>> Cc: "John Sefler" >>> Sent: Wednesday, October 17, 2012 2:58:44 PM >>> Subject: [katello-devel] Retrieving "listing" files from pulp >>> >>> >>> Working on a BZ [1] where the available releases are not being >>> displayed in subscription-manager. These are fetched from the CDN, >>> which in the case of katello is pulp, via the /listing files >>> >>> /content/dist/rhel/server/6/listing >>> 6.1 >>> 6.2 >>> 6.3 >>> 6Server >>> >>> This is what sub-mgr is effectively doing: >>> >>> % curl --stderr /dev/null --insecure --tlsv1 --cert >>> /etc/pki/entitlement/1203469290095408448.pem --key >>> /etc/pki/entitlement/1203469290095408448-key.pem >>> https://se-rhelbox.usersys.redhat.com/pulp/repos/Test_Org_1349760599/Dev//content/dist/rhel/server/5/listing >>> >>> But this results in a 403. >>> >>> A second issue is that there are no listing files at all in the >>> pulp >>> repos. ie. server/5/listing does not exist compared to what's in >>> production and stage cdn. >>> >>> Help? >>> >>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=832118 >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> So we've discovered why there are no listing files, however, what >> credentials should be used when curl'ing against pulp in a katello >> setting? QE needs this to work since they compare what >> subscription-manager returns versus what is really there. >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > Sorry, the reason there are no listing files is that pulp does not sync those; BZ/RFE submitted. I don't think Pulp will synchronize those by its own because we feed it with the full url of the repo (such as content/nature/ver/arch/os), but the listing files are in content/nature/listing and content/nature/ver/listing. Therefore Katello should be the one that should be able to push those listing files to Pulp. The second option would be Pulp providing the lisitng "files" dynamically. -- Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From jweiss at redhat.com Thu Oct 18 13:30:44 2012 From: jweiss at redhat.com (Jeff Weiss) Date: Thu, 18 Oct 2012 09:30:44 -0400 (EDT) Subject: [katello-devel] [tkolhar@redhat.com: Request to change the password for RHN accounts:] In-Reply-To: <1013018230.9648665.1350561237568.JavaMail.root@redhat.com> Message-ID: <1955730216.3227871.1350567044671.JavaMail.root@redhat.com> I guess before we do that, we should find out if machines currently registered to that account will actually stop receiving updates until their account info is changed. I assumed that was the case, but I am actually not sure now that I think about it. Anyone know if that is what will happen? -jeff ----- Original Message ----- From: "Tom McKay" To: "Tazim Kolhar" Cc: "Ladislav Jozsa" , infosec at redhat.com, katello-devel at redhat.com Sent: Thursday, October 18, 2012 1:53:57 PM Subject: Re: [katello-devel] [tkolhar at redhat.com: Request to change the password for RHN accounts:] ----- Original Message ----- > From: "Tazim Kolhar" > To: "Ladislav Jozsa" > Cc: katello-devel at redhat.com, infosec at redhat.com > Sent: Thursday, October 18, 2012 5:10:27 AM > Subject: Re: [katello-devel] [tkolhar at redhat.com: Request to change the password for RHN accounts:] > > Hi, > > Sorry, actually I just came to know, there are lot of machines > using that account that will stop working if the password is > changed. > Please, DO NOT change the account passwords to avoid any further > issues. > Please, ignore the request to change passwords. > > > Thanks & Regards, > Tazim. > > > > Please don't change the password, there are hundreds of machines > > using that account that will stop working if the password is > > changed. > > >-Jeff I would bump this a bit higher up the chain. The password went out to a publicly archived email list. You can choose to live with that hole with the potential of anyone registering and subscribing to real Red Hat content, or you can close it. > > ----- Original Message ----- > From: "Ladislav Jozsa" > To: infosec at redhat.com > Cc: tkolhar at redhat.com > Sent: Thursday, October 18, 2012 2:20:03 PM > Subject: [tkolhar at redhat.com: Request to change the password for RHN > accounts:] > > Hi, > > could you please arrange password change for RHN QA due to its > compromise in Bugzilla? > > Many thanks, > Ladislav > > ----- Forwarded message from Tazim Kolhar ----- > > Date: Thu, 18 Oct 2012 04:12:13 -0400 (EDT) > From: Tazim Kolhar > To: Ladislav Jozsa > Cc: Tazim Kolhar > Subject: Request to change the password for RHN accounts: > > Hi, > > I have been using the below doc to register my system to rhn : > https://docspace.corp.redhat.com/docs/DOC-64963 > > While, discussing a Bug with the team I somehow made the password > 'public' by mistake. > > Requesting, you to please change the password for the above > accounts in order to avoid free subscriptions. > Also, please modify the doc accordingly. > > > Thanks & Regards, > Tazim. > > ----- End forwarded message ----- > > -- > Ladislav Jozsa > Release Test Team > Quality Assurance Engineer > Red Hat, Inc., Brno Office > +420 608 73 7620 > > _______________________________________________ > 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 jweiss at redhat.com Thu Oct 18 14:05:03 2012 From: jweiss at redhat.com (Jeff Weiss) Date: Thu, 18 Oct 2012 10:05:03 -0400 (EDT) Subject: [katello-devel] [tkolhar@redhat.com: Request to change the password for RHN accounts:] In-Reply-To: <20121018134758.GD7501@skywalker.redhat.com> Message-ID: <511808165.3251755.1350569103974.JavaMail.root@redhat.com> Ok then I think we should go ahead and change the password. Sorry for the confusion. -Jeff ----- Original Message ----- From: "Ladislav Jozsa" To: "Jeff Weiss" Cc: "Tom McKay" , infosec at redhat.com, katello-devel at redhat.com, "Tazim Kolhar" Sent: Thursday, October 18, 2012 3:47:58 PM Subject: Re: [katello-devel] [tkolhar at redhat.com: Request to change the password for RHN accounts:] Machines registered to the CDN (via subscription manager) will work and will receive updates. When such machine is registered to the CDN for the first time, it obtains a certificate and all further authentication is certficated based. You need the login and password only for the first time registration. yum updates will work normally. Regards, Ladislav On Oct 18 2012, Jeff Weiss wrote: | I guess before we do that, we should find out if machines currently registered to that account will actually stop receiving updates until their account info is changed. I assumed that was the case, but I am actually not sure now that I think about it. | | Anyone know if that is what will happen? | | -jeff | | | ----- Original Message ----- | From: "Tom McKay" | To: "Tazim Kolhar" | Cc: "Ladislav Jozsa" , infosec at redhat.com, katello-devel at redhat.com | Sent: Thursday, October 18, 2012 1:53:57 PM | Subject: Re: [katello-devel] [tkolhar at redhat.com: Request to change the password for RHN accounts:] | | | | ----- Original Message ----- | > From: "Tazim Kolhar" | > To: "Ladislav Jozsa" | > Cc: katello-devel at redhat.com, infosec at redhat.com | > Sent: Thursday, October 18, 2012 5:10:27 AM | > Subject: Re: [katello-devel] [tkolhar at redhat.com: Request to change the password for RHN accounts:] | > | > Hi, | > | > Sorry, actually I just came to know, there are lot of machines | > using that account that will stop working if the password is | > changed. | > Please, DO NOT change the account passwords to avoid any further | > issues. | > Please, ignore the request to change passwords. | > | > | > Thanks & Regards, | > Tazim. | > | > | > > Please don't change the password, there are hundreds of machines | > > using that account that will stop working if the password is | > > changed. | > | > >-Jeff | | I would bump this a bit higher up the chain. The password went out to a publicly archived email list. You can choose to live with that hole with the potential of anyone registering and subscribing to real Red Hat content, or you can close it. | | > | > ----- Original Message ----- | > From: "Ladislav Jozsa" | > To: infosec at redhat.com | > Cc: tkolhar at redhat.com | > Sent: Thursday, October 18, 2012 2:20:03 PM | > Subject: [tkolhar at redhat.com: Request to change the password for RHN | > accounts:] | > | > Hi, | > | > could you please arrange password change for RHN QA due to its | > compromise in Bugzilla? | > | > Many thanks, | > Ladislav | > | > ----- Forwarded message from Tazim Kolhar ----- | > | > Date: Thu, 18 Oct 2012 04:12:13 -0400 (EDT) | > From: Tazim Kolhar | > To: Ladislav Jozsa | > Cc: Tazim Kolhar | > Subject: Request to change the password for RHN accounts: | > | > Hi, | > | > I have been using the below doc to register my system to rhn : | > https://docspace.corp.redhat.com/docs/DOC-64963 | > | > While, discussing a Bug with the team I somehow made the password | > 'public' by mistake. | > | > Requesting, you to please change the password for the above | > accounts in order to avoid free subscriptions. | > Also, please modify the doc accordingly. | > | > | > Thanks & Regards, | > Tazim. | > | > ----- End forwarded message ----- | > | > -- | > Ladislav Jozsa | > Release Test Team | > Quality Assurance Engineer | > Red Hat, Inc., Brno Office | > +420 608 73 7620 | > | > _______________________________________________ | > 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 -- Ladislav Jozsa Release Test Team Quality Assurance Engineer Red Hat, Inc., Brno Office +420 608 73 7620 From inecas at redhat.com Thu Oct 18 14:56:07 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 18 Oct 2012 16:56:07 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <767004935.14032999.1350564306445.JavaMail.root@redhat.com> References: <767004935.14032999.1350564306445.JavaMail.root@redhat.com> Message-ID: <50801887.30401@redhat.com> Just to put it on the right track: no development dependency will break the nightly RPM builds. Neither the build nor the production RPMs are dependent on the custom gems repo. So nobody's holding you form getting rid of custom repo, keeping the information about the dependencies in the Gemfile, maintaining a wiki page (or better a script because the wiki will get more obsolete sooner than you finish writing it) to run everything without RPMs at all etc. But if you add production dependencies, you should care about it running in production from the beginning, that's all I ask you for. -- Ivan On 10/18/2012 02:45 PM, David Davis wrote: > +10 > > David > > ----- Original Message ----- >> From: "Hugh Brock" >> To: "Bryan Kearney" >> Cc: katello-devel at redhat.com >> Sent: Thursday, October 18, 2012 8:22:47 AM >> Subject: Re: [katello-devel] moving to ruby 1.9.3 >> >> On Thu, Oct 18, 2012 at 08:14:42AM -0400, Bryan Kearney wrote: >>> On 10/18/2012 05:34 AM, Dmitri Dolguikh wrote: >>>> On 18/10/12 09:22 AM, Ivan Ne?as wrote: >>>>> On 10/17/2012 07:18 PM, Hugh Brock wrote: >>>>>> On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote: >>>>>>> On 17/10/12 05:04 PM, Jason Rist wrote: >>>>>>>> On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: >>>>>>>>> As part of port to Ruby 1.9.3, I'd suggest moving away from >>>>>>>>> custom >>>>>>>>> ruby >>>>>>>>> repository for bundler-based installs, and switch to >>>>>>>>> rubygems.org >>>>>>>>> repository instead. Folks still would rather use >>>>>>>>> Fedora-provided gems >>>>>>>>> can do so, since Fedora 17 versions of 'bundler' and 'gem' >>>>>>>>> are >>>>>>>>> yum-aware. This would simplify dependency management during >>>>>>>>> development. >>>>>>>>> >>>>>>>>> >>>>>>>>> As the next step I'd like to propose to switch to rails 3.2 >>>>>>>>> (the >>>>>>>>> version >>>>>>>>> of Rails that's going to be shipped with f18) in master >>>>>>>>> (which is >>>>>>>>> what >>>>>>>>> Aeolus folks did). >>>>> Let's call it Fedora 18 support :) >>>>>>>>> >>>>>>>>> -d >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> katello-devel mailing list >>>>>>>>> katello-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>>>> I think this is what we should have been doing. Can we not >>>>>>>> develop >>>>>>>> upstream in a more normal rails fashion and then deal with >>>>>>>> packaging and >>>>>>>> the like downstream? Or is that too much work? >>>>>>>> >>>>>>> I'm not sure why we aren't doing this atm. Considering that we >>>>>>> have >>>>>>> a suite of integration tests that is being run *after* katello >>>>>>> has >>>>>>> been packaged, it's safe to split development and packaging - >>>>>>> we are >>>>>>> able to catch the issues. >>>>> Here are some reasons why we care about RPM packages from the >>>>> beginning: >>>>> >>>>> 1. Katello as a working thing by far isn't just a Rails app and >>>>> outside of the Ruby word gems mean nothing. >>>>> 2. The installation process is part of the whole project. Using >>>>> the >>>>> installation process that will be used in production from start >>>>> means >>>>> catching the issues sooner than just before release >>>>> 3. Creating an RPM forces you to thing about the license soon. >>>>> It's >>>>> not pleasant to find out that your code is not shipable because >>>>> of the >>>>> licensing issues >>>>> 4. The code has to work on the target platform (which is Fedora >>>>> an >>>>> RHEL for us), and (as Metallica sings) nothing else matters >>>>> 5. Things like selinux need to be solved as well. >>>>> 6. This approach is Continuous Delivery compliant: and now we are >>>>> having 2-months CR release cycle >>>>> >>>>> You can do whatever you want on the development machine. And I >>>>> have >>>>> nothing against improvements that will make development on >>>>> non-Fedora >>>>> based systems easier. But when you want to merge into the master, >>>>> you >>>>> have to count on the fact that somebody will want to install it >>>>> on >>>>> test or production machine. >>>>> >>>>> Unlike Aeolus, we don't try to get Katello into Fedora official >>>>> repos >>>>> yet (though our client packages are already there). And getting >>>>> the >>>>> packages to Fedora it the thing that makes the packaging harder >>>>> and >>>>> slows down the process: waiting for 2 weeks till the library can >>>>> be >>>>> used is just too much. Therefore we have our own Koji instance, >>>>> where >>>>> the deps go in the first place, and then we can work on getting >>>>> them >>>>> to Fedora later while development goes on. >>>>> >>>>> So what I'm saying is: it would be great if someone clones our >>>>> repo, >>>>> runs bundle install and the server runs on every platform (though >>>>> I >>>>> don't thing forcing the developer to run all the deps (like Pulp, >>>>> Candlepin, Katello-Cli) from source would make the Rails >>>>> developer >>>>> happy. But giving up our nightly builds and all the good things >>>>> that >>>>> go with it just for this reason is really huge step backward. And >>>>> I >>>>> don't see a reason that this two things couldn't co-exist >>>>> together. >>>>> >>>>> -- Ivan >>>> I think we need to standardize on whether replies go above or >>>> below the >>>> original comment :) >>>> >>>> >>>> I don't think anybody participating in this thread suggests that >>>> packaging is not important. Nor is anyone talking about about >>>> abandoning >>>> nightly builds, etc. >>>> >>>> I'm suggesting that we remove development process dependency on >>>> build >>>> artifacts. Let's use rubygems.org in development (I know of >>>> several >>>> people who are doing this already; it's *very* useful to be able >>>> to add >>>> new dependencies in development quickly). Let's use >>>> system-provided gems >>>> in packaged Katello. >>>> >>> +1 >> This is exactly the mode we are pushing to in Aeolus. I should point >> out >> that it is not only the normal mode for upstream Ruby projects, it is >> the normal mode for *almost all* upstream projects that are not >> completely Red-Hat centric. >> >> libvirt is a good example of this. It is a C project, as you know, >> and >> Red Hat delivers it entirely packaged as RPM. But Daniel Veillard, >> the >> libvirt maintainer, *will not even allow rpm spec files* in the >> libvirt >> tree upstream, just as he does not allow debian package >> instructions. libvirt upstream is delivered and installed with tar >> -xvzf >> libvirt.tgz; ./configure; make; make install. >> >> The libvirt crew, because they work for Red Hat, also get to spend a >> good bit of time maintaining the Fedora and RHEL rpm specs. This is >> an >> overhead investment that is worth the effort because it makes it >> easier >> for Red Hat to deliver libvirt. The libvirt crew *also* spend some >> amount of time maintaining the .deb build, becasue it's good for >> community adoption, but this is also done out of band. Core libvirt >> contributors however do not get concerned with packaging. >> >> I see no reason why any of our Ruby projects should follow a >> different >> development mode than this. >> >> --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 >> >> _______________________________________________ >> 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 mmccune at redhat.com Thu Oct 18 14:56:24 2012 From: mmccune at redhat.com (Mike McCune) Date: Thu, 18 Oct 2012 07:56:24 -0700 Subject: [katello-devel] [tkolhar@redhat.com: Request to change the password for RHN accounts:] In-Reply-To: <1955730216.3227871.1350567044671.JavaMail.root@redhat.com> References: <1955730216.3227871.1350567044671.JavaMail.root@redhat.com> Message-ID: <50801898.6080301@redhat.com> changing a RHN password shouldn't effect the systems from receiving updates. The only time the username and password is used for authentication is during *registration*. After that the system is authorized with the systemid file stored on the managed system. Changing the password in RHN should not effect any of the registered machines if my memory serves me correct. Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 On 10/18/2012 06:30 AM, Jeff Weiss wrote: > I guess before we do that, we should find out if machines currently registered to that account will actually stop receiving updates until their account info is changed. I assumed that was the case, but I am actually not sure now that I think about it. > > Anyone know if that is what will happen? > > -jeff > > > ----- Original Message ----- > From: "Tom McKay" > To: "Tazim Kolhar" > Cc: "Ladislav Jozsa", infosec at redhat.com, katello-devel at redhat.com > Sent: Thursday, October 18, 2012 1:53:57 PM > Subject: Re: [katello-devel] [tkolhar at redhat.com: Request to change the password for RHN accounts:] > > > > ----- Original Message ----- >> From: "Tazim Kolhar" >> To: "Ladislav Jozsa" >> Cc: katello-devel at redhat.com, infosec at redhat.com >> Sent: Thursday, October 18, 2012 5:10:27 AM >> Subject: Re: [katello-devel] [tkolhar at redhat.com: Request to change the password for RHN accounts:] >> >> Hi, >> >> Sorry, actually I just came to know, there are lot of machines >> using that account that will stop working if the password is >> changed. >> Please, DO NOT change the account passwords to avoid any further >> issues. >> Please, ignore the request to change passwords. >> >> >> Thanks& Regards, >> Tazim. >> >> >>> Please don't change the password, there are hundreds of machines >>> using that account that will stop working if the password is >>> changed. >> >>> -Jeff > > I would bump this a bit higher up the chain. The password went out to a publicly archived email list. You can choose to live with that hole with the potential of anyone registering and subscribing to real Red Hat content, or you can close it. > >> >> ----- Original Message ----- >> From: "Ladislav Jozsa" >> To: infosec at redhat.com >> Cc: tkolhar at redhat.com >> Sent: Thursday, October 18, 2012 2:20:03 PM >> Subject: [tkolhar at redhat.com: Request to change the password for RHN >> accounts:] >> >> Hi, >> >> could you please arrange password change for RHN QA due to its >> compromise in Bugzilla? >> >> Many thanks, >> Ladislav >> >> ----- Forwarded message from Tazim Kolhar ----- >> >> Date: Thu, 18 Oct 2012 04:12:13 -0400 (EDT) >> From: Tazim Kolhar >> To: Ladislav Jozsa >> Cc: Tazim Kolhar >> Subject: Request to change the password for RHN accounts: >> >> Hi, >> >> I have been using the below doc to register my system to rhn : >> https://docspace.corp.redhat.com/docs/DOC-64963 >> >> While, discussing a Bug with the team I somehow made the password >> 'public' by mistake. >> >> Requesting, you to please change the password for the above >> accounts in order to avoid free subscriptions. >> Also, please modify the doc accordingly. >> >> >> Thanks& Regards, >> Tazim. >> >> ----- End forwarded message ----- >> >> -- >> Ladislav Jozsa >> Release Test Team >> Quality Assurance Engineer >> Red Hat, Inc., Brno Office >> +420 608 73 7620 >> >> _______________________________________________ >> 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 cperry at redhat.com Thu Oct 18 15:39:44 2012 From: cperry at redhat.com (Cliff Perry) Date: Thu, 18 Oct 2012 16:39:44 +0100 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507FF2B2.8070004@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> Message-ID: <508022C0.9090405@redhat.com> On 10/18/2012 01:14 PM, Bryan Kearney wrote: > On 10/18/2012 05:34 AM, Dmitri Dolguikh wrote: >> On 18/10/12 09:22 AM, Ivan Ne?as wrote: >>> On 10/17/2012 07:18 PM, Hugh Brock wrote: >>>> On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote: >>>>> On 17/10/12 05:04 PM, Jason Rist wrote: >>>>>> On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: >>>>>>> As part of port to Ruby 1.9.3, I'd suggest moving away from custom >>>>>>> ruby >>>>>>> repository for bundler-based installs, and switch to rubygems.org >>>>>>> repository instead. Folks still would rather use Fedora-provided >>>>>>> gems >>>>>>> can do so, since Fedora 17 versions of 'bundler' and 'gem' are >>>>>>> yum-aware. This would simplify dependency management during >>>>>>> development. >>>>>>> >>>>>>> >>>>>>> As the next step I'd like to propose to switch to rails 3.2 (the >>>>>>> version >>>>>>> of Rails that's going to be shipped with f18) in master (which is >>>>>>> what >>>>>>> Aeolus folks did). >>> Let's call it Fedora 18 support :) >>>>>>> >>>>>>> >>>>>>> -d >>>>>>> >>>>>>> _______________________________________________ >>>>>>> katello-devel mailing list >>>>>>> katello-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>> I think this is what we should have been doing. Can we not develop >>>>>> upstream in a more normal rails fashion and then deal with >>>>>> packaging and >>>>>> the like downstream? Or is that too much work? >>>>>> >>>>> I'm not sure why we aren't doing this atm. Considering that we have >>>>> a suite of integration tests that is being run *after* katello has >>>>> been packaged, it's safe to split development and packaging - we are >>>>> able to catch the issues. >>> Here are some reasons why we care about RPM packages from the beginning: >>> >>> 1. Katello as a working thing by far isn't just a Rails app and >>> outside of the Ruby word gems mean nothing. >>> 2. The installation process is part of the whole project. Using the >>> installation process that will be used in production from start means >>> catching the issues sooner than just before release >>> 3. Creating an RPM forces you to thing about the license soon. It's >>> not pleasant to find out that your code is not shipable because of the >>> licensing issues >>> 4. The code has to work on the target platform (which is Fedora an >>> RHEL for us), and (as Metallica sings) nothing else matters >>> 5. Things like selinux need to be solved as well. >>> 6. This approach is Continuous Delivery compliant: and now we are >>> having 2-months CR release cycle >>> >>> You can do whatever you want on the development machine. And I have >>> nothing against improvements that will make development on non-Fedora >>> based systems easier. But when you want to merge into the master, you >>> have to count on the fact that somebody will want to install it on >>> test or production machine. >>> >>> Unlike Aeolus, we don't try to get Katello into Fedora official repos >>> yet (though our client packages are already there). And getting the >>> packages to Fedora it the thing that makes the packaging harder and >>> slows down the process: waiting for 2 weeks till the library can be >>> used is just too much. Therefore we have our own Koji instance, where >>> the deps go in the first place, and then we can work on getting them >>> to Fedora later while development goes on. >>> >>> So what I'm saying is: it would be great if someone clones our repo, >>> runs bundle install and the server runs on every platform (though I >>> don't thing forcing the developer to run all the deps (like Pulp, >>> Candlepin, Katello-Cli) from source would make the Rails developer >>> happy. But giving up our nightly builds and all the good things that >>> go with it just for this reason is really huge step backward. And I >>> don't see a reason that this two things couldn't co-exist together. >>> >>> -- Ivan >> >> I think we need to standardize on whether replies go above or below the >> original comment :) >> In the middle - don't standardize - cos people will then complain. We are all grown adults and can adapt to everyone's habits. >> >> I don't think anybody participating in this thread suggests that >> packaging is not important. Nor is anyone talking about about abandoning >> nightly builds, etc. >> >> I'm suggesting that we remove development process dependency on build >> artifacts. Let's use rubygems.org in development (I know of several >> people who are doing this already; it's *very* useful to be able to add >> new dependencies in development quickly). Let's use system-provided gems >> in packaged Katello. >> > +1 Personal opinion. I'll suggest, if you make a pull request for katello in github, that you have resolved gem packaging/build before submitting a patch/code that requires a new gem. In other words - hack away as you want, but once you want it formally in Katello - clean it up and make it easily consumable for all, wanting to install Katello from nightly rpm based yum repos. If a pull request requires a new(er) gem, then it should be rejected until that gem is packaged and available via rpm in one of the usual repos for katello. Cliff > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mmorsi at redhat.com Thu Oct 18 16:56:24 2012 From: mmorsi at redhat.com (Mo Morsi) Date: Thu, 18 Oct 2012 12:56:24 -0400 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <508022C0.9090405@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> Message-ID: <508034B8.8040606@redhat.com> On 10/18/2012 11:39 AM, Cliff Perry wrote: >>> I think we need to standardize on whether replies go above or below the >>> original comment :) >>> > > In the middle - don't standardize - cos people will then complain. We > are all grown adults and can adapt to everyone's habits. +1, many a flame war has been started over this topic alone :-) > >>> >>> I don't think anybody participating in this thread suggests that >>> packaging is not important. Nor is anyone talking about about >>> abandoning >>> nightly builds, etc. >>> >>> I'm suggesting that we remove development process dependency on build >>> artifacts. Let's use rubygems.org in development (I know of several >>> people who are doing this already; it's *very* useful to be able to add >>> new dependencies in development quickly). Let's use system-provided >>> gems >>> in packaged Katello. >>> >> +1 > > Personal opinion. > > I'll suggest, if you make a pull request for katello in github, that > you have resolved gem packaging/build before submitting a patch/code > that requires a new gem. In other words - hack away as you want, but > once you want it formally in Katello - clean it up and make it easily > consumable for all, wanting to install Katello from nightly rpm based > yum repos. If a pull request requires a new(er) gem, then it should be > rejected until that gem is packaged and available via rpm in one of > the usual repos for katello. > > Cliff I'm in favour of this approach and for the longest time we tried doing this w/ Aeolus. Unfortunately what happend is that when push-came-to-shove (when time is tight), these requirements get dropped in lieu of getting features in. We always ended up w/ the inevitable packaging nightmare during release time. Granted things have been getting better as we've spread packaging around and given that many core dependenices are now in Fedora but there is still work togo. Having the products in Fedora and RHEL is a great selling point IMO, especially to established communities based on those platforms, though I understand these restrictions are hard to enforce / expect of developers, especially with other competing requirements. As with everything there are many aspects to this, technical, organizational, and promotional. I'm still not convinced that we can't do more technically, I'm working on a feature for the http://isitfedoraruby.com site that will allow you to do a mass import of a gem. With a simple click or two, I want to be able to pull an gem and all dependencies, generate spec files for all of those using gem2rpm, and if possible create rpms and a yum repo for immediate consumption. This still doesn't solve the problem of getting everything into Fedora, but getting to that point might present solutions not feasible before. As always any efforts on the Fedora / Ruby platform, whether for our products or just in general to improve things is more than appreciated. You can find more about the sig here: http://fedoraproject.org/wiki/Ruby_SIG -Mo From jomara at redhat.com Thu Oct 18 20:07:23 2012 From: jomara at redhat.com (Jordan OMara) Date: Thu, 18 Oct 2012 16:07:23 -0400 Subject: [katello-devel] informative cli designs Message-ID: <20121018200723.GG46712@redhat.com> In certain situations the CLI does not provide a lot of information to the user. Example: Id : 1 Name : key_one Description: this is a key Usage Limit : unlimited Environment Id : 2 System Template Id : None Pools: [ ff8080813a66136e013a756303420044 ] In the UI, 'pools' shows you quite a bit of information about the pool, not just the Id. Presumably the idea is that the CLI user would make subsequent queries to get info about the pool they wanted. Question 1: Is this the desired use case, or should we provide a 'verbose' flag and allow the user to see nested pool data as well? Question 2: Assuming the answer to question 1 is "yes", is the best way to do this (or at least the accepted katello pattern) to make the Activation Key API return more pool info, or to make the CLI make subsequent calls to get additional pool data? YOUR INPUT IS REQUESTED, -- 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 Thu Oct 18 20:23:25 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 18 Oct 2012 22:23:25 +0200 Subject: [katello-devel] informative cli designs In-Reply-To: <20121018200723.GG46712@redhat.com> References: <20121018200723.GG46712@redhat.com> Message-ID: <5080653D.90102@redhat.com> On 10/18/2012 10:07 PM, Jordan OMara wrote: > In certain situations the CLI does not provide a lot of information to > the user. Example: > > Id : 1 > Name : key_one > Description: > this is a key > Usage Limit : unlimited > Environment Id : 2 > System Template Id : None > Pools: > [ ff8080813a66136e013a756303420044 ] > > In the UI, 'pools' shows you quite a bit of information about the > pool, not just the Id. Presumably the idea is that the CLI user would > make subsequent queries to get info about the pool they wanted. > > Question 1: Is this the desired use case, or should we provide a > 'verbose' flag and allow the user to see nested pool data as well? I guess it makes sense, yes. > > Question 2: Assuming the answer to question 1 is "yes", is the best > way to do this (or at least the accepted katello pattern) to make the > Activation Key API return more pool info, or to make the CLI make > subsequent calls to get additional pool data? Both is probably acceptable I guess, I would vote for the subsequent calls just to avoid the pattern that every CLI change would imply an API change. -- Ivan > > YOUR INPUT IS REQUESTED, > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hbrock at redhat.com Thu Oct 18 20:33:13 2012 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 18 Oct 2012 16:33:13 -0400 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <508022C0.9090405@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> Message-ID: <20121018203256.GB12308@redhat.com> On Thu, Oct 18, 2012 at 04:39:44PM +0100, Cliff Perry wrote: > On 10/18/2012 01:14 PM, Bryan Kearney wrote: > >On 10/18/2012 05:34 AM, Dmitri Dolguikh wrote: > >>On 18/10/12 09:22 AM, Ivan Ne?as wrote: > >>>On 10/17/2012 07:18 PM, Hugh Brock wrote: > >>>>On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote: > >>>>>On 17/10/12 05:04 PM, Jason Rist wrote: > >>>>>>On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: > >>>>>>>As part of port to Ruby 1.9.3, I'd suggest moving away from custom > >>>>>>>ruby > >>>>>>>repository for bundler-based installs, and switch to rubygems.org > >>>>>>>repository instead. Folks still would rather use Fedora-provided > >>>>>>>gems > >>>>>>>can do so, since Fedora 17 versions of 'bundler' and 'gem' are > >>>>>>>yum-aware. This would simplify dependency management during > >>>>>>>development. > >>>>>>> > >>>>>>> > >>>>>>>As the next step I'd like to propose to switch to rails 3.2 (the > >>>>>>>version > >>>>>>>of Rails that's going to be shipped with f18) in master (which is > >>>>>>>what > >>>>>>>Aeolus folks did). > >>>Let's call it Fedora 18 support :) > >>>>>>> > >>>>>>> > >>>>>>>-d > >>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>katello-devel mailing list > >>>>>>>katello-devel at redhat.com > >>>>>>>https://www.redhat.com/mailman/listinfo/katello-devel > >>>>>>I think this is what we should have been doing. Can we not develop > >>>>>>upstream in a more normal rails fashion and then deal with > >>>>>>packaging and > >>>>>>the like downstream? Or is that too much work? > >>>>>> > >>>>>I'm not sure why we aren't doing this atm. Considering that we have > >>>>>a suite of integration tests that is being run *after* katello has > >>>>>been packaged, it's safe to split development and packaging - we are > >>>>>able to catch the issues. > >>>Here are some reasons why we care about RPM packages from the beginning: > >>> > >>>1. Katello as a working thing by far isn't just a Rails app and > >>>outside of the Ruby word gems mean nothing. > >>>2. The installation process is part of the whole project. Using the > >>>installation process that will be used in production from start means > >>>catching the issues sooner than just before release > >>>3. Creating an RPM forces you to thing about the license soon. It's > >>>not pleasant to find out that your code is not shipable because of the > >>>licensing issues > >>>4. The code has to work on the target platform (which is Fedora an > >>>RHEL for us), and (as Metallica sings) nothing else matters > >>>5. Things like selinux need to be solved as well. > >>>6. This approach is Continuous Delivery compliant: and now we are > >>>having 2-months CR release cycle > >>> > >>>You can do whatever you want on the development machine. And I have > >>>nothing against improvements that will make development on non-Fedora > >>>based systems easier. But when you want to merge into the master, you > >>>have to count on the fact that somebody will want to install it on > >>>test or production machine. > >>> > >>>Unlike Aeolus, we don't try to get Katello into Fedora official repos > >>>yet (though our client packages are already there). And getting the > >>>packages to Fedora it the thing that makes the packaging harder and > >>>slows down the process: waiting for 2 weeks till the library can be > >>>used is just too much. Therefore we have our own Koji instance, where > >>>the deps go in the first place, and then we can work on getting them > >>>to Fedora later while development goes on. > >>> > >>>So what I'm saying is: it would be great if someone clones our repo, > >>>runs bundle install and the server runs on every platform (though I > >>>don't thing forcing the developer to run all the deps (like Pulp, > >>>Candlepin, Katello-Cli) from source would make the Rails developer > >>>happy. But giving up our nightly builds and all the good things that > >>>go with it just for this reason is really huge step backward. And I > >>>don't see a reason that this two things couldn't co-exist together. > >>> > >>>-- Ivan > >> > >>I think we need to standardize on whether replies go above or below the > >>original comment :) > >> > > In the middle - don't standardize - cos people will then complain. > We are all grown adults and can adapt to everyone's habits. > > >> > >>I don't think anybody participating in this thread suggests that > >>packaging is not important. Nor is anyone talking about about abandoning > >>nightly builds, etc. > >> > >>I'm suggesting that we remove development process dependency on build > >>artifacts. Let's use rubygems.org in development (I know of several > >>people who are doing this already; it's *very* useful to be able to add > >>new dependencies in development quickly). Let's use system-provided gems > >>in packaged Katello. > >> > >+1 > > Personal opinion. > > I'll suggest, if you make a pull request for katello in github, that > you have resolved gem packaging/build before submitting a patch/code > that requires a new gem. In other words - hack away as you want, but > once you want it formally in Katello - clean it up and make it > easily consumable for all, wanting to install Katello from nightly > rpm based yum repos. If a pull request requires a new(er) gem, then > it should be rejected until that gem is packaged and available via > rpm in one of the usual repos for katello. > We did this for a while with Aeolus. Unfortunately it confuses the hell out of ruby developers who don't know anything about RPM. Imagine for a moment that you are a top-notch rails programmer. Unless you already work at Red Hat, chances are you've never had to write an RPM spec before. Now let's say by some miracle you become interested in contributing to upstream Katello, or Aeolus. You poke around, talk to people, figure out that the feature you want isn't already in progress and that upstream would like to have it. So you go off and write the thing. Along the way you add your friend's handy gem that does XYZ. When you submit your patch upstream, we say, oh, gee, sorry, we don't take patches that add gem dependencies unless you also wrap them up in this arcane packaging format that is redundant (for rubyists) and not the least bit useful to you. I don't think I need to describe what the typical reaction would be... If we ever want any of these projects to fly on their own without 100% support from Red Hat, we have to stop doing things that make them weird to non-RH folks. Like even talking about RPM... or, god help us, Fedora. --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 inecas at redhat.com Thu Oct 18 21:44:35 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 18 Oct 2012 23:44:35 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121018203256.GB12308@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <20121018203256.GB12308@redhat.com> Message-ID: <50807843.3080405@redhat.com> On 10/18/2012 10:33 PM, Hugh Brock wrote: > On Thu, Oct 18, 2012 at 04:39:44PM +0100, Cliff Perry wrote: >> On 10/18/2012 01:14 PM, Bryan Kearney wrote: >>> On 10/18/2012 05:34 AM, Dmitri Dolguikh wrote: >>>> On 18/10/12 09:22 AM, Ivan Ne?as wrote: >>>>> On 10/17/2012 07:18 PM, Hugh Brock wrote: >>>>>> On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote: >>>>>>> On 17/10/12 05:04 PM, Jason Rist wrote: >>>>>>>> On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote: >>>>>>>>> As part of port to Ruby 1.9.3, I'd suggest moving away from custom >>>>>>>>> ruby >>>>>>>>> repository for bundler-based installs, and switch to rubygems.org >>>>>>>>> repository instead. Folks still would rather use Fedora-provided >>>>>>>>> gems >>>>>>>>> can do so, since Fedora 17 versions of 'bundler' and 'gem' are >>>>>>>>> yum-aware. This would simplify dependency management during >>>>>>>>> development. >>>>>>>>> >>>>>>>>> >>>>>>>>> As the next step I'd like to propose to switch to rails 3.2 (the >>>>>>>>> version >>>>>>>>> of Rails that's going to be shipped with f18) in master (which is >>>>>>>>> what >>>>>>>>> Aeolus folks did). >>>>> Let's call it Fedora 18 support :) >>>>>>>>> >>>>>>>>> -d >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> katello-devel mailing list >>>>>>>>> katello-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>>>> I think this is what we should have been doing. Can we not develop >>>>>>>> upstream in a more normal rails fashion and then deal with >>>>>>>> packaging and >>>>>>>> the like downstream? Or is that too much work? >>>>>>>> >>>>>>> I'm not sure why we aren't doing this atm. Considering that we have >>>>>>> a suite of integration tests that is being run *after* katello has >>>>>>> been packaged, it's safe to split development and packaging - we are >>>>>>> able to catch the issues. >>>>> Here are some reasons why we care about RPM packages from the beginning: >>>>> >>>>> 1. Katello as a working thing by far isn't just a Rails app and >>>>> outside of the Ruby word gems mean nothing. >>>>> 2. The installation process is part of the whole project. Using the >>>>> installation process that will be used in production from start means >>>>> catching the issues sooner than just before release >>>>> 3. Creating an RPM forces you to thing about the license soon. It's >>>>> not pleasant to find out that your code is not shipable because of the >>>>> licensing issues >>>>> 4. The code has to work on the target platform (which is Fedora an >>>>> RHEL for us), and (as Metallica sings) nothing else matters >>>>> 5. Things like selinux need to be solved as well. >>>>> 6. This approach is Continuous Delivery compliant: and now we are >>>>> having 2-months CR release cycle >>>>> >>>>> You can do whatever you want on the development machine. And I have >>>>> nothing against improvements that will make development on non-Fedora >>>>> based systems easier. But when you want to merge into the master, you >>>>> have to count on the fact that somebody will want to install it on >>>>> test or production machine. >>>>> >>>>> Unlike Aeolus, we don't try to get Katello into Fedora official repos >>>>> yet (though our client packages are already there). And getting the >>>>> packages to Fedora it the thing that makes the packaging harder and >>>>> slows down the process: waiting for 2 weeks till the library can be >>>>> used is just too much. Therefore we have our own Koji instance, where >>>>> the deps go in the first place, and then we can work on getting them >>>>> to Fedora later while development goes on. >>>>> >>>>> So what I'm saying is: it would be great if someone clones our repo, >>>>> runs bundle install and the server runs on every platform (though I >>>>> don't thing forcing the developer to run all the deps (like Pulp, >>>>> Candlepin, Katello-Cli) from source would make the Rails developer >>>>> happy. But giving up our nightly builds and all the good things that >>>>> go with it just for this reason is really huge step backward. And I >>>>> don't see a reason that this two things couldn't co-exist together. >>>>> >>>>> -- Ivan >>>> I think we need to standardize on whether replies go above or below the >>>> original comment :) >>>> >> In the middle - don't standardize - cos people will then complain. >> We are all grown adults and can adapt to everyone's habits. >> >>>> I don't think anybody participating in this thread suggests that >>>> packaging is not important. Nor is anyone talking about about abandoning >>>> nightly builds, etc. >>>> >>>> I'm suggesting that we remove development process dependency on build >>>> artifacts. Let's use rubygems.org in development (I know of several >>>> people who are doing this already; it's *very* useful to be able to add >>>> new dependencies in development quickly). Let's use system-provided gems >>>> in packaged Katello. >>>> >>> +1 >> Personal opinion. >> >> I'll suggest, if you make a pull request for katello in github, that >> you have resolved gem packaging/build before submitting a patch/code >> that requires a new gem. In other words - hack away as you want, but >> once you want it formally in Katello - clean it up and make it >> easily consumable for all, wanting to install Katello from nightly >> rpm based yum repos. If a pull request requires a new(er) gem, then >> it should be rejected until that gem is packaged and available via >> rpm in one of the usual repos for katello. >> > We did this for a while with Aeolus. Unfortunately it confuses the hell > out of ruby developers who don't know anything about RPM. > > Imagine for a moment that you are a top-notch rails programmer. Unless > you already work at Red Hat, chances are you've never had to write an > RPM spec before. > > Now let's say by some miracle you become interested in contributing to > upstream Katello, or Aeolus. You poke around, talk to people, figure out > that the feature you want isn't already in progress and that upstream > would like to have it. So you go off and write the thing. Along the way > you add your friend's handy gem that does XYZ. > > When you submit your patch upstream, we say, oh, gee, sorry, we don't > take patches that add gem dependencies unless you also wrap them up in > this arcane packaging format that is redundant (for rubyists) and not > the least bit useful to you. > > I don't think I need to describe what the typical reaction would be... > > If we ever want any of these projects to fly on their own without 100% > support from Red Hat, we have to stop doing things that make them weird > to non-RH folks. Like even talking about RPM... or, god help us, > Fedora. I will be really happy to have this kind of issues. And don't get me wrong, I really would like to see Katello supporting other than RPM based platforms. But let's be realistic. For now, this are pure virtual problems: if someone will have a need to send a patch to Katello anytime soon, it will be a user which implies he/she already has an infrastructure of RPM based systems and probably runs Katlello from RPMs as well. There are, on the other side, problems, we are really facing day to day (I've mentioned 6 reasons why we care about RPMs already). If we ever want any support from the non-RPM based world, we first need to prove that we do really cool stuff here (and I believe we do), then provide user support for other distros (deb repos and client tools for start), or be so good that they will do it on their own. And then we can continue in this discussion again. And unless there is a support for rubygems and client tools for Mac OS X, I doubt there will be a Ruby developer interested in Katello but not knowing anything about RPMs or other system-wide packaging solution. -- Ivan > > --Hugh > -- Ivan From jpazdziora at redhat.com Fri Oct 19 07:07:45 2012 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 19 Oct 2012 09:07:45 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121018203256.GB12308@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <20121018203256.GB12308@redhat.com> Message-ID: <20121019070745.GD29835@redhat.com> On Thu, Oct 18, 2012 at 04:33:13PM -0400, Hugh Brock wrote: > > Now let's say by some miracle you become interested in contributing to > upstream Katello, or Aeolus. You poke around, talk to people, figure out > that the feature you want isn't already in progress and that upstream > would like to have it. So you go off and write the thing. Along the way > you add your friend's handy gem that does XYZ. > > When you submit your patch upstream, we say, oh, gee, sorry, we don't > take patches that add gem dependencies unless you also wrap them up in > this arcane packaging format that is redundant (for rubyists) and not > the least bit useful to you. > > I don't think I need to describe what the typical reaction would be... > > If we ever want any of these projects to fly on their own without 100% > support from Red Hat, we have to stop doing things that make them weird > to non-RH folks. Like even talking about RPM... or, god help us, > Fedora. The danger of the approach you describe is that you pull in a dependency into your project which will be hard or impossible to meet in the downstream product, due to licensing or other issues. At the point some unlucky souls will finally get to do the packaging and find out the issues with distributability of said dependency or with incompatibility of other dependencies that are already in the OS, it might already be cemented deep in the project and it will be much harder to workaround or replace. The developer who reviewed and merged the pull request will already be working on something else and not really care about resolving the issue. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat From lzap at redhat.com Fri Oct 19 08:09:07 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 19 Oct 2012 10:09:07 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <508022C0.9090405@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> Message-ID: <20121019080907.GA4986@lzapx.brq.redhat.com> > I'll suggest, if you make a pull request for katello in github, that > you have resolved gem packaging/build before submitting a patch/code > that requires a new gem. In other words - hack away as you want, but > once you want it formally in Katello - clean it up and make it > easily consumable for all, wanting to install Katello from nightly > rpm based yum repos. If a pull request requires a new(er) gem, then > it should be rejected until that gem is packaged and available via > rpm in one of the usual repos for katello. > This is *EXACTLY* I wanted to write today. What Dmitri recommends is okay for me, as long as we define what DEVELOPMENT means. For me, the border line is a git pull request. Once you make it, you need to have an RPM package, working installation, basic sanity tests working. Cliff wrote it right, there's a nice English word for it: HACKING. I need to write right here, right now, that this is **VERY** important for me. Some folks were working so hard to get our nightly running, making all the packages, improving build process and this kind of things. Crossing the line would be step back I am not willing to accept. Having working RPM-based installation is nothing that is blocking something in development, or somewhere else. Therefore let's use rubygems for development, let's use rubygems.org and do what we need to do to make it easier to develop. We are actully doing this already, except we have our own repo not to change gem versions too often. But the work is still considered done, when RPMs are there, installation is tested and all developers and community can check the new feature the very next day reporting bugs, giving us feedback. Splitting our development into phases like hacking and packaging is not what we want to do. I want nightly, every single day. Packaging is sometimes hard task, sometimes there are dependency issues or license issues. Not doing it continuously would be suicide, having all the bugs reported in the packaging phase (perhaps at the end of week/sprint/release sprint). LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From tstrachota at redhat.com Fri Oct 19 08:17:41 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Fri, 19 Oct 2012 10:17:41 +0200 Subject: [katello-devel] informative cli designs In-Reply-To: <5080653D.90102@redhat.com> References: <20121018200723.GG46712@redhat.com> <5080653D.90102@redhat.com> Message-ID: <50810CA5.2080205@redhat.com> On 10/18/2012 10:23 PM, Ivan Ne?as wrote: > On 10/18/2012 10:07 PM, Jordan OMara wrote: >> In certain situations the CLI does not provide a lot of information to >> the user. Example: >> >> Id : 1 >> Name : key_one >> Description: >> this is a key >> Usage Limit : unlimited >> Environment Id : 2 >> System Template Id : None >> Pools: >> [ ff8080813a66136e013a756303420044 ] >> >> In the UI, 'pools' shows you quite a bit of information about the >> pool, not just the Id. Presumably the idea is that the CLI user would >> make subsequent queries to get info about the pool they wanted. >> >> Question 1: Is this the desired use case, or should we provide a >> 'verbose' flag and allow the user to see nested pool data as well? > I guess it makes sense, yes. Since we already have verbose flag, I would go for just adding the nested information. ie. 'pool info' would display all the info by default while 'pool list' would have it hidden. >> >> Question 2: Assuming the answer to question 1 is "yes", is the best >> way to do this (or at least the accepted katello pattern) to make the >> Activation Key API return more pool info, or to make the CLI make >> subsequent calls to get additional pool data? > Both is probably acceptable I guess, I would vote for the subsequent > calls just to avoid the pattern that every CLI change would imply an API > change. +1 T. > > -- Ivan >> >> YOUR INPUT IS REQUESTED, >> >> >> _______________________________________________ >> 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 lzap at redhat.com Fri Oct 19 08:21:23 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 19 Oct 2012 10:21:23 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507ED2D3.7080800@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED2D3.7080800@redhat.com> Message-ID: <20121019082122.GB4986@lzapx.brq.redhat.com> On Wed, Oct 17, 2012 at 08:46:27AM -0700, Michael McCune wrote: > On 10/17/2012 08:37 AM, Dmitri Dolguikh wrote: > >As part of port to Ruby 1.9.3, I'd suggest moving away from custom ruby > >repository for bundler-based installs, and switch to rubygems.org > >repository instead. Folks still would rather use Fedora-provided gems > >can do so, since Fedora 17 versions of 'bundler' and 'gem' are > >yum-aware. This would simplify dependency management during development. > > this sounds appealing, what is the best way to 'try it out' from a > fresh install perspective? I like the idea of getting rid of our gem repo, but lemme ask this. Is there any way of controlling how folks are updating versions in lock files? I mean, we built our gem repo because of "instability" of Gemfile.lock file. Very often someone commited a version bump of something incompatible - bang. I expect this should be much better now since we use review request and we will discuss every single Gemfile change. But in any case, we should take care! > >As the next step I'd like to propose to switch to rails 3.2 (the version > >of Rails that's going to be shipped with f18) in master (which is what > >Aeolus folks did). > > Why not, but I vote for only upgrading Rails and keeping other libraries on oldest versions possible. I mean, not doing "bundle update" for all, but just for Rails and doing this carefully step by step, library after library. Of course, while keeping versions in our spec files in sync. ps - But what I do not agree is splitting up into development phase and packaging phase :-) I sent another reply in the thread. Every single dev can do the split on his own - making "longer" development cycle in his own branch and preparing packages just before the git pull request. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Fri Oct 19 08:39:17 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Fri, 19 Oct 2012 10:39:17 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121018122247.GZ12308@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <20121018122247.GZ12308@redhat.com> Message-ID: <508111B5.2010708@redhat.com> On 10/18/2012 02:22 PM, Hugh Brock wrote: > I see no reason why any of our Ruby projects should follow a different > development mode than this. Because libvirt is one package and Katello consist of 111 packages (counted on RHEL6) and configuring these all together is significant part of our development. -- Miroslav Such? Red Hat Satellite Engineering From msuchy at redhat.com Fri Oct 19 08:58:39 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Fri, 19 Oct 2012 10:58:39 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <508034B8.8040606@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <508034B8.8040606@redhat.com> Message-ID: <5081163F.5040302@redhat.com> On 10/18/2012 06:56 PM, Mo Morsi wrote: > Granted things have been getting better as we've spread packaging around > and given that many core dependenices are now in Fedora but there is > still work togo. Having the products in Fedora and RHEL is a great > selling point IMO Yes, having packages in Fedora is good. Mostly because its guidelines force you to behave properly and to avoid hacks (e.g. candlepin-deps or converge-ui-devel). And there will be *long long way* before katello can get into Fedora (because Pulp, Candlepin and Foreman will have to be there first). -- Miroslav Such? Red Hat Satellite Engineering From msuchy at redhat.com Fri Oct 19 09:04:14 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Fri, 19 Oct 2012 11:04:14 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121017171834.GS12308@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> Message-ID: <5081178E.8080103@redhat.com> On 10/17/2012 07:18 PM, Hugh Brock wrote: > Yes, Aeolus is already doing this and IMO it is the only sane way to > develop upstream. There is a natural split between upstream gem-only and > distro-specific product packaging, let's let it happen. > > This means that some unlucky set of souls from each team is going to > have to deal with the packaging each release, but that's the price we're > going to pay regardless. We'll just rotate the personnel and let > everyone feel the pain equally (this will also help keep a lid on the > inclination to add things to Gemfile willy-nilly). We have already been there in past. That was around Satellite 5.0 times (and before). Ask Cliff, Jesus or Mike how long it took us to properly package it and create functional ISO. It was neither days nor weeks. And I really do want to repeat it. -- Miroslav Such? Red Hat Satellite Engineering From msuchy at redhat.com Fri Oct 19 09:09:52 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Fri, 19 Oct 2012 11:09:52 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507FCD31.4070700@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> Message-ID: <508118E0.60706@redhat.com> On 10/18/2012 11:34 AM, Dmitri Dolguikh wrote: > it's *very* useful to be able to add new dependencies in development quickly And it's *very* easy to add new dependency into katello-thirdparty.git and build it in our Koji. To be specific adding new gem into our repo is one or two hour task. And I really could not see valid excuse for skipping this. -- Miroslav Such? Red Hat Satellite Engineering From msuchy at redhat.com Fri Oct 19 09:14:08 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Fri, 19 Oct 2012 11:14:08 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121018203256.GB12308@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <20121018203256.GB12308@redhat.com> Message-ID: <508119E0.5060402@redhat.com> On 10/18/2012 10:33 PM, Hugh Brock wrote: > Imagine for a moment that you are a top-notch rails programmer. Unless > you already work at Red Hat, chances are you've never had to write an > RPM spec before. The idea that somebody is developing management system of rpm based machines, written for rpm based system and mostly consisting of managing rpm files - and such developer is not aware of rpm internals and did not create rpm spec before, sounds quite funny to me (or sad?). -- Miroslav Such? Red Hat Satellite Engineering From lzap at redhat.com Fri Oct 19 09:23:45 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 19 Oct 2012 11:23:45 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <508034B8.8040606@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <508034B8.8040606@redhat.com> Message-ID: <20121019092344.GD4986@lzapx.brq.redhat.com> > I'm in favour of this approach and for the longest time we tried doing > this w/ Aeolus. Unfortunately what happend is that when > push-came-to-shove (when time is tight), these requirements get dropped > in lieu of getting features in. We always ended up w/ the inevitable > packaging nightmare during release time. > > Granted things have been getting better as we've spread packaging around > and given that many core dependenices are now in Fedora but there is > still work togo. Having the products in Fedora and RHEL is a great > selling point IMO, especially to established communities based on those > platforms, though I understand these restrictions are hard to enforce / > expect of developers, especially with other competing requirements. > > As with everything there are many aspects to this, technical, > organizational, and promotional. I'm still not convinced that we can't > do more technically, I'm working on a feature for the > http://isitfedoraruby.com site that will allow you to do a mass import > of a gem. With a simple click or two, I want to be able to pull an gem > and all dependencies, generate spec files for all of those using > gem2rpm, and if possible create rpms and a yum repo for immediate > consumption. This still doesn't solve the problem of getting everything > into Fedora, but getting to that point might present solutions not > feasible before. > > As always any efforts on the Fedora / Ruby platform, whether for our > products or just in general to improve things is more than appreciated. > You can find more about the sig here: > > http://fedoraproject.org/wiki/Ruby_SIG > Just a technical sidenote - when we say "having an RPM package" that basically mean creating it in our (Katello) repo, so we can have nightly the next day. Then we usually start the process of getting it into Fedora, but this is a separate task, because of obvious reasons. You are apparently one step further - Aeolus is already in Fedora, therefore processes for you guys are slightly different. For us, it's just a check if the package is already in Fedora/EPEL and if not, we can just create a package in our repo while there is separate effort running independently getting all of those into Fedora. Once we get there, our process will be different still. We have our Koji instance, therefore we can live on our own building our packages that would be overriding Fedora packages until version is bumped there. Mirek, correct me if I am wrong, you know the process better. -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Fri Oct 19 09:24:57 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Fri, 19 Oct 2012 11:24:57 +0200 Subject: [katello-devel] informative cli designs In-Reply-To: <20121018200723.GG46712@redhat.com> References: <20121018200723.GG46712@redhat.com> Message-ID: <50811C69.8090607@redhat.com> On 10/18/2012 10:07 PM, Jordan OMara wrote: > > Question 1: Is this the desired use case, or should we provide a > 'verbose' flag and allow the user to see nested pool data as well? > > Question 2: Assuming the answer to question 1 is "yes", is the best > way to do this (or at least the accepted katello pattern) to make the > Activation Key API return more pool info, or to make the CLI make > subsequent calls to get additional pool data? KISS [1] http://en.wikipedia.org/wiki/KISS_principle -- Miroslav Such? Red Hat Satellite Engineering From thomasmckay at redhat.com Fri Oct 19 11:15:48 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 19 Oct 2012 07:15:48 -0400 (EDT) Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <508119E0.5060402@redhat.com> Message-ID: <513399052.10024763.1350645348391.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Miroslav Such?" > To: katello-devel at redhat.com > Sent: Friday, October 19, 2012 5:14:08 AM > Subject: Re: [katello-devel] moving to ruby 1.9.3 > > On 10/18/2012 10:33 PM, Hugh Brock wrote: > > Imagine for a moment that you are a top-notch rails programmer. > > Unless > > you already work at Red Hat, chances are you've never had to write > > an > > RPM spec before. > > The idea that somebody is developing management system of rpm based > machines, written for rpm based system and mostly consisting of > managing > rpm files - and such developer is not aware of rpm internals and did > not > create rpm spec before, sounds quite funny to me (or sad?). > > -- > Miroslav Such? > Red Hat Satellite Engineering > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel +1 All this talk of community developers, etc. is fine and interesting. However, this software is written for RPM based customers. What are there needs? Unless I am mistaken, katello is not a project born out of a vibrant community of Ruby on Rails developers all chomping at the bit to 'bundle install' from rubygems.org. The reality is that there is a very, very simple flow for developing katello: yum install katello-all, katello-configure, git checkout, sym link /usr/share/katello to checkout. If someone wants to develop katello, they probably can do it. And why would they need to install any other gems? No other gems would be allowed into github until it worked with above. Do the work, if you want it in. Otherwise, develop within the framework. And if someone wants to develop a rich katello feature there are ways for that too. Look at ldap_fluff which is a gem that adds active directory support for login. Throw in all the work being done to allow katello to run w/o all the backend services, which will be helpful. Look at foreman which can link in without too much complication (though a lot of work, of course). I'm 100% for easy developer setup. I'm 100% against anything that makes it more difficult to deliver a product that is useful for both Red Hat _customers_ and community _users_. Tough for developers? Tough. From daviddavis at redhat.com Fri Oct 19 12:14:49 2012 From: daviddavis at redhat.com (David Davis) Date: Fri, 19 Oct 2012 08:14:49 -0400 (EDT) Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121019082122.GB4986@lzapx.brq.redhat.com> Message-ID: <741104138.14694178.1350648889886.JavaMail.root@redhat.com> I think using Gemfile.lock is a great idea. It would give us some oversight into gem versions and gem versions changing by way of reviewing pull requests to Katello. Currently, I just upload rails 3.2.8 to our gem repo and break all new development installs of Katello (as rails 3.2.8 matches our Gemfile requirement of '>= 3.0.10' yet it does not work with our project in its current state). There's no review process to our katello-thirdparty git repo and until there is, I think locking down gem versions in the Gemfile.lock is a much better idea. David ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Friday, October 19, 2012 4:21:23 AM > Subject: Re: [katello-devel] moving to ruby 1.9.3 > > On Wed, Oct 17, 2012 at 08:46:27AM -0700, Michael McCune wrote: > > On 10/17/2012 08:37 AM, Dmitri Dolguikh wrote: > > >As part of port to Ruby 1.9.3, I'd suggest moving away from custom > > >ruby > > >repository for bundler-based installs, and switch to rubygems.org > > >repository instead. Folks still would rather use Fedora-provided > > >gems > > >can do so, since Fedora 17 versions of 'bundler' and 'gem' are > > >yum-aware. This would simplify dependency management during > > >development. > > > > this sounds appealing, what is the best way to 'try it out' from a > > fresh install perspective? > > I like the idea of getting rid of our gem repo, but lemme ask this. > Is > there any way of controlling how folks are updating versions in lock > files? > > I mean, we built our gem repo because of "instability" of > Gemfile.lock > file. Very often someone commited a version bump of something > incompatible - bang. > > I expect this should be much better now since we use review request > and > we will discuss every single Gemfile change. But in any case, we > should > take care! > > > >As the next step I'd like to propose to switch to rails 3.2 (the > > >version > > >of Rails that's going to be shipped with f18) in master (which is > > >what > > >Aeolus folks did). > > > > > Why not, but I vote for only upgrading Rails and keeping other > libraries > on oldest versions possible. I mean, not doing "bundle update" for > all, > but just for Rails and doing this carefully step by step, library > after > library. Of course, while keeping versions in our spec files in sync. > > ps - But what I do not agree is splitting up into development phase > and > packaging phase :-) I sent another reply in the thread. Every single > dev can do the split on his own - making "longer" development cycle > in > his own branch and preparing packages just before the git pull > request. > > LZ > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From mpovolny at redhat.com Fri Oct 19 12:25:24 2012 From: mpovolny at redhat.com (Martin Povolny) Date: Fri, 19 Oct 2012 14:25:24 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121018203256.GB12308@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <20121018203256.GB12308@redhat.com> Message-ID: <20121019122523.GA5222@piskot.brq.redhat.com> On Thu, Oct 18, 2012 at 04:33:13PM -0400, Hugh Brock wrote: > We did this for a while with Aeolus. Unfortunately it confuses the hell > out of ruby developers who don't know anything about RPM. > > Imagine for a moment that you are a top-notch rails programmer. Unless > you already work at Red Hat, chances are you've never had to write an > RPM spec before. > > Now let's say by some miracle you become interested in contributing to > upstream Katello, or Aeolus. You poke around, talk to people, figure out > that the feature you want isn't already in progress and that upstream > would like to have it. So you go off and write the thing. Along the way > you add your friend's handy gem that does XYZ. You yourself used so many conditions, that the case is really unrealistic ;-) If someone comes with great code and does not know the RPM stuff I am sure someone will be happy to do the rpm-specific work for him. But that's just placing one more hypothesis on top of another. > > When you submit your patch upstream, we say, oh, gee, sorry, we don't > take patches that add gem dependencies unless you also wrap them up in > this arcane packaging format that is redundant (for rubyists) and not > the least bit useful to you. > > I don't think I need to describe what the typical reaction would be... > > If we ever want any of these projects to fly on their own without 100% > support from Red Hat, we have to stop doing things that make them weird > to non-RH folks. Like even talking about RPM... or, god help us, > Fedora. > I have to say that the reasons for doing RPM builds as a integral part of the development process seem very valid to me. And also valid in the context of Conductor. I would point out 2: Unless you work on the packages all way through the project, there will surely come some very unpleasant surprise when the time comes to release (examples where given in the discussion and also seen in the project history!). If every developer is working in his own setup on his own virtual machine using his very special environment including downloading gems from rubygems and pulls code from github and on the other side the user or customer uses and RPM install on a different distribution and on variety of real hardware, then the gap between the customer and the developer is getting HUGE. I believe that Red Hat has the tools to make the gap as small as possible, and has people with the expertise to use them. Automated package build tools and tool to install nightly build packages to freshly installed distros providing developers access to their new code running in the environment the customer/user will have is the way to close the gap I think. Why not to see the problems the packaging may bring or the user might experience as early in the development process as possible? -- Martin Povolny tel. +420 777714458 From lzap at redhat.com Fri Oct 19 12:25:29 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 19 Oct 2012 14:25:29 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <741104138.14694178.1350648889886.JavaMail.root@redhat.com> References: <20121019082122.GB4986@lzapx.brq.redhat.com> <741104138.14694178.1350648889886.JavaMail.root@redhat.com> Message-ID: <20121019122529.GG4986@lzapx.brq.redhat.com> Well, we have been there :-) Ten months ago we have decided to remove Gemfile.lock from our git. The issue with lock file that time was it was difficult to track changes in it. Since we use github pull requests now, it should be much more easier to keep it fit and refuse any version changes which are not appropriate. It is also necessary to have the ability to run against Ruby 1.8 and Ruby 1.9. Dmitri has a new version of Gemfile that works with both, and we should keep it in this state for a while. It's a good to have ability to run unit tests also on older 1.8 for some time IMHO, because we can be asked to backport some feature onto RHEL6 SE. So, yes, basically this is +1 :-) LZ On Fri, Oct 19, 2012 at 08:14:49AM -0400, David Davis wrote: > I think using Gemfile.lock is a great idea. It would give us some oversight into gem versions and gem versions changing by way of reviewing pull requests to Katello. Currently, I just upload rails 3.2.8 to our gem repo and break all new development installs of Katello (as rails 3.2.8 matches our Gemfile requirement of '>= 3.0.10' yet it does not work with our project in its current state). There's no review process to our katello-thirdparty git repo and until there is, I think locking down gem versions in the Gemfile.lock is a much better idea. > > David > > ----- Original Message ----- > > From: "Lukas Zapletal" > > To: katello-devel at redhat.com > > Sent: Friday, October 19, 2012 4:21:23 AM > > Subject: Re: [katello-devel] moving to ruby 1.9.3 > > > > On Wed, Oct 17, 2012 at 08:46:27AM -0700, Michael McCune wrote: > > > On 10/17/2012 08:37 AM, Dmitri Dolguikh wrote: > > > >As part of port to Ruby 1.9.3, I'd suggest moving away from custom > > > >ruby > > > >repository for bundler-based installs, and switch to rubygems.org > > > >repository instead. Folks still would rather use Fedora-provided > > > >gems > > > >can do so, since Fedora 17 versions of 'bundler' and 'gem' are > > > >yum-aware. This would simplify dependency management during > > > >development. > > > > > > this sounds appealing, what is the best way to 'try it out' from a > > > fresh install perspective? > > > > I like the idea of getting rid of our gem repo, but lemme ask this. > > Is > > there any way of controlling how folks are updating versions in lock > > files? > > > > I mean, we built our gem repo because of "instability" of > > Gemfile.lock > > file. Very often someone commited a version bump of something > > incompatible - bang. > > > > I expect this should be much better now since we use review request > > and > > we will discuss every single Gemfile change. But in any case, we > > should > > take care! > > > > > >As the next step I'd like to propose to switch to rails 3.2 (the > > > >version > > > >of Rails that's going to be shipped with f18) in master (which is > > > >what > > > >Aeolus folks did). > > > > > > > > Why not, but I vote for only upgrading Rails and keeping other > > libraries > > on oldest versions possible. I mean, not doing "bundle update" for > > all, > > but just for Rails and doing this carefully step by step, library > > after > > library. Of course, while keeping versions in our spec files in sync. > > > > ps - But what I do not agree is splitting up into development phase > > and > > packaging phase :-) I sent another reply in the thread. Every single > > dev can do the split on his own - making "longer" development cycle > > in > > his own branch and preparing packages just before the git pull > > request. > > > > LZ > > > > -- > > Later, > > > > Lukas "lzap" Zapletal > > #katello #systemengine > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -- Later, Lukas "lzap" Zapletal #katello #systemengine From bbuckingham at redhat.com Fri Oct 19 12:32:54 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Fri, 19 Oct 2012 08:32:54 -0400 Subject: [katello-devel] 854 - request review of pull request Message-ID: <50814876.4070608@redhat.com> Hi, Can someone look over the pull request below today? (Please, please, please.. :) ). The bug associated with it is a blocker and we need to get any comments addressed and have it merged in prior to Monday. https://github.com/Katello/katello/pull/854 thanks, Brad From inecas at redhat.com Fri Oct 19 13:42:51 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Fri, 19 Oct 2012 15:42:51 +0200 Subject: [katello-devel] Katello.org: the API docs officially available Message-ID: <508158DB.7040409@redhat.com> Hi Fellow Katelloers, We're happy to announce the API documentation is available on our web site [1]. You can also learn more about it in a blog post [2]. And finally, you can see the documentation right for your running instance after installing the katello-api-docs package under `/katello/apidoc` path. [1] - http://www.katello.org/apidoc/ [2] - http://www.katello.org/katello-api-docs-now-available -- Ivan From msuchy at redhat.com Fri Oct 19 14:28:51 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Fri, 19 Oct 2012 16:28:51 +0200 Subject: [katello-devel] Selinux on F17 Message-ID: <508163A3.5020505@redhat.com> The failing selinux on F17 is caused by: https://bugzilla.redhat.com/show_bug.cgi?id=836087 Now waiting for mgrepl. Writing just in case somebody would try to fix it while I'm on PTO next week. -- Miroslav Such? Red Hat Satellite Engineering From msuchy at redhat.com Fri Oct 19 14:35:30 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Fri, 19 Oct 2012 16:35:30 +0200 Subject: [katello-devel] ElasticSearch is failing on F17 Message-ID: <50816532.9030705@redhat.com> SSIA if somebody want to investigate it. -- Miroslav Such? Red Hat Satellite Engineering From msuchy at redhat.com Fri Oct 19 14:36:09 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Fri, 19 Oct 2012 16:36:09 +0200 Subject: [katello-devel] ElasticSearch is failing on F17 In-Reply-To: <50816532.9030705@redhat.com> References: <50816532.9030705@redhat.com> Message-ID: <50816559.9070001@redhat.com> On 10/19/2012 04:35 PM, Miroslav Such? wrote: > SSIA > if somebody want to investigate it. > # /etc/init.d/elasticsearch start Starting elasticsearch: [ OK ] The stack size specified is too small, Specify at least 160k Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- Miroslav Such? Red Hat Satellite Engineering From lzap at redhat.com Fri Oct 19 14:49:38 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 19 Oct 2012 16:49:38 +0200 Subject: [katello-devel] ElasticSearch is failing on F17 In-Reply-To: <50816559.9070001@redhat.com> References: <50816532.9030705@redhat.com> <50816559.9070001@redhat.com> Message-ID: <20121019144938.GR4986@lzapx.brq.redhat.com> What do you have in /etc/sysconfig/elasticsearch? LZ On Fri, Oct 19, 2012 at 04:36:09PM +0200, Miroslav Suchy wrote: > On 10/19/2012 04:35 PM, Miroslav Such? wrote: > >SSIA > >if somebody want to investigate it. > > > # /etc/init.d/elasticsearch start > Starting elasticsearch: [ OK ] > The stack size specified is too small, Specify at least 160k > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > > -- > Miroslav Such? > Red Hat Satellite Engineering > > _______________________________________________ > 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 Fri Oct 19 14:58:32 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 19 Oct 2012 10:58:32 -0400 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <508119E0.5060402@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <20121018203256.GB12308@redhat.com> <508119E0.5060402@redhat.com> Message-ID: <50816A98.206@redhat.com> On 10/19/2012 05:14 AM, Miroslav Such? wrote: > On 10/18/2012 10:33 PM, Hugh Brock wrote: >> Imagine for a moment that you are a top-notch rails programmer. Unless >> you already work at Red Hat, chances are you've never had to write an >> RPM spec before. > > The idea that somebody is developing management system of rpm based > machines, written for rpm based system and mostly consisting of managing > rpm files - and such developer is not aware of rpm internals and did not > create rpm spec before, sounds quite funny to me (or sad?). > I would hope at some point we support non rpm deployments. I know Foreman supports Debian. if we get pulp to support .debs then the model should work, yes? -- bk From dmitri at redhat.com Fri Oct 19 15:21:17 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 19 Oct 2012 16:21:17 +0100 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121019080907.GA4986@lzapx.brq.redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <20121019080907.GA4986@lzapx.brq.redhat.com> Message-ID: <50816FED.1080008@redhat.com> On 19/10/12 09:09 AM, Lukas Zapletal wrote: >> I'll suggest, if you make a pull request for katello in github, that >> you have resolved gem packaging/build before submitting a patch/code >> that requires a new gem. In other words - hack away as you want, but >> once you want it formally in Katello - clean it up and make it >> easily consumable for all, wanting to install Katello from nightly >> rpm based yum repos. If a pull request requires a new(er) gem, then >> it should be rejected until that gem is packaged and available via >> rpm in one of the usual repos for katello. >> > This is *EXACTLY* I wanted to write today. > > What Dmitri recommends is okay for me, as long as we define what > DEVELOPMENT means. For me, the border line is a git pull request. Once > you make it, you need to have an RPM package, working installation, > basic sanity tests working. > > Cliff wrote it right, there's a nice English word for it: HACKING. > > I need to write right here, right now, that this is **VERY** important > for me. Some folks were working so hard to get our nightly running, > making all the packages, improving build process and this kind of > things. Crossing the line would be step back I am not willing to accept. > Having working RPM-based installation is nothing that is blocking > something in development, or somewhere else. > > Therefore let's use rubygems for development, let's use rubygems.org and > do what we need to do to make it easier to develop. We are actully doing > this already, except we have our own repo not to change gem versions too > often. But the work is still considered done, when RPMs are there, > installation is tested and all developers and community can check the > new feature the very next day reporting bugs, giving us feedback. > > Splitting our development into phases like hacking and packaging is not > what we want to do. I want nightly, every single day. Packaging is > sometimes hard task, sometimes there are dependency issues or license > issues. Not doing it continuously would be suicide, having all the bugs > reported in the packaging phase (perhaps at the end of > week/sprint/release sprint). > > LZ > The current build process is hinged upon the idea of building for one platform (currently f16/rhel 6.x, going to be f17). I know that I'd like to have f18 packages (so folks don't need to wait 6 months for us to catch up). There's also non-rpm-based linux distributions. It's because of this zoo the packaging *has* to be a separate stage. A build per platform, with platform-specific dependencies, a separate test run, etc. Separate, however, doesn't mean second-class. I'll wholeheartedly support the notion that broken package is just as important to fix as broken tests. -d From hbrock at redhat.com Fri Oct 19 17:05:55 2012 From: hbrock at redhat.com (Hugh Brock) Date: Fri, 19 Oct 2012 13:05:55 -0400 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121019122529.GG4986@lzapx.brq.redhat.com> References: <20121019082122.GB4986@lzapx.brq.redhat.com> <741104138.14694178.1350648889886.JavaMail.root@redhat.com> <20121019122529.GG4986@lzapx.brq.redhat.com> Message-ID: <20121019170555.GE12308@redhat.com> On Fri, Oct 19, 2012 at 02:25:29PM +0200, Lukas Zapletal wrote: > Well, we have been there :-) > > Ten months ago we have decided to remove Gemfile.lock from our git. > > The issue with lock file that time was it was difficult to track changes > in it. Since we use github pull requests now, it should be much more > easier to keep it fit and refuse any version changes which are not > appropriate. > > It is also necessary to have the ability to run against Ruby 1.8 and > Ruby 1.9. Dmitri has a new version of Gemfile that works with both, and > we should keep it in this state for a while. It's a good to have ability > to run unit tests also on older 1.8 for some time IMHO, because we can > be asked to backport some feature onto RHEL6 SE. > > So, yes, basically this is +1 :-) > > LZ Also be careful: if you have Gemfile.lock in source control, which I think is a good idea for the record, but you also have system gem/rpms installed, the actual gemset you are running may become unpredictable. We have two modes for Aeolus: 1. Use only userspace gems, keep Gemfile.lock in place, ignore system gems; 2. Use system gems, move Gemfile.lock to Gemfile.lock.in, pass flag to Bundler to tell it to prefer system gems. You have to have the second mode to test the RPM version of the project. For everyday development we mostly use the first mode though. --Hugh > > On Fri, Oct 19, 2012 at 08:14:49AM -0400, David Davis wrote: > > I think using Gemfile.lock is a great idea. It would give us some oversight into gem versions and gem versions changing by way of reviewing pull requests to Katello. Currently, I just upload rails 3.2.8 to our gem repo and break all new development installs of Katello (as rails 3.2.8 matches our Gemfile requirement of '>= 3.0.10' yet it does not work with our project in its current state). There's no review process to our katello-thirdparty git repo and until there is, I think locking down gem versions in the Gemfile.lock is a much better idea. > > > > David > > > > ----- Original Message ----- > > > From: "Lukas Zapletal" > > > To: katello-devel at redhat.com > > > Sent: Friday, October 19, 2012 4:21:23 AM > > > Subject: Re: [katello-devel] moving to ruby 1.9.3 > > > > > > On Wed, Oct 17, 2012 at 08:46:27AM -0700, Michael McCune wrote: > > > > On 10/17/2012 08:37 AM, Dmitri Dolguikh wrote: > > > > >As part of port to Ruby 1.9.3, I'd suggest moving away from custom > > > > >ruby > > > > >repository for bundler-based installs, and switch to rubygems.org > > > > >repository instead. Folks still would rather use Fedora-provided > > > > >gems > > > > >can do so, since Fedora 17 versions of 'bundler' and 'gem' are > > > > >yum-aware. This would simplify dependency management during > > > > >development. > > > > > > > > this sounds appealing, what is the best way to 'try it out' from a > > > > fresh install perspective? > > > > > > I like the idea of getting rid of our gem repo, but lemme ask this. > > > Is > > > there any way of controlling how folks are updating versions in lock > > > files? > > > > > > I mean, we built our gem repo because of "instability" of > > > Gemfile.lock > > > file. Very often someone commited a version bump of something > > > incompatible - bang. > > > > > > I expect this should be much better now since we use review request > > > and > > > we will discuss every single Gemfile change. But in any case, we > > > should > > > take care! > > > > > > > >As the next step I'd like to propose to switch to rails 3.2 (the > > > > >version > > > > >of Rails that's going to be shipped with f18) in master (which is > > > > >what > > > > >Aeolus folks did). > > > > > > > > > > > Why not, but I vote for only upgrading Rails and keeping other > > > libraries > > > on oldest versions possible. I mean, not doing "bundle update" for > > > all, > > > but just for Rails and doing this carefully step by step, library > > > after > > > library. Of course, while keeping versions in our spec files in sync. > > > > > > ps - But what I do not agree is splitting up into development phase > > > and > > > packaging phase :-) I sent another reply in the thread. Every single > > > dev can do the split on his own - making "longer" development cycle > > > in > > > his own branch and preparing packages just before the git pull > > > request. > > > > > > LZ > > > > > > -- > > > Later, > > > > > > Lukas "lzap" Zapletal > > > #katello #systemengine > > > > > > _______________________________________________ > > > 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 -- == 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 Fri Oct 19 17:08:14 2012 From: hbrock at redhat.com (Hugh Brock) Date: Fri, 19 Oct 2012 13:08:14 -0400 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <513399052.10024763.1350645348391.JavaMail.root@redhat.com> References: <508119E0.5060402@redhat.com> <513399052.10024763.1350645348391.JavaMail.root@redhat.com> Message-ID: <20121019170814.GF12308@redhat.com> On Fri, Oct 19, 2012 at 07:15:48AM -0400, Tom McKay wrote: > > > ----- Original Message ----- > > From: "Miroslav Such?" > > To: katello-devel at redhat.com > > Sent: Friday, October 19, 2012 5:14:08 AM > > Subject: Re: [katello-devel] moving to ruby 1.9.3 > > > > On 10/18/2012 10:33 PM, Hugh Brock wrote: > > > Imagine for a moment that you are a top-notch rails programmer. > > > Unless > > > you already work at Red Hat, chances are you've never had to write > > > an > > > RPM spec before. > > > > The idea that somebody is developing management system of rpm based > > machines, written for rpm based system and mostly consisting of > > managing > > rpm files - and such developer is not aware of rpm internals and did > > not > > create rpm spec before, sounds quite funny to me (or sad?). > > > > -- > > Miroslav Such? > > Red Hat Satellite Engineering > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > +1 > > All this talk of community developers, etc. is fine and interesting. However, this software is written for RPM based customers. What are there needs? Unless I am mistaken, katello is not a project born out of a vibrant community of Ruby on Rails developers all chomping at the bit to 'bundle install' from rubygems.org. > > The reality is that there is a very, very simple flow for developing katello: yum install katello-all, katello-configure, git checkout, sym link /usr/share/katello to checkout. If someone wants to develop katello, they probably can do it. And why would they need to install any other gems? No other gems would be allowed into github until it worked with above. Do the work, if you want it in. Otherwise, develop within the framework. > > And if someone wants to develop a rich katello feature there are ways for that too. Look at ldap_fluff which is a gem that adds active directory support for login. Throw in all the work being done to allow katello to run w/o all the backend services, which will be helpful. Look at foreman which can link in without too much complication (though a lot of work, of course). > > I'm 100% for easy developer setup. I'm 100% against anything that makes it more difficult to deliver a product that is useful for both Red Hat _customers_ and community _users_. Tough for developers? Tough. > > If you don't care about upstream, why bother to have the source open at all? Think of the trouble you'd save yourselves. I'm not kidding... --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 inecas at redhat.com Fri Oct 19 17:12:14 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Fri, 19 Oct 2012 19:12:14 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121019170555.GE12308@redhat.com> References: <20121019082122.GB4986@lzapx.brq.redhat.com> <741104138.14694178.1350648889886.JavaMail.root@redhat.com> <20121019122529.GG4986@lzapx.brq.redhat.com> <20121019170555.GE12308@redhat.com> Message-ID: <508189EE.2080506@redhat.com> On 10/19/2012 07:05 PM, Hugh Brock wrote: > On Fri, Oct 19, 2012 at 02:25:29PM +0200, Lukas Zapletal wrote: >> Well, we have been there :-) >> >> Ten months ago we have decided to remove Gemfile.lock from our git. >> >> The issue with lock file that time was it was difficult to track changes >> in it. Since we use github pull requests now, it should be much more >> easier to keep it fit and refuse any version changes which are not >> appropriate. >> >> It is also necessary to have the ability to run against Ruby 1.8 and >> Ruby 1.9. Dmitri has a new version of Gemfile that works with both, and >> we should keep it in this state for a while. It's a good to have ability >> to run unit tests also on older 1.8 for some time IMHO, because we can >> be asked to backport some feature onto RHEL6 SE. >> >> So, yes, basically this is +1 :-) >> >> LZ > Also be careful: if you have Gemfile.lock in source control, which I > think is a good idea for the record, but you also have system gem/rpms > installed, the actual gemset you are running may become > unpredictable. We have two modes for Aeolus: > > 1. Use only userspace gems, keep Gemfile.lock in place, ignore system > gems; > 2. Use system gems, move Gemfile.lock to Gemfile.lock.in, pass flag to > Bundler to tell it to prefer system gems. Yop, the Gemfile.lock should not get into "binary" RPM at all. But yes, it's easier to have the file there and delete if needed (like when you want to use your system packages instead your custom installation), then not having the file and well? not having it :) -- Ivan > > You have to have the second mode to test the RPM version of the > project. For everyday development we mostly use the first mode though. > > --Hugh > >> On Fri, Oct 19, 2012 at 08:14:49AM -0400, David Davis wrote: >>> I think using Gemfile.lock is a great idea. It would give us some oversight into gem versions and gem versions changing by way of reviewing pull requests to Katello. Currently, I just upload rails 3.2.8 to our gem repo and break all new development installs of Katello (as rails 3.2.8 matches our Gemfile requirement of '>= 3.0.10' yet it does not work with our project in its current state). There's no review process to our katello-thirdparty git repo and until there is, I think locking down gem versions in the Gemfile.lock is a much better idea. >>> >>> David >>> >>> ----- Original Message ----- >>>> From: "Lukas Zapletal" >>>> To: katello-devel at redhat.com >>>> Sent: Friday, October 19, 2012 4:21:23 AM >>>> Subject: Re: [katello-devel] moving to ruby 1.9.3 >>>> >>>> On Wed, Oct 17, 2012 at 08:46:27AM -0700, Michael McCune wrote: >>>>> On 10/17/2012 08:37 AM, Dmitri Dolguikh wrote: >>>>>> As part of port to Ruby 1.9.3, I'd suggest moving away from custom >>>>>> ruby >>>>>> repository for bundler-based installs, and switch to rubygems.org >>>>>> repository instead. Folks still would rather use Fedora-provided >>>>>> gems >>>>>> can do so, since Fedora 17 versions of 'bundler' and 'gem' are >>>>>> yum-aware. This would simplify dependency management during >>>>>> development. >>>>> this sounds appealing, what is the best way to 'try it out' from a >>>>> fresh install perspective? >>>> I like the idea of getting rid of our gem repo, but lemme ask this. >>>> Is >>>> there any way of controlling how folks are updating versions in lock >>>> files? >>>> >>>> I mean, we built our gem repo because of "instability" of >>>> Gemfile.lock >>>> file. Very often someone commited a version bump of something >>>> incompatible - bang. >>>> >>>> I expect this should be much better now since we use review request >>>> and >>>> we will discuss every single Gemfile change. But in any case, we >>>> should >>>> take care! >>>> >>>>>> As the next step I'd like to propose to switch to rails 3.2 (the >>>>>> version >>>>>> of Rails that's going to be shipped with f18) in master (which is >>>>>> what >>>>>> Aeolus folks did). >>>>>> >>>> Why not, but I vote for only upgrading Rails and keeping other >>>> libraries >>>> on oldest versions possible. I mean, not doing "bundle update" for >>>> all, >>>> but just for Rails and doing this carefully step by step, library >>>> after >>>> library. Of course, while keeping versions in our spec files in sync. >>>> >>>> ps - But what I do not agree is splitting up into development phase >>>> and >>>> packaging phase :-) I sent another reply in the thread. Every single >>>> dev can do the split on his own - making "longer" development cycle >>>> in >>>> his own branch and preparing packages just before the git pull >>>> request. >>>> >>>> LZ >>>> >>>> -- >>>> Later, >>>> >>>> Lukas "lzap" Zapletal >>>> #katello #systemengine >>>> >>>> _______________________________________________ >>>> 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 -- Ivan From hbrock at redhat.com Fri Oct 19 17:14:45 2012 From: hbrock at redhat.com (Hugh Brock) Date: Fri, 19 Oct 2012 13:14:45 -0400 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121019122523.GA5222@piskot.brq.redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <20121018203256.GB12308@redhat.com> <20121019122523.GA5222@piskot.brq.redhat.com> Message-ID: <20121019171444.GG12308@redhat.com> On Fri, Oct 19, 2012 at 02:25:24PM +0200, Martin Povolny wrote: > On Thu, Oct 18, 2012 at 04:33:13PM -0400, Hugh Brock wrote: > > We did this for a while with Aeolus. Unfortunately it confuses the hell > > out of ruby developers who don't know anything about RPM. > > > > Imagine for a moment that you are a top-notch rails programmer. Unless > > you already work at Red Hat, chances are you've never had to write an > > RPM spec before. > > > > Now let's say by some miracle you become interested in contributing to > > upstream Katello, or Aeolus. You poke around, talk to people, figure out > > that the feature you want isn't already in progress and that upstream > > would like to have it. So you go off and write the thing. Along the way > > you add your friend's handy gem that does XYZ. > > You yourself used so many conditions, that the case is really unrealistic > ;-) > > If someone comes with great code and does not know the RPM stuff I am > sure someone will be happy to do the rpm-specific work for him. > > But that's just placing one more hypothesis on top of another. I completely disagree. I have *lost good ruby developers* because they thought our obsession with packaging was crazy. This is not a made-up case. > > > > When you submit your patch upstream, we say, oh, gee, sorry, we don't > > take patches that add gem dependencies unless you also wrap them up in > > this arcane packaging format that is redundant (for rubyists) and not > > the least bit useful to you. > > > > I don't think I need to describe what the typical reaction would be... > > > > If we ever want any of these projects to fly on their own without 100% > > support from Red Hat, we have to stop doing things that make them weird > > to non-RH folks. Like even talking about RPM... or, god help us, > > Fedora. > > > > I have to say that the reasons for doing RPM builds as a integral part of > the development process seem very valid to me. And also valid in the > context of Conductor. > > I would point out 2: > > Unless you work on the packages all way through the project, there will > surely come some very unpleasant surprise when the time comes to release > (examples where given in the discussion and also seen in the project > history!). We've been through this, and frankly we overstate the problem. Yes, packaging involves pain. Yes, sometimes you add gems that cause problems later. But why does the review of "I want to have this gem" have to involve "Go package this thing as an RPM"? We can, and should, carefully review gems that we add to the project to make sure that they are licensed correctly and that the code is reasonable. No decent Ruby developer would argue with that. This does *not* mean that we have to then force people to deal with re-packaging those things as RPMs. That is a *productization* task and it should be handled by a *productization* team. > If every developer is working in his own setup on his own virtual > machine using his very special environment including downloading gems > from rubygems and pulls code from github and on the other side the user > or customer uses and RPM install on a different distribution and on > variety of real hardware, then the gap between the customer and the developer > is getting HUGE. > > I believe that Red Hat has the tools to make the gap as small as > possible, and has people with the expertise to use them. Yes. In the productization phase, we have that. It is part of the expense we bear when we're dealing with rolling stuff up and hardening it. It does not need to happen upstream. > Automated package build tools and tool to install nightly build packages > to freshly installed distros providing developers access to their new > code running in the environment the customer/user will have is the way to > close the gap I think. > > Why not to see the problems the packaging may bring or the user might > experience as early in the development process as possible? Because it pollutes the upstream development process and makes it completely foreign to non-Red Hat developers. Building community is hard enough without putting roadblocks in the way. --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 Fri Oct 19 18:39:19 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 19 Oct 2012 14:39:19 -0400 Subject: [katello-devel] informative cli designs In-Reply-To: <20121018200723.GG46712@redhat.com> References: <20121018200723.GG46712@redhat.com> Message-ID: <50819E57.6000501@redhat.com> On 10/18/2012 04:07 PM, Jordan OMara wrote: > In certain situations the CLI does not provide a lot of information to > the user. Example: > > Id : 1 > Name : key_one > Description: > this is a key > Usage Limit : unlimited > Environment Id : 2 > System Template Id : None > Pools: > [ ff8080813a66136e013a756303420044 ] > > In the UI, 'pools' shows you quite a bit of information about the > pool, not just the Id. Presumably the idea is that the CLI user would > make subsequent queries to get info about the pool they wanted. > > Question 1: Is this the desired use case, or should we provide a > 'verbose' flag and allow the user to see nested pool data as well? The other classes have verbose apis. I could see adding pool id and name, so that you can query against it later. > > Question 2: Assuming the answer to question 1 is "yes", is the best > way to do this (or at least the accepted katello pattern) to make the > Activation Key API return more pool info, or to make the CLI make > subsequent calls to get additional pool data? > > YOUR INPUT IS REQUESTED, I like the atomic nature of the api calls, since it does make the simpler. I would suggest we attack it this way: if there is a task you need to do, what is the cli not supporting. -- bk From lzap at redhat.com Fri Oct 19 19:11:45 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 19 Oct 2012 21:11:45 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <50816FED.1080008@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <20121019080907.GA4986@lzapx.brq.redhat.com> <50816FED.1080008@redhat.com> Message-ID: <20121019191145.GT4986@lzapx.brq.redhat.com> On Fri, Oct 19, 2012 at 04:21:17PM +0100, Dmitri Dolguikh wrote: > It's because of this zoo the packaging *has* to be a separate stage. > A build per platform, with platform-specific dependencies, a > separate test run, etc. Separate, however, doesn't mean > second-class. I'll wholeheartedly support the notion that broken > package is just as important to fix as broken tests. > > Depends on what you mean by separate stage. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Sat Oct 20 18:28:48 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Sat, 20 Oct 2012 20:28:48 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <50816A98.206@redhat.com> References: <507ED0B2.2020503@redhat.com> <507ED728.90505@redhat.com> <507EDA7D.6090308@redhat.com> <20121017171834.GS12308@redhat.com> <507FBC40.9060509@redhat.com> <507FCD31.4070700@redhat.com> <507FF2B2.8070004@redhat.com> <508022C0.9090405@redhat.com> <20121018203256.GB12308@redhat.com> <508119E0.5060402@redhat.com> <50816A98.206@redhat.com> Message-ID: <5082ED60.7050204@redhat.com> On 10/19/2012 04:58 PM, Bryan Kearney wrote: >> The idea that somebody is developing management system of rpm based >> machines, written for rpm based system and mostly consisting of managing >> rpm files - and such developer is not aware of rpm internals and did not >> create rpm spec before, sounds quite funny to me (or sad?). >> > I would hope at some point we support non rpm deployments. I know > Foreman supports Debian. if we get pulp to support .debs then the model > should work, yes? So it will then flip to: Somebody is developing management system of rpm and deb and knows nothing about packaging rpm and/or deb. It still sounds sarcastic to me. -- Miroslav Such? Red Hat Satellite Engineering From jpazdziora at redhat.com Mon Oct 22 06:40:55 2012 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 22 Oct 2012 08:40:55 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121019170814.GF12308@redhat.com> References: <508119E0.5060402@redhat.com> <513399052.10024763.1350645348391.JavaMail.root@redhat.com> <20121019170814.GF12308@redhat.com> Message-ID: <20121022064055.GH15074@redhat.com> On Fri, Oct 19, 2012 at 01:08:14PM -0400, Hugh Brock wrote: > > If you don't care about upstream, why bother to have the source open at > all? Think of the trouble you'd save yourselves. Noone said they did not care about upstream. People claimed that they prefer to focus on making upstream's *users'* lives easier by packaging nightly properly. Which sounds very sane because if the user does not get across the installation and setup steps of the project, you've lost both user and potential developer. Especially in the system management realm where your target users are system administrators, they have generally standardized on packaging, and it's the packaging native to the OS because it brings significant advantages -- you can check signatures, you can verify your software, etc. Noone claims that the rock star ruby developer who hated OS-native packaging has to be the person who does the .spec hacking and licence due diligence -- anybody from the team can help them or do the work for them. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat From lzap at redhat.com Mon Oct 22 07:58:16 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 22 Oct 2012 09:58:16 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121019170555.GE12308@redhat.com> References: <20121019082122.GB4986@lzapx.brq.redhat.com> <741104138.14694178.1350648889886.JavaMail.root@redhat.com> <20121019122529.GG4986@lzapx.brq.redhat.com> <20121019170555.GE12308@redhat.com> Message-ID: <20121022075816.GB4946@lzapx.brq.redhat.com> > Also be careful: if you have Gemfile.lock in source control, which I > think is a good idea for the record, but you also have system gem/rpms > installed, the actual gemset you are running may become > unpredictable. We have two modes for Aeolus: > > 1. Use only userspace gems, keep Gemfile.lock in place, ignore system > gems; > 2. Use system gems, move Gemfile.lock to Gemfile.lock.in, pass flag to > Bundler to tell it to prefer system gems. > > You have to have the second mode to test the RPM version of the > project. For everyday development we mostly use the first mode though. > Yeah, that's the plan. There is also a third possibility which Foreman makes use: 3. Do not distribute Gemfile.lock in the rpm and have a post-transaction section which creates it with "bundle install --local". But if there are any gems installed by user (gem install command), they could be used and I think even in this case we should patch bundler to use only systems gems. >From this three options I like number 2 the most. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Mon Oct 22 08:34:19 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 22 Oct 2012 10:34:19 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <507ED0B2.2020503@redhat.com> References: <507ED0B2.2020503@redhat.com> Message-ID: <20121022083419.GC4946@lzapx.brq.redhat.com> Guys, I think this discussion is out of the track after Jason requested to develop more "Ruby" way. I already replied several times to that thread in a sense it is not good idea. But let me put this back on track. Dmitri has new version of Gemfile that works both with Ruby 1.8 and 1.9 AND it also uses rubygems.org instead of our repo. I am currently testing it on Fedora and RHEL. I think we can try to merge this change into the master - this is easy to revert (one file to be deleted). Therefore I vote for pushing this into the master for an evaluation period. LZ On Wed, Oct 17, 2012 at 04:37:22PM +0100, Dmitri Dolguikh wrote: > As part of port to Ruby 1.9.3, I'd suggest moving away from custom > ruby repository for bundler-based installs, and switch to > rubygems.org repository instead. Folks still would rather use > Fedora-provided gems can do so, since Fedora 17 versions of > 'bundler' and 'gem' are yum-aware. This would simplify dependency > management during development. > > > As the next step I'd like to propose to switch to rails 3.2 (the > version of Rails that's going to be shipped with f18) in master > (which is what Aeolus folks did). > > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From ifarkas at redhat.com Mon Oct 22 10:17:20 2012 From: ifarkas at redhat.com (Imre Farkas) Date: Mon, 22 Oct 2012 06:17:20 -0400 (EDT) Subject: [katello-devel] New forms and integration with simple_form Message-ID: <2039429842.3771010.1350901039997.JavaMail.root@redhat.com> The following meeting has been modified: Subject: New forms and integration with simple_form Organizer: "Imre Farkas" Location: "Brno 2 - 3rd floor - Thuridhartindur Room" [MODIFIED] Resources: "Brno 2 - 3rd floor - Thuridhartindur Room" (Site: BRQ, Building: FBCII, Floor: 3, Room: Thuridhartindur) [MODIFIED] Time: Monday, October 22, 2012, 4:00:00 PM - 4:30:00 PM GMT +01:00 Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna Required: jcoufal at redhat.com; katello-devel at redhat.com; aeolus-devel at lists.fedorahosted.org; converge-ui-devel at redhat.com; jcarrill at redhat.com; tzumainn at redhat.com; afitzsim at redhat.com; jrist at redhat.com Optional: jzigmund at redhat.com *~*~*~*~*~*~*~*~*~* Conference Code: 3112661927 Elluminate: https://sas.elluminate.com/m.jnlp?sid=819&password=M.36C2DE4ECF0E2FBF0B156E41D94055 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 4487 bytes Desc: not available URL: From daviddavis at redhat.com Mon Oct 22 11:28:19 2012 From: daviddavis at redhat.com (David Davis) Date: Mon, 22 Oct 2012 07:28:19 -0400 (EDT) Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <20121022083419.GC4946@lzapx.brq.redhat.com> Message-ID: <1065299336.15441306.1350905299218.JavaMail.root@redhat.com> I second that. Thank you Dmitri and Lzap for putting in work to make this happen! David ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Monday, October 22, 2012 4:34:19 AM > Subject: Re: [katello-devel] moving to ruby 1.9.3 > > Guys, > > I think this discussion is out of the track after Jason requested to > develop more "Ruby" way. I already replied several times to that > thread > in a sense it is not good idea. But let me put this back on track. > > Dmitri has new version of Gemfile that works both with Ruby 1.8 and > 1.9 > AND it also uses rubygems.org instead of our repo. I am currently > testing it on Fedora and RHEL. > > I think we can try to merge this change into the master - this is > easy > to revert (one file to be deleted). Therefore I vote for pushing this > into the master for an evaluation period. > > LZ > > On Wed, Oct 17, 2012 at 04:37:22PM +0100, Dmitri Dolguikh wrote: > > As part of port to Ruby 1.9.3, I'd suggest moving away from custom > > ruby repository for bundler-based installs, and switch to > > rubygems.org repository instead. Folks still would rather use > > Fedora-provided gems can do so, since Fedora 17 versions of > > 'bundler' and 'gem' are yum-aware. This would simplify dependency > > management during development. > > > > > > As the next step I'd like to propose to switch to rails 3.2 (the > > version of Rails that's going to be shipped with f18) in master > > (which is what Aeolus folks did). > > > > > > -d > > > > _______________________________________________ > > 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 lzap at redhat.com Mon Oct 22 12:28:24 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 22 Oct 2012 14:28:24 +0200 Subject: [katello-devel] moving to ruby 1.9.3 In-Reply-To: <1065299336.15441306.1350905299218.JavaMail.root@redhat.com> References: <20121022083419.GC4946@lzapx.brq.redhat.com> <1065299336.15441306.1350905299218.JavaMail.root@redhat.com> Message-ID: <20121022122824.GD4946@lzapx.brq.redhat.com> I have been playing with Dmitri's Gemfile for a while now and I have submitted new pull request minute ago. Please give it a try and test it on your environment. We should support every single setup - pure gems (rbenv/rvm), system and gems mix, only system gems with development pure gems etc. Also on 1.8 and 1.9. Please report any issues in the pull request. If everything is fine, we can eventually merge it later this week. LZ On Mon, Oct 22, 2012 at 07:28:19AM -0400, David Davis wrote: > I second that. Thank you Dmitri and Lzap for putting in work to make this happen! > > David > > ----- Original Message ----- > > From: "Lukas Zapletal" > > To: katello-devel at redhat.com > > Sent: Monday, October 22, 2012 4:34:19 AM > > Subject: Re: [katello-devel] moving to ruby 1.9.3 > > > > Guys, > > > > I think this discussion is out of the track after Jason requested to > > develop more "Ruby" way. I already replied several times to that > > thread > > in a sense it is not good idea. But let me put this back on track. > > > > Dmitri has new version of Gemfile that works both with Ruby 1.8 and > > 1.9 > > AND it also uses rubygems.org instead of our repo. I am currently > > testing it on Fedora and RHEL. > > > > I think we can try to merge this change into the master - this is > > easy > > to revert (one file to be deleted). Therefore I vote for pushing this > > into the master for an evaluation period. > > > > LZ > > > > On Wed, Oct 17, 2012 at 04:37:22PM +0100, Dmitri Dolguikh wrote: > > > As part of port to Ruby 1.9.3, I'd suggest moving away from custom > > > ruby repository for bundler-based installs, and switch to > > > rubygems.org repository instead. Folks still would rather use > > > Fedora-provided gems can do so, since Fedora 17 versions of > > > 'bundler' and 'gem' are yum-aware. This would simplify dependency > > > management during development. > > > > > > > > > As the next step I'd like to propose to switch to rails 3.2 (the > > > version of Rails that's going to be shipped with f18) in master > > > (which is what Aeolus folks did). > > > > > > > > > -d > > > > > > _______________________________________________ > > > 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 > > -- Later, Lukas "lzap" Zapletal #katello #systemengine From jcoufal at redhat.com Mon Oct 22 12:54:37 2012 From: jcoufal at redhat.com (=?UTF-8?B?SmFyb23DrXIgQ291ZmFs?=) Date: Mon, 22 Oct 2012 14:54:37 +0200 Subject: [katello-devel] New forms and integration with simple_form In-Reply-To: <2039429842.3771010.1350901039997.JavaMail.root@redhat.com> References: <2039429842.3771010.1350901039997.JavaMail.root@redhat.com> Message-ID: <5085420D.4000506@redhat.com> This presentation is gonna be about New forms and their integration to our applications (Conductor and Katello). We will introduce all features and show, how to use and implement them easily with Simple Form. Short agenda for this meeting: *Part 1:** **Forms introduction:* - basic introduction - basic structure - element types - features - preview *Part 2:** **Implementation with Simple Form:* - Simple Form overview - Wrapper API - Custom components You are all welcome. -- Jarda -- Jarom?r Coufal Interaction Designer Red Hat Czech s.r.o. Mobile: +420 724 595 508 E-mail: jcoufal at redhat.com IRC: jcoufal at #cloudforms-ui, #aeolus, #brno From lzap at redhat.com Mon Oct 22 13:27:51 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 22 Oct 2012 15:27:51 +0200 Subject: [katello-devel] Katello nightly broken - foreman initialization Message-ID: <20121022132751.GG4946@lzapx.brq.redhat.com> Hey, perhaps due to our Foreman branch merge, nightly does not install. The db seed step fails with: 503 Service Unavailable /usr/lib/ruby/gems/1.8/gems/foreman_api-0.0.7/lib/foreman_api/resources/user.rb:15:in `index' /usr/share/katello/lib/resources/abstract_model.rb:213:in `all' /usr/share/katello/db/seeds.rb:44 Since I have some BZ duties, please anyone interested investigate :-) To reproduce just install nightly. Foreman service is not up during the seed most likely. -- Later, Lukas "lzap" Zapletal #katello #systemengine From jsherril at redhat.com Mon Oct 22 13:36:45 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 22 Oct 2012 09:36:45 -0400 Subject: [katello-devel] ElasticSearch is failing on F17 In-Reply-To: <50816559.9070001@redhat.com> References: <50816532.9030705@redhat.com> <50816559.9070001@redhat.com> Message-ID: <50854BED.30608@redhat.com> On 10/19/2012 10:36 AM, Miroslav Such? wrote: > On 10/19/2012 04:35 PM, Miroslav Such? wrote: >> SSIA >> if somebody want to investigate it. >> > # /etc/init.d/elasticsearch start > Starting elasticsearch: [ OK ] > The stack size specified is too small, Specify at least 160k > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > Our version of elastic search doesn't run on java 1.7. IIRC martin was working on getting the newer version (that does run on 1.7) building from scratch, it was just taking a while. There was a user story on it. -Justin From tkolhar at redhat.com Mon Oct 22 14:20:12 2012 From: tkolhar at redhat.com (Tazim Kolhar) Date: Mon, 22 Oct 2012 10:20:12 -0400 (EDT) Subject: [katello-devel] Query regarding katello-reset-dbs script for headpin Message-ID: <702216376.7664537.1350915612799.JavaMail.root@redhat.com> Hi all, A script katello-reset-dbs is used to erase all the data in candlepin database. As per my knowledge, on successful execution of this script, all the data (organisations, environments,manifests, etc) are erased and complete fresh login is provided . Now, while executing this script a password prompt appears . What should be the ideal password provided to proceed further. or can that field be left blank ? Thanks & Regards, Tazim. From thomasmckay at redhat.com Mon Oct 22 14:48:42 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 22 Oct 2012 10:48:42 -0400 (EDT) Subject: [katello-devel] katello-configure --reset-data vs. katello-reset-dbs Message-ID: <55428861.10785123.1350917322945.JavaMail.root@redhat.com> A reminder that 'katello-configure --reset-data' is the preferred mechanism for resetting data on a katello install. Although 'katello-reset-dbs' still exists in the scripts dir, it would be great to get everyone transitioned over to katello-configure method as the standard. From jrist at redhat.com Mon Oct 22 14:59:46 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 22 Oct 2012 08:59:46 -0600 Subject: [katello-devel] CloudForms Forms Blackboard Collaborate Recording In-Reply-To: <50855E08.4060702@redhat.com> References: <50855E08.4060702@redhat.com> Message-ID: <50855F62.7060303@redhat.com> Session: Converge-UI Forms Type: None Started: Oct 22, 2012 09:43 AM Eastern (EDT, North America/US) Ended: Oct 22, 2012 10:47 AM Eastern (EDT, North America/US) This session was recorded. To view the recording, please click the link below: https://sas.elluminate.com/p.jnlp?psid=2012-10-22.0743.M.E3150799EC2723891DECB287740E81.vcr&sid=819 -J From jcoufal at redhat.com Mon Oct 22 15:29:24 2012 From: jcoufal at redhat.com (=?UTF-8?B?SmFyb23DrXIgQ291ZmFs?=) Date: Mon, 22 Oct 2012 17:29:24 +0200 Subject: [katello-devel] [Converge-ui-devel] New forms and integration with simple_form In-Reply-To: <5085420D.4000506@redhat.com> References: <2039429842.3771010.1350901039997.JavaMail.root@redhat.com> <5085420D.4000506@redhat.com> Message-ID: <50856654.1070105@redhat.com> Here are promised sources for our presentations. If you are experiencing any troubles, feel free to contact us, we will do our best to help you. Introduction to Forms: https://www.aeolusproject.org/redmine/attachments/242/converge-ui_forms_presentation.zip Simple Form: https://www.aeolusproject.org/redmine/attachments/243/SimpleForm.pdf Preview (devel version of converge-ui with latest changes): http://convergeui-jcoufal.rhcloud.com/forms -- Jarda (jcoufal) -- Imre (ifarkas) On 22.10.2012 14:54, Jarom?r Coufal wrote: > This presentation is gonna be about New forms and their integration to > our applications (Conductor and Katello). > > We will introduce all features and show, how to use and implement them > easily with Simple Form. > > Short agenda for this meeting: > > *Part 1:** > **Forms introduction:* > - basic introduction > - basic structure > - element types > - features > - preview > > *Part 2:** > **Implementation with Simple Form:* > - Simple Form overview > - Wrapper API > - Custom components > > You are all welcome. > > -- Jarda > -- Jarom?r Coufal Interaction Designer Red Hat Czech s.r.o. Mobile: +420 724 595 508 E-mail: jcoufal at redhat.com IRC: jcoufal at #cloudforms-ui, #aeolus, #brno From thomasmckay at redhat.com Mon Oct 22 19:01:19 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 22 Oct 2012 15:01:19 -0400 (EDT) Subject: [katello-devel] 'katello-configure --deployment=headpin' fails in foreman Message-ID: <867550230.10895808.1350932479495.JavaMail.root@redhat.com> Here is the katello-configure log: http://pastebin.com/YkhQN4Q1 121022-14:31:26 debug: Automatically imported foreman from foreman into production 121022-14:31:26 Could not find resource 'Class[Foreman]' for relationship on 'Class[Katello::Config]' on node rhel62-headpin Note that headpin does not include any of the foreman pieces and needs to have them all fenced. Where's the broken or missing fence? From bkearney at redhat.com Mon Oct 22 19:22:34 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 22 Oct 2012 15:22:34 -0400 Subject: [katello-devel] Tried to install from https://fedorahosted.org/katello/wiki/DevelopmentSetup Message-ID: <50859CFA.1050901@redhat.com> Some notes. Let me know if I should uddate or add bugs: 1) http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-latest.rpm does not exist. I used the current released one from 1.1 2) I had a /bundler/config sitting around which turned off the development group. I noticed that redcarpet and js-routes were not installed. Would a ruby person have known this? 3) The install instruction talk about port 3000, but I believe that will mean subscription manager will not work. Should we update it to go throuhg httpd? 4) I had to set use_foreman to false or I would get a can not connect error. Should foreman be working? -- bk From inecas at redhat.com Mon Oct 22 19:45:11 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 22 Oct 2012 21:45:11 +0200 Subject: [katello-devel] Tried to install from https://fedorahosted.org/katello/wiki/DevelopmentSetup In-Reply-To: <50859CFA.1050901@redhat.com> References: <50859CFA.1050901@redhat.com> Message-ID: <5085A247.4020009@redhat.com> On 10/22/2012 09:22 PM, Bryan Kearney wrote: > Some notes. Let me know if I should uddate or add bugs: > > 1) > http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-latest.rpm > does not exist. I used the current released one from 1.1 This is the right file I believe http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-1.0.3-1.fc16.noarch.rpm > > 2) I had a /bundler/config sitting around which turned off the > development group. I noticed that redcarpet and js-routes were not > installed. Would a ruby person have known this? I believe it's not right to use the /usr/share/katello for development, what I use is a regular clone of our repo and update the httpd conf to point there. I'm preparing the script that will do that automatically (in fact, i use puppet for that, but it's a bit overkill: a simple script will be better) > > 3) The install instruction talk about port 3000, but I believe that > will mean subscription manager will not work. Should we update it to > go throuhg httpd? It should work if you run webrick + set up rhsm correctly. But I agree letting it go through httpd (assuming you're reusing the katello-configure setup) should be engough > > 4) I had to set use_foreman to false or I would get a can not connect > error. Should foreman be working? > It's still quite fresh merge, something might be broken. what's the message you get? -- Ivan > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From bkearney at redhat.com Mon Oct 22 20:00:54 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 22 Oct 2012 16:00:54 -0400 Subject: [katello-devel] Tried to install from https://fedorahosted.org/katello/wiki/DevelopmentSetup In-Reply-To: <5085A247.4020009@redhat.com> References: <50859CFA.1050901@redhat.com> <5085A247.4020009@redhat.com> Message-ID: <5085A5F6.5030207@redhat.com> On 10/22/2012 03:45 PM, Ivan Ne?as wrote: > On 10/22/2012 09:22 PM, Bryan Kearney wrote: >> Some notes. Let me know if I should uddate or add bugs: >> >> 1) >> http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-latest.rpm >> does not exist. I used the current released one from 1.1 > This is the right file I believe > http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-1.0.3-1.fc16.noarch.rpm > >> >> 2) I had a /bundler/config sitting around which turned off the >> development group. I noticed that redcarpet and js-routes were not >> installed. Would a ruby person have known this? > > I believe it's not right to use the /usr/share/katello for development, > what I use is a regular clone of our repo and update the httpd conf to > point there. I'm preparing the script that will do that automatically > (in fact, i use puppet for that, but it's a bit overkill: a simple > script will be better) > >> >> 3) The install instruction talk about port 3000, but I believe that >> will mean subscription manager will not work. Should we update it to >> go throuhg httpd? > It should work if you run webrick + set up rhsm correctly. But I agree > letting it go through httpd (assuming you're reusing the > katello-configure setup) should be engough >> >> 4) I had to set use_foreman to false or I would get a can not connect >> error. Should foreman be working? I think the issue here is that I installed from 1.1, so there was no foreman oauth done when running katello-configure. So, I am going to switch to re-install from the nightlies and see what I get. - bk From thomasmckay at redhat.com Mon Oct 22 20:39:27 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 22 Oct 2012 16:39:27 -0400 (EDT) Subject: [katello-devel] 'katello-configure --deployment=headpin' fails in foreman In-Reply-To: <867550230.10895808.1350932479495.JavaMail.root@redhat.com> Message-ID: <286223801.11031730.1350938367341.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tom McKay" > To: "katello-devel" > Sent: Monday, October 22, 2012 3:01:19 PM > Subject: [katello-devel] 'katello-configure --deployment=headpin' fails in foreman > > > Here is the katello-configure log: http://pastebin.com/YkhQN4Q1 > > 121022-14:31:26 debug: Automatically imported foreman from foreman > into production > 121022-14:31:26 Could not find resource 'Class[Foreman]' for > relationship on 'Class[Katello::Config]' on node rhel62-headpin > > Note that headpin does not include any of the foreman pieces and > needs to have them all fenced. Where's the broken or missing fence? > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > BK pointed out missing fence in katello/manifests/init.pp. Thanks! From inecas at redhat.com Mon Oct 22 21:25:56 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 22 Oct 2012 23:25:56 +0200 Subject: [katello-devel] Tried to install from https://fedorahosted.org/katello/wiki/DevelopmentSetup In-Reply-To: <5085A5F6.5030207@redhat.com> References: <50859CFA.1050901@redhat.com> <5085A247.4020009@redhat.com> <5085A5F6.5030207@redhat.com> Message-ID: <5085B9E4.9030206@redhat.com> On 10/22/2012 10:00 PM, Bryan Kearney wrote: > On 10/22/2012 03:45 PM, Ivan Ne?as wrote: >> On 10/22/2012 09:22 PM, Bryan Kearney wrote: >>> Some notes. Let me know if I should uddate or add bugs: >>> >>> 1) >>> http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-latest.rpm >>> >>> does not exist. I used the current released one from 1.1 >> This is the right file I believe >> http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-1.0.3-1.fc16.noarch.rpm >> >> >>> >>> 2) I had a /bundler/config sitting around which turned off the >>> development group. I noticed that redcarpet and js-routes were not >>> installed. Would a ruby person have known this? >> >> I believe it's not right to use the /usr/share/katello for development, >> what I use is a regular clone of our repo and update the httpd conf to >> point there. I'm preparing the script that will do that automatically >> (in fact, i use puppet for that, but it's a bit overkill: a simple >> script will be better) >> >>> >>> 3) The install instruction talk about port 3000, but I believe that >>> will mean subscription manager will not work. Should we update it to >>> go throuhg httpd? >> It should work if you run webrick + set up rhsm correctly. But I agree >> letting it go through httpd (assuming you're reusing the >> katello-configure setup) should be engough >>> >>> 4) I had to set use_foreman to false or I would get a can not connect >>> error. Should foreman be working? > > > I think the issue here is that I installed from 1.1, so there was no > foreman oauth done when running katello-configure. So, I am going to > switch to re-install from the nightlies and see what I get. > As I promised, here is the script: https://github.com/Katello/katello/pull/894 I've tested it and it looks it works nice. It also is able to prefer system gems (reusing the Gemfile.lock from the production environment). It would be great if you gave it a shot to see if it works for you. > - bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From daviddavis at redhat.com Mon Oct 22 23:08:20 2012 From: daviddavis at redhat.com (David Davis) Date: Mon, 22 Oct 2012 19:08:20 -0400 (EDT) Subject: [katello-devel] Bootstrapping katello In-Reply-To: <949070052.15903820.1350946647490.JavaMail.root@redhat.com> Message-ID: <1059218714.15904546.1350947300869.JavaMail.root@redhat.com> Typically in Rails and Ruby projects, there's a boostrap rake task that'll take care of setting up the project so you can develop it and/or run it. I figured it might be worthwhile to set up something similar for Katello after some recent problems people have been experiencing. Not only will it appeal to Ruby/Rails developers but it might also make it easier for us to setup development instances of Katello. In addition, I think it might be easier to maintain than the wiki page and we could also allow for custom logic in the boostrap task in order to support different ways of setting up katello. To illustrate this last point, you could have some tasks like: rake bootstrap rake bootstrap:pulpv2 rake bootstrap:sam (and so forth) Anyway, I've worked on a rough draft (http://fpaste.org/HwRc/). The hope is that in order to setup a new project for development, one would just have to run: git clone --recursive git at github.com:daviddavis/katello.git cd katello/src bundle install rake bootstrap Let me know what you all think. Thanks! David From inecas at redhat.com Tue Oct 23 06:15:49 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 23 Oct 2012 08:15:49 +0200 Subject: [katello-devel] Bootstrapping katello In-Reply-To: <1059218714.15904546.1350947300869.JavaMail.root@redhat.com> References: <1059218714.15904546.1350947300869.JavaMail.root@redhat.com> Message-ID: <50863615.5060608@redhat.com> On 10/23/2012 01:08 AM, David Davis wrote: > Typically in Rails and Ruby projects, there's a boostrap rake task that'll take care of setting up the project so you can develop it and/or run it. I figured it might be worthwhile to set up something similar for Katello after some recent problems people have been experiencing. Not only will it appeal to Ruby/Rails developers but it might also make it easier for us to setup development instances of Katello. In addition, I think it might be easier to maintain than the wiki page and we could also allow for custom logic in the boostrap task in order to support different ways of setting up katello. To illustrate this last point, you could have some tasks like: > > rake bootstrap > rake bootstrap:pulpv2 > rake bootstrap:sam > (and so forth) > > Anyway, I've worked on a rough draft (http://fpaste.org/HwRc/). The hope is that in order to setup a new project for development, one would just have to run: > > git clone --recursive git at github.com:daviddavis/katello.git > cd katello/src > bundle install > rake bootstrap > > Let me know what you all think. Thanks! If you don't insist on the rake task, I thing this does what you had in mind https://github.com/Katello/katello/pull/894 . IMO it needs to be run before the bundle install (in fact it's good to run bundle install from the script, making sure the development dependencies are met. This script bases the installation on katello-configure which lets us to have the basic installation on one place and have it maintained (since katello-configure is tested on daily basis) -- Ivan > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From lzap at redhat.com Tue Oct 23 07:35:43 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 23 Oct 2012 09:35:43 +0200 Subject: [katello-devel] [stahnma@puppetlabs.com: Fixing Puppet in Fedora/EPEL] Message-ID: <20121023073543.GE4702@lzapx.brq.redhat.com> To let you know (we rely on Puppet in Katello). LZ ----- Forwarded message from Michael Stahnke ----- Date: Fri, 19 Oct 2012 16:04:24 -0700 From: Michael Stahnke To: epel-devel-list at redhat.com, devel at lists.fedoraproject.org Subject: Fixing Puppet in Fedora/EPEL Puppet in the Fedora/EPEL ecosystem is a bit wonky currently. I'd really like to fix it. Problems: * Fedora 17 (and higher) ships with Ruby 1.9.x and Puppet 2.7.x. 2.7.x is not 100% compatible with 1.9.3. The number of issues in this space continues to grow. * EPEL 5/6 still have Puppet 2.6.x in stable. This version of Puppet isn't maintained any more, other than security fixes. * Puppet 3.0.x is out and is the fully supported branch from Puppet Labs and supports Ruby 1.9.3+ fully. * People wanting to have to Fedora clients (agents) check into a RHEL master have to either replace all Puppet software with items provided by yum.puppetlabs.com or replace Fedora ruby/puppet with the ones from RHEL/EPEL. My proposal would be the following: * Move EPEL 6, Fedora >= 17 to use Puppet 3.0. * Move EPEL 5 to the latest 2.7.x branch. This is the last branch of Puppet that supports Ruby 1.8.5, and works with 3.0 masters. This would cause some backward-incompatible changes as documented here[1]. However, this would provide the longest life of Puppet on RHEL/Fedora ecosystems and allow users of Puppet to continue to develop solutions around it on RHEL/EPEL/Fedora, such as the Red Hat Openstack work. We would obviously want to allow testing for some time before pushing the changes everywhere. Puppet Labs release engineering is more than willing to do a majority of this work to make this happen. [1] http://projects.puppetlabs.com/projects/1/wiki/Release_Notes#Important-Deprecations Michael Stahnke stahnma on freenode Puppet Labs Software Delivery -- devel mailing list devel at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel ----- End forwarded message ----- -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Oct 23 09:00:54 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 23 Oct 2012 11:00:54 +0200 Subject: [katello-devel] Query regarding katello-reset-dbs script for headpin In-Reply-To: <702216376.7664537.1350915612799.JavaMail.root@redhat.com> References: <702216376.7664537.1350915612799.JavaMail.root@redhat.com> Message-ID: <20121023090054.GK4702@lzapx.brq.redhat.com> This tools is for developers only, to fully reset your installation use: katello-configure --answer-file=/etc/katello/katello-configure.conf \ --reset-data=YES --reset-cache=YES Team - can we stop distributing this script in our RPM installations? It confuses people, developers know where to find it (git). Or at least I vote moving this into devel package, I will push a pull request right away. LZ On Mon, Oct 22, 2012 at 10:20:12AM -0400, Tazim Kolhar wrote: > Hi all, > > A script katello-reset-dbs is used to erase all the data in candlepin database. > As per my knowledge, on successful execution of this script, all the data (organisations, environments,manifests, etc) are erased > and complete fresh login is provided . > > Now, while executing this script a password prompt appears . > What should be the ideal password provided to proceed further. > or can that field be left blank ? > > Thanks & Regards, > Tazim. > > _______________________________________________ > 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 Tue Oct 23 09:02:17 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 23 Oct 2012 11:02:17 +0200 Subject: [katello-devel] katello-configure --reset-data vs. katello-reset-dbs In-Reply-To: <55428861.10785123.1350917322945.JavaMail.root@redhat.com> References: <55428861.10785123.1350917322945.JavaMail.root@redhat.com> Message-ID: <20121023090217.GL4702@lzapx.brq.redhat.com> Right, I am pushing a request that is moving this out of katello-common package into katello-devel (which already exists but it does not install yet - Mirek is still packaging some of the devel dependencies). If you must have it, please force installation (does not hurt - it just pulls more devel gems from Fedora/EPEL and drops few additional rake files). LZ On Mon, Oct 22, 2012 at 10:48:42AM -0400, Tom McKay wrote: > A reminder that 'katello-configure --reset-data' is the preferred mechanism for resetting data on a katello install. Although 'katello-reset-dbs' still exists in the scripts dir, it would be great to get everyone transitioned over to katello-configure method as the standard. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From ohadlevy at redhat.com Tue Oct 23 09:30:55 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Tue, 23 Oct 2012 11:30:55 +0200 Subject: [katello-devel] [stahnma@puppetlabs.com: Fixing Puppet in Fedora/EPEL] In-Reply-To: <20121023073543.GE4702@lzapx.brq.redhat.com> References: <20121023073543.GE4702@lzapx.brq.redhat.com> Message-ID: <508663CF.7000600@redhat.com> On 10/23/2012 09:35 AM, Lukas Zapletal wrote: > My proposal would be the following: > * Move EPEL 6, Fedora >= 17 to use Puppet 3.0. I would vote against it, 3.0 is not stable at all, and requires manifest code change (as stated) i would wait until 3.0 is stable before pushing that. > * Move EPEL 5 to the latest 2.7.x branch. This is the last branch of > Puppet that supports Ruby 1.8.5, and works with 3.0 masters. +1 for 2.7.x in both EPEL 5,6 fedora might make sense for puppet 3 (but has the potinial of crashing as clients needs to be equal or older to the master). Ohad From lzap at redhat.com Tue Oct 23 09:34:46 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 23 Oct 2012 11:34:46 +0200 Subject: [katello-devel] Tried to install from https://fedorahosted.org/katello/wiki/DevelopmentSetup In-Reply-To: <50859CFA.1050901@redhat.com> References: <50859CFA.1050901@redhat.com> Message-ID: <20121023093446.GN4702@lzapx.brq.redhat.com> On Mon, Oct 22, 2012 at 03:22:34PM -0400, Bryan Kearney wrote: > Some notes. Let me know if I should uddate or add bugs: > > 1) http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-latest.rpm > does not exist. I used the current released one from 1.1 > Due to change in our infrastructure scripts during Koji transition we no longer create -latest.rpms in the releases. You can find it only in nightly. > 4) I had to set use_foreman to false or I would get a can not > connect error. Should foreman be working? Nightly is currently broken, Foreman does not come up and db seed fails since it cannot create Foreman user there. Me and Marting are looking into it. I will post a warning on the user list. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Oct 23 09:51:56 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 23 Oct 2012 11:51:56 +0200 Subject: [katello-devel] Bootstrapping katello In-Reply-To: <1059218714.15904546.1350947300869.JavaMail.root@redhat.com> References: <949070052.15903820.1350946647490.JavaMail.root@redhat.com> <1059218714.15904546.1350947300869.JavaMail.root@redhat.com> Message-ID: <20121023095156.GQ4702@lzapx.brq.redhat.com> If you make it into the master, please make sure the rake task is NOT distributed in katello-common rpm, but in katello-devel package. See the SPEC file for examples. Btw I provision my instances with snap-guest and simple set of bash scripts which do the same as your bootstrap, but it's more readable and more straightforward :-) https://github.com/lzap/snap-guest (I don't share my shell scripts because they are big mess, but writing one is matter of ten minutes) Guys, if you make it to the master, please document it on the wiki. Preferably make a section or something, because both scripts do similar things. LZ On Mon, Oct 22, 2012 at 07:08:20PM -0400, David Davis wrote: > Typically in Rails and Ruby projects, there's a boostrap rake task that'll take care of setting up the project so you can develop it and/or run it. I figured it might be worthwhile to set up something similar for Katello after some recent problems people have been experiencing. Not only will it appeal to Ruby/Rails developers but it might also make it easier for us to setup development instances of Katello. In addition, I think it might be easier to maintain than the wiki page and we could also allow for custom logic in the boostrap task in order to support different ways of setting up katello. To illustrate this last point, you could have some tasks like: > > rake bootstrap > rake bootstrap:pulpv2 > rake bootstrap:sam > (and so forth) > > Anyway, I've worked on a rough draft (http://fpaste.org/HwRc/). The hope is that in order to setup a new project for development, one would just have to run: > > git clone --recursive git at github.com:daviddavis/katello.git > cd katello/src > bundle install > rake bootstrap > > Let me know what you all think. Thanks! > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Tue Oct 23 10:38:30 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 23 Oct 2012 11:38:30 +0100 Subject: [katello-devel] Tried to install from https://fedorahosted.org/katello/wiki/DevelopmentSetup In-Reply-To: <50859CFA.1050901@redhat.com> References: <50859CFA.1050901@redhat.com> Message-ID: <508673A6.2030801@redhat.com> On 22/10/12 08:22 PM, Bryan Kearney wrote: > Some notes. Let me know if I should uddate or add bugs: > > 1) > http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-latest.rpm > does not exist. I used the current released one from 1.1 > > 2) I had a /bundler/config sitting around which turned off the > development group. You must've ran 'bundler install --without development' at some point. All subsequent runs (and requires) assume the same configuration. -d > I noticed that redcarpet and js-routes were not installed. Would a > ruby person have known this? > > 3) The install instruction talk about port 3000, but I believe that > will mean subscription manager will not work. Should we update it to > go throuhg httpd? > > 4) I had to set use_foreman to false or I would get a can not connect > error. Should foreman be working? > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From inecas at redhat.com Tue Oct 23 10:46:12 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 23 Oct 2012 12:46:12 +0200 Subject: [katello-devel] Tried to install from https://fedorahosted.org/katello/wiki/DevelopmentSetup In-Reply-To: <508673A6.2030801@redhat.com> References: <50859CFA.1050901@redhat.com> <508673A6.2030801@redhat.com> Message-ID: <50867574.7010600@redhat.com> On 10/23/2012 12:38 PM, Dmitri Dolguikh wrote: > On 22/10/12 08:22 PM, Bryan Kearney wrote: >> Some notes. Let me know if I should uddate or add bugs: >> >> 1) >> http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-latest.rpm >> does not exist. I used the current released one from 1.1 >> >> 2) I had a /bundler/config sitting around which turned off the >> development group. > You must've ran 'bundler install --without development' at some point. > All subsequent runs (and requires) assume the same configuration. it seems that's the file from /usr/share/katello/.bundler after installation > -d >> I noticed that redcarpet and js-routes were not installed. Would a >> ruby person have known this? >> >> 3) The install instruction talk about port 3000, but I believe that >> will mean subscription manager will not work. Should we update it to >> go throuhg httpd? >> >> 4) I had to set use_foreman to false or I would get a can not connect >> error. Should foreman be working? >> >> -- 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 -- Ivan From daviddavis at redhat.com Tue Oct 23 11:51:46 2012 From: daviddavis at redhat.com (David Davis) Date: Tue, 23 Oct 2012 07:51:46 -0400 (EDT) Subject: [katello-devel] Bootstrapping katello In-Reply-To: <50863615.5060608@redhat.com> Message-ID: <1797127390.16129443.1350993106185.JavaMail.root@redhat.com> Yes, that does. Thanks Ivan. David ----- Original Message ----- > From: "Ivan Ne?as" > To: katello-devel at redhat.com > Sent: Tuesday, October 23, 2012 2:15:49 AM > Subject: Re: [katello-devel] Bootstrapping katello > > On 10/23/2012 01:08 AM, David Davis wrote: > > Typically in Rails and Ruby projects, there's a boostrap rake task > > that'll take care of setting up the project so you can develop it > > and/or run it. I figured it might be worthwhile to set up > > something similar for Katello after some recent problems people > > have been experiencing. Not only will it appeal to Ruby/Rails > > developers but it might also make it easier for us to setup > > development instances of Katello. In addition, I think it might be > > easier to maintain than the wiki page and we could also allow for > > custom logic in the boostrap task in order to support different > > ways of setting up katello. To illustrate this last point, you > > could have some tasks like: > > > > rake bootstrap > > rake bootstrap:pulpv2 > > rake bootstrap:sam > > (and so forth) > > > > Anyway, I've worked on a rough draft (http://fpaste.org/HwRc/). The > > hope is that in order to setup a new project for development, one > > would just have to run: > > > > git clone --recursive git at github.com:daviddavis/katello.git > > cd katello/src > > bundle install > > rake bootstrap > > > > Let me know what you all think. Thanks! > If you don't insist on the rake task, I thing this does what you had > in > mind https://github.com/Katello/katello/pull/894 . IMO it needs to be > run before the bundle install (in fact it's good to run bundle > install > from the script, making sure the development dependencies are met. > This > script bases the installation on katello-configure which lets us to > have > the basic installation on one place and have it maintained (since > katello-configure is tested on daily basis) > > -- Ivan > > > > David > > > > _______________________________________________ > > 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 bkearney at redhat.com Tue Oct 23 12:06:20 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 23 Oct 2012 08:06:20 -0400 Subject: [katello-devel] Clean install Message-ID: <5086883C.5050402@redhat.com> I am following the insructions at [1], but I am usinng the nighty repos from [2]. With a clean install, I see the following failure in db_seed.log [3]. It looks like it is in the link up to foreman, I see an oauth key in the katello.yml file, but nothing in the foreman side. Am I missing a config some place. [1] https://fedorahosted.org/katello/wiki/DevelopmentSetup [2] http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-1.1.2-1.fc16.noarch.rpm [3] http://pastie.org/5103156 From inecas at redhat.com Tue Oct 23 12:08:09 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 23 Oct 2012 14:08:09 +0200 Subject: [katello-devel] Clean install In-Reply-To: <5086883C.5050402@redhat.com> References: <5086883C.5050402@redhat.com> Message-ID: <508688A9.7000800@redhat.com> On 10/23/2012 02:06 PM, Bryan Kearney wrote: > I am following the insructions at [1], but I am usinng the nighty > repos from [2]. With a clean install, I see the following failure in > db_seed.log [3]. It looks like it is in the link up to foreman, I see > an oauth key in the katello.yml file, but nothing in the foreman side. > Am I missing a config some place. \ Lukas already addressed that: https://github.com/theforeman/foreman/pull/202 -- Ivan > > > [1] https://fedorahosted.org/katello/wiki/DevelopmentSetup > [2] > http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-1.1.2-1.fc16.noarch.rpm > [3] http://pastie.org/5103156 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From bkearney at redhat.com Tue Oct 23 12:12:31 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 23 Oct 2012 08:12:31 -0400 Subject: [katello-devel] Tried to install from https://fedorahosted.org/katello/wiki/DevelopmentSetup In-Reply-To: <20121023093446.GN4702@lzapx.brq.redhat.com> References: <50859CFA.1050901@redhat.com> <20121023093446.GN4702@lzapx.brq.redhat.com> Message-ID: <508689AF.2060603@redhat.com> On 10/23/2012 05:34 AM, Lukas Zapletal wrote: > On Mon, Oct 22, 2012 at 03:22:34PM -0400, Bryan Kearney wrote: >> Some notes. Let me know if I should uddate or add bugs: >> >> 1) http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-latest.rpm >> does not exist. I used the current released one from 1.1 >> > > Due to change in our infrastructure scripts during Koji transition we no > longer create -latest.rpms in the releases. You can find it only in > nightly. > >> 4) I had to set use_foreman to false or I would get a can not >> connect error. Should foreman be working? > > Nightly is currently broken, Foreman does not come up and db seed fails > since it cannot create Foreman user there. I have foreman up, but I am getting a 503 on the install. You can see: http://pastie.org/5103156 -- bk > > Me and Marting are looking into it. > > I will post a warning on the user list. > From inecas at redhat.com Tue Oct 23 12:12:53 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 23 Oct 2012 14:12:53 +0200 Subject: [katello-devel] Tried to install from https://fedorahosted.org/katello/wiki/DevelopmentSetup In-Reply-To: <508689AF.2060603@redhat.com> References: <50859CFA.1050901@redhat.com> <20121023093446.GN4702@lzapx.brq.redhat.com> <508689AF.2060603@redhat.com> Message-ID: <508689C5.6000002@redhat.com> On 10/23/2012 02:12 PM, Bryan Kearney wrote: > On 10/23/2012 05:34 AM, Lukas Zapletal wrote: >> On Mon, Oct 22, 2012 at 03:22:34PM -0400, Bryan Kearney wrote: >>> Some notes. Let me know if I should uddate or add bugs: >>> >>> 1) >>> http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/16/x86_64/katello-repos-latest.rpm >>> does not exist. I used the current released one from 1.1 >>> >> >> Due to change in our infrastructure scripts during Koji transition we no >> longer create -latest.rpms in the releases. You can find it only in >> nightly. >> >>> 4) I had to set use_foreman to false or I would get a can not >>> connect error. Should foreman be working? >> >> Nightly is currently broken, Foreman does not come up and db seed fails >> since it cannot create Foreman user there. > > I have foreman up, but I am getting a 503 on the install. You can see: > > http://pastie.org/5103156 It's probably apache responding because thin is down `ps -Af | grep foreman` will tell you -- Ivan > > -- bk >> >> Me and Marting are looking into it. >> >> I will post a warning on the user list. >> > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From bkearney at redhat.com Tue Oct 23 12:14:28 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 23 Oct 2012 08:14:28 -0400 Subject: [katello-devel] Clean install In-Reply-To: <508688A9.7000800@redhat.com> References: <5086883C.5050402@redhat.com> <508688A9.7000800@redhat.com> Message-ID: <50868A24.8050709@redhat.com> On 10/23/2012 08:08 AM, Ivan Ne?as wrote: > On 10/23/2012 02:06 PM, Bryan Kearney wrote: >> I am following the insructions at [1], but I am usinng the nighty >> repos from [2]. With a clean install, I see the following failure in >> db_seed.log [3]. It looks like it is in the link up to foreman, I see >> an oauth key in the katello.yml file, but nothing in the foreman side. >> Am I missing a config some place. \ > Lukas already addressed that: > https://github.com/theforeman/foreman/pull/202 > > -- Ivan ok.. so I need to wait for a new nightyly, or set use_foreman to false? -- bk From inecas at redhat.com Tue Oct 23 12:14:51 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 23 Oct 2012 14:14:51 +0200 Subject: [katello-devel] Clean install In-Reply-To: <50868A24.8050709@redhat.com> References: <5086883C.5050402@redhat.com> <508688A9.7000800@redhat.com> <50868A24.8050709@redhat.com> Message-ID: <50868A3B.803@redhat.com> On 10/23/2012 02:14 PM, Bryan Kearney wrote: > On 10/23/2012 08:08 AM, Ivan Ne?as wrote: >> On 10/23/2012 02:06 PM, Bryan Kearney wrote: >>> I am following the insructions at [1], but I am usinng the nighty >>> repos from [2]. With a clean install, I see the following failure in >>> db_seed.log [3]. It looks like it is in the link up to foreman, I see >>> an oauth key in the katello.yml file, but nothing in the foreman side. >>> Am I missing a config some place. \ >> Lukas already addressed that: >> https://github.com/theforeman/foreman/pull/202 >> >> -- Ivan > > ok.. so I need to wait for a new nightyly, or set use_foreman to false? try `chown foreman:foreman /var/log/foreman/production.log` and rerun katello-configure again -- Ivan > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From bkearney at redhat.com Tue Oct 23 12:18:37 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 23 Oct 2012 08:18:37 -0400 Subject: [katello-devel] katello-configure --reset-data vs. katello-reset-dbs In-Reply-To: <20121023090217.GL4702@lzapx.brq.redhat.com> References: <55428861.10785123.1350917322945.JavaMail.root@redhat.com> <20121023090217.GL4702@lzapx.brq.redhat.com> Message-ID: <50868B1D.4020505@redhat.com> On 10/23/2012 05:02 AM, Lukas Zapletal wrote: > Right, I am pushing a request that is moving this out of katello-common > package into katello-devel (which already exists but it does not install > yet - Mirek is still packaging some of the devel dependencies). > > If you must have it, please force installation (does not hurt - it just > pulls more devel gems from Fedora/EPEL and drops few additional rake > files). > > LZ > > On Mon, Oct 22, 2012 at 10:48:42AM -0400, Tom McKay wrote: >> A reminder that 'katello-configure --reset-data' is the preferred mechanism for resetting data on a katello install. Although 'katello-reset-dbs' still exists in the scripts dir, it would be great to get everyone transitioned over to katello-configure method as the standard. We will need to update the docs at [1] to on how to get the development gems into the install. I have noticed that katello configure runs from the gems in /usr/share/katello (the rpm install). However, as soon as you install redcarpet in your source dir, it infects the other ruby libaries so that subsequent katello-configure runs fails with being unable to load redcarpet. [1] https://fedorahosted.org/katello/wiki/DevelopmentSetup -- bk From inecas at redhat.com Tue Oct 23 12:19:15 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 23 Oct 2012 14:19:15 +0200 Subject: [katello-devel] katello-configure --reset-data vs. katello-reset-dbs In-Reply-To: <50868B1D.4020505@redhat.com> References: <55428861.10785123.1350917322945.JavaMail.root@redhat.com> <20121023090217.GL4702@lzapx.brq.redhat.com> <50868B1D.4020505@redhat.com> Message-ID: <50868B43.4010202@redhat.com> On 10/23/2012 02:18 PM, Bryan Kearney wrote: > On 10/23/2012 05:02 AM, Lukas Zapletal wrote: >> Right, I am pushing a request that is moving this out of katello-common >> package into katello-devel (which already exists but it does not install >> yet - Mirek is still packaging some of the devel dependencies). >> >> If you must have it, please force installation (does not hurt - it just >> pulls more devel gems from Fedora/EPEL and drops few additional rake >> files). >> >> LZ >> >> On Mon, Oct 22, 2012 at 10:48:42AM -0400, Tom McKay wrote: >>> A reminder that 'katello-configure --reset-data' is the preferred >>> mechanism for resetting data on a katello install. Although >>> 'katello-reset-dbs' still exists in the scripts dir, it would be >>> great to get everyone transitioned over to katello-configure method >>> as the standard. > > > We will need to update the docs at [1] to on how to get the > development gems into the install. I have noticed that katello > configure runs from the gems in /usr/share/katello (the rpm install). > However, as soon as you install redcarpet in your source dir, it > infects the other ruby libaries so that subsequent katello-configure > runs fails with being unable to load redcarpet. It should not happen with the devsetup script I've sent. -- Ivan > > [1] https://fedorahosted.org/katello/wiki/DevelopmentSetup > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From Duncan.Innes at virginmoney.com Tue Oct 23 13:18:14 2012 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Tue, 23 Oct 2012 14:18:14 +0100 Subject: [katello-devel] [stahnma@puppetlabs.com: Fixing Puppet inFedora/EPEL] In-Reply-To: <508663CF.7000600@redhat.com> References: <20121023073543.GE4702@lzapx.brq.redhat.com> <508663CF.7000600@redhat.com> Message-ID: <56343345B145C043AE990701E3D19395B9E9A1@EXVS2.nrplc.localnet> > On Behalf Of Ohad Levy > Sent: 23 October 2012 10:31 > > On 10/23/2012 09:35 AM, Lukas Zapletal wrote: > > My proposal would be the following: > > * Move EPEL 6, Fedora >= 17 to use Puppet 3.0. > I would vote against it, 3.0 is not stable at all, and requires manifest code > change (as stated) i would wait until 3.0 is stable before pushing that. How unstable is Puppet 3.0 really? I'm not criticising, but I just hadn't seen any big problems with it. Katello might be at 1.1 now, but is really aiming at maturity and widespread stability further down the road surely? Should integration of Puppet 3.0 not be looked at now rather than delaying the pain for another day? > > * Move EPEL 5 to the latest 2.7.x branch. This is the last branch of > > Puppet that supports Ruby 1.8.5, and works with 3.0 masters. > +1 for 2.7.x in both EPEL 5,6 fedora might make sense for > puppet 3 (but has the potinial of crashing as clients needs to be equal > or older to the master). I don't have any great say, but I'd vote to get functionality in sooner rather than later > > Ohad This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Authorised and regulated by the Financial Services Authority. The following companies also trade as Virgin Money and are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482) are authorised and regulated by the Financial Services Authority. Virgin Money Cards Limited (Company no. 4232392) is introducer appointed representative only of Virgin Money Personal Financial Service Limited. For further details of Virgin Money group companies please visit our website at virginmoney.com From sam at kottlerdevelopment.com Tue Oct 23 13:58:43 2012 From: sam at kottlerdevelopment.com (Sam Kottler) Date: Tue, 23 Oct 2012 09:58:43 -0400 Subject: [katello-devel] [stahnma@puppetlabs.com: Fixing Puppet inFedora/EPEL] In-Reply-To: <56343345B145C043AE990701E3D19395B9E9A1@EXVS2.nrplc.localnet> References: <20121023073543.GE4702@lzapx.brq.redhat.com> <508663CF.7000600@redhat.com> <56343345B145C043AE990701E3D19395B9E9A1@EXVS2.nrplc.localnet> Message-ID: > > How unstable is Puppet 3.0 really? I'm not criticising, but I just > hadn't seen any > big problems with it. Katello might be at 1.1 now, but is really aiming > at maturity > and widespread stability further down the road surely? > Should integration of Puppet 3.0 not be looked at now rather than > delaying the pain > for another day? There are a lot of issues with Puppet 3 that could potentially block users from upgrading. One of them is that storeconfigs don't work, so if you're using them you can't upgrade yet. Additionally, there is a change that invalidates hyphens as class names, which will require some (albeit minor) refactoring. I've seen some other issues in rolling the patch for Foreman that adds Puppet 3 support, like the configuration loading mechanism doesn't work as designed; that should be fixed in the recently release 3.0.1. That issue meant that Puppet had to run as root so it would load the configuration from /etc/puppet instead of $HOME/.puppet. Anyhow, I think that it's worthwhile to wait for Puppet 3 to become more stable and battle tested before putting it into production, but upgrading your manifests now to be compliant with the DSL changes in 3 certainly never hurts. -S On Tue, Oct 23, 2012 at 9:18 AM, Innes, Duncan wrote: > > On Behalf Of Ohad Levy > > Sent: 23 October 2012 10:31 > > > > On 10/23/2012 09:35 AM, Lukas Zapletal wrote: > > > My proposal would be the following: > > > * Move EPEL 6, Fedora >= 17 to use Puppet 3.0. > > I would vote against it, 3.0 is not stable at all, and requires > manifest code > > change (as stated) i would wait until 3.0 is stable before pushing > that. > How unstable is Puppet 3.0 really? I'm not criticising, but I just > hadn't seen any > big problems with it. Katello might be at 1.1 now, but is really aiming > at maturity > and widespread stability further down the road surely? > Should integration of Puppet 3.0 not be looked at now rather than > delaying the pain > for another day? > > > * Move EPEL 5 to the latest 2.7.x branch. This is the last branch > of > > > Puppet that supports Ruby 1.8.5, and works with 3.0 masters. > > +1 for 2.7.x in both EPEL 5,6 fedora might make sense for > > puppet 3 (but has the potinial of crashing as clients needs to be > equal > > or older to the master). > I don't have any great say, but I'd vote to get functionality in sooner > rather than > later > > > > Ohad > > > This e-mail is intended to be confidential to the recipient. If you > receive a copy in error, please inform the sender and then delete this > message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). > Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. > Authorised and regulated by the Financial Services Authority. > > The following companies also trade as Virgin Money and are registered in > England and Wales and have their registered office at Discovery House, > Whiting Road, Norwich NR4 6EJ: > > Virgin Money Personal Financial Service Limited (Company no. 3072766) and > Virgin Money Unit Trust Managers Limited (Company no. 3000482) are > authorised and regulated by the Financial Services Authority. > > Virgin Money Cards Limited (Company no. 4232392) is introducer appointed > representative only of Virgin Money Personal Financial Service Limited. > > For further details of Virgin Money group companies please visit our > website at virginmoney.com > > _______________________________________________ > 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 lzap at redhat.com Tue Oct 23 14:21:41 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 23 Oct 2012 16:21:41 +0200 Subject: [katello-devel] Clean install In-Reply-To: <5086883C.5050402@redhat.com> References: <5086883C.5050402@redhat.com> Message-ID: <20121023142042.GT4702@lzapx.brq.redhat.com> Done, I have also created small change on the Katello side so we wont run this as root anymore. Will build katello rpms soon, next nightly should be fine hopefully. LZ On Tue, Oct 23, 2012 at 08:06:20AM -0400, Bryan Kearney wrote: > I am following the insructions at [1], but I am usinng the nighty > repos from [2]. With a clean install, I see the following failure in > db_seed.log [3]. It looks like it is in the link up to foreman, I > see an oauth key in the katello.yml file, but nothing in the foreman > side. Am I missing a config some place. > > > [1] https://fedorahosted.org/katello/wiki/DevelopmentSetup > [2] http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-1.1.2-1.fc16.noarch.rpm > [3] http://pastie.org/5103156 > > _______________________________________________ > 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 Tue Oct 23 15:04:46 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 23 Oct 2012 17:04:46 +0200 Subject: [katello-devel] Nightly builds Message-ID: <20121023150445.GY4702@lzapx.brq.redhat.com> Hey, I suspect Mirek's server which do the nigtly builds in koji is not running due to power outage (migration) in Brno "minilab". If this is confirmed tomorrow, I will keep building nightly builds very Brno morning :-) Anyone can do this, by simply executing: ./rel-eng/build-missing-builds-in-koji.sh watching http://koji.katello.org/koji/tasks and waiting until new repo is created (4 times a day). It is very simple FYI ;-) LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From jrist at redhat.com Tue Oct 23 15:24:56 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 23 Oct 2012 09:24:56 -0600 Subject: [katello-devel] Merging and Pulling with no wait Message-ID: <5086B6C8.5080201@redhat.com> Hi Everyone - I started a discussion on IRC because I can't just walk over to people's cubes and question things, but I thought an email would be best to expand the conversation. This morning I was going through my emails and I saw two emails for pull request 898. ( https://github.com/Katello/katello/pull/898 ). One for the pull request and 12 minutes later an ACK and merge. Unless I'm checking my email all the time, I would have missed that. And I did miss it. Now I'm picking on one pull request but the fact of the matter is that this has happened a bunch lately. The whole point of the pull request process is to make sure we're getting a chance to prevent errors like the one that pull request #903 was made to fix. Eric pointed out that there isn't a specified wait time but can we please take into consideration that 12 minutes isn't enough for a pull request to be fully discussed? I mentioned earlier that I don't have the ability to hear cube conversations or pass by someone in the hall and chat with them, so I really need to have the ability to "hear things" via emails, IRC, and pull request discussion. In general I think it's healthier for the team to be able to "hear things" that way as well. Thanks! Jason -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From jrist at redhat.com Tue Oct 23 16:44:32 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 23 Oct 2012 10:44:32 -0600 Subject: [katello-devel] Bootstrapping katello In-Reply-To: <50863615.5060608@redhat.com> References: <1059218714.15904546.1350947300869.JavaMail.root@redhat.com> <50863615.5060608@redhat.com> Message-ID: <5086C970.5060709@redhat.com> On 10/23/2012 12:15 AM, Ivan Ne?as wrote: > On 10/23/2012 01:08 AM, David Davis wrote: >> Typically in Rails and Ruby projects, there's a boostrap rake task >> that'll take care of setting up the project so you can develop it >> and/or run it. I figured it might be worthwhile to set up something >> similar for Katello after some recent problems people have been >> experiencing. Not only will it appeal to Ruby/Rails developers but it >> might also make it easier for us to setup development instances of >> Katello. In addition, I think it might be easier to maintain than the >> wiki page and we could also allow for custom logic in the boostrap >> task in order to support different ways of setting up katello. To >> illustrate this last point, you could have some tasks like: >> >> rake bootstrap >> rake bootstrap:pulpv2 >> rake bootstrap:sam >> (and so forth) >> >> Anyway, I've worked on a rough draft (http://fpaste.org/HwRc/). The >> hope is that in order to setup a new project for development, one >> would just have to run: >> >> git clone --recursive git at github.com:daviddavis/katello.git >> cd katello/src >> bundle install >> rake bootstrap >> >> Let me know what you all think. Thanks! > If you don't insist on the rake task, I thing this does what you had in > mind https://github.com/Katello/katello/pull/894 . IMO it needs to be > run before the bundle install (in fact it's good to run bundle install > from the script, making sure the development dependencies are met. This > script bases the installation on katello-configure which lets us to have > the basic installation on one place and have it maintained (since > katello-configure is tested on daily basis) > > -- Ivan >> >> David >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > If rake:bootstrap is a common thing, then why don't' we tie it into the script you wrote? Similar to make configure of old. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From ehelms at redhat.com Tue Oct 23 16:58:36 2012 From: ehelms at redhat.com (Eric Helms) Date: Tue, 23 Oct 2012 12:58:36 -0400 (EDT) Subject: [katello-devel] Bootstrapping katello In-Reply-To: <5086C970.5060709@redhat.com> Message-ID: <1212464577.11431062.1351011516040.JavaMail.root@redhat.com> +1 to what Jason said. If the Ruby/Rails community at large is used to a rake:boostrap task, and we can take our bash script and wrap a rake task around it and achieve both with easy maintainability lets do it. -Eric ----- Original Message ----- From: "Jason Rist" To: "Ivan Ne?as" Cc: katello-devel at redhat.com Sent: Tuesday, October 23, 2012 12:44:32 PM Subject: Re: [katello-devel] Bootstrapping katello On 10/23/2012 12:15 AM, Ivan Ne?as wrote: > On 10/23/2012 01:08 AM, David Davis wrote: >> Typically in Rails and Ruby projects, there's a boostrap rake task >> that'll take care of setting up the project so you can develop it >> and/or run it. I figured it might be worthwhile to set up something >> similar for Katello after some recent problems people have been >> experiencing. Not only will it appeal to Ruby/Rails developers but it >> might also make it easier for us to setup development instances of >> Katello. In addition, I think it might be easier to maintain than the >> wiki page and we could also allow for custom logic in the boostrap >> task in order to support different ways of setting up katello. To >> illustrate this last point, you could have some tasks like: >> >> rake bootstrap >> rake bootstrap:pulpv2 >> rake bootstrap:sam >> (and so forth) >> >> Anyway, I've worked on a rough draft (http://fpaste.org/HwRc/). The >> hope is that in order to setup a new project for development, one >> would just have to run: >> >> git clone --recursive git at github.com:daviddavis/katello.git >> cd katello/src >> bundle install >> rake bootstrap >> >> Let me know what you all think. Thanks! > If you don't insist on the rake task, I thing this does what you had in > mind https://github.com/Katello/katello/pull/894 . IMO it needs to be > run before the bundle install (in fact it's good to run bundle install > from the script, making sure the development dependencies are met. This > script bases the installation on katello-configure which lets us to have > the basic installation on one place and have it maintained (since > katello-configure is tested on daily basis) > > -- Ivan >> >> David >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > If rake:bootstrap is a common thing, then why don't' we tie it into the script you wrote? Similar to make configure of old. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From inecas at redhat.com Tue Oct 23 17:24:17 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 23 Oct 2012 19:24:17 +0200 Subject: [katello-devel] Bootstrapping katello In-Reply-To: <1212464577.11431062.1351011516040.JavaMail.root@redhat.com> References: <1212464577.11431062.1351011516040.JavaMail.root@redhat.com> Message-ID: <5086D2C1.50201@redhat.com> When running rake, it usually load all the rake tasks you have. Which might be a problem because some deps you just don't have yet and the devsetup calls bundle install for you (leveraging the Gemfile.lock from the "production" installation, so that you get the packages from the system first and then get the rest from rubygems. I'm not sure how spread the "rake bootstrap" command is (honestly: I've read about it here for the first time, but that might be my ignorance). I prefer scripts against rake tasks because the rake task doesn't have nice args parsing and help messages. But feel free to update that or reuse it to make it into `rake bootstrap`. However, I think the important think is to document, which needs to be done for both cases. I think users doesn't care what command they run provided it works. -- Ivan On 10/23/2012 06:58 PM, Eric Helms wrote: > +1 to what Jason said. If the Ruby/Rails community at large is used to a rake:boostrap task, and we can take our bash script and wrap a rake task around it and achieve both with easy maintainability lets do it. > > -Eric > > ----- Original Message ----- > From: "Jason Rist" > To: "Ivan Ne?as" > Cc: katello-devel at redhat.com > Sent: Tuesday, October 23, 2012 12:44:32 PM > Subject: Re: [katello-devel] Bootstrapping katello > > On 10/23/2012 12:15 AM, Ivan Ne?as wrote: >> On 10/23/2012 01:08 AM, David Davis wrote: >>> Typically in Rails and Ruby projects, there's a boostrap rake task >>> that'll take care of setting up the project so you can develop it >>> and/or run it. I figured it might be worthwhile to set up something >>> similar for Katello after some recent problems people have been >>> experiencing. Not only will it appeal to Ruby/Rails developers but it >>> might also make it easier for us to setup development instances of >>> Katello. In addition, I think it might be easier to maintain than the >>> wiki page and we could also allow for custom logic in the boostrap >>> task in order to support different ways of setting up katello. To >>> illustrate this last point, you could have some tasks like: >>> >>> rake bootstrap >>> rake bootstrap:pulpv2 >>> rake bootstrap:sam >>> (and so forth) >>> >>> Anyway, I've worked on a rough draft (http://fpaste.org/HwRc/). The >>> hope is that in order to setup a new project for development, one >>> would just have to run: >>> >>> git clone --recursive git at github.com:daviddavis/katello.git >>> cd katello/src >>> bundle install >>> rake bootstrap >>> >>> Let me know what you all think. Thanks! >> If you don't insist on the rake task, I thing this does what you had in >> mind https://github.com/Katello/katello/pull/894 . IMO it needs to be >> run before the bundle install (in fact it's good to run bundle install >> from the script, making sure the development dependencies are met. This >> script bases the installation on katello-configure which lets us to have >> the basic installation on one place and have it maintained (since >> katello-configure is tested on daily basis) >> >> -- Ivan >>> David >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> > If rake:bootstrap is a common thing, then why don't' we tie it into the > script you wrote? Similar to make configure of old. > > -J > -- Ivan From daviddavis at redhat.com Tue Oct 23 17:26:06 2012 From: daviddavis at redhat.com (David Davis) Date: Tue, 23 Oct 2012 13:26:06 -0400 (EDT) Subject: [katello-devel] Bootstrapping katello In-Reply-To: <1212464577.11431062.1351011516040.JavaMail.root@redhat.com> Message-ID: <681629038.16368973.1351013166431.JavaMail.root@redhat.com> So having a "rake boostrap" task is not common enough in the Ruby/Rails world that someone wouldn't just run 'rake bootstrap' in a project and expect it to work. Plus, running rake requires stuff like the project gems and Ivan's script installs those. I think most people are probably going to develop the project from an existing katello rpm install and that fits Ivan's script better. At some point though, it might be worthwhile to refactor Ivan's script, pull out the common code, and make a rake bootstrap task but that's going to take work and is not worth it ATM IMO. It's a good idea though so it's worth keeping in mind. David ----- Original Message ----- > From: "Eric Helms" > To: katello-devel at redhat.com > Sent: Tuesday, October 23, 2012 12:58:36 PM > Subject: Re: [katello-devel] Bootstrapping katello > > +1 to what Jason said. If the Ruby/Rails community at large is used > to a rake:boostrap task, and we can take our bash script and wrap a > rake task around it and achieve both with easy maintainability lets > do it. > > -Eric > > ----- Original Message ----- > From: "Jason Rist" > To: "Ivan Ne?as" > Cc: katello-devel at redhat.com > Sent: Tuesday, October 23, 2012 12:44:32 PM > Subject: Re: [katello-devel] Bootstrapping katello > > On 10/23/2012 12:15 AM, Ivan Ne?as wrote: > > On 10/23/2012 01:08 AM, David Davis wrote: > >> Typically in Rails and Ruby projects, there's a boostrap rake task > >> that'll take care of setting up the project so you can develop it > >> and/or run it. I figured it might be worthwhile to set up > >> something > >> similar for Katello after some recent problems people have been > >> experiencing. Not only will it appeal to Ruby/Rails developers but > >> it > >> might also make it easier for us to setup development instances of > >> Katello. In addition, I think it might be easier to maintain than > >> the > >> wiki page and we could also allow for custom logic in the boostrap > >> task in order to support different ways of setting up katello. To > >> illustrate this last point, you could have some tasks like: > >> > >> rake bootstrap > >> rake bootstrap:pulpv2 > >> rake bootstrap:sam > >> (and so forth) > >> > >> Anyway, I've worked on a rough draft (http://fpaste.org/HwRc/). > >> The > >> hope is that in order to setup a new project for development, one > >> would just have to run: > >> > >> git clone --recursive git at github.com:daviddavis/katello.git > >> cd katello/src > >> bundle install > >> rake bootstrap > >> > >> Let me know what you all think. Thanks! > > If you don't insist on the rake task, I thing this does what you > > had in > > mind https://github.com/Katello/katello/pull/894 . IMO it needs to > > be > > run before the bundle install (in fact it's good to run bundle > > install > > from the script, making sure the development dependencies are met. > > This > > script bases the installation on katello-configure which lets us to > > have > > the basic installation on one place and have it maintained (since > > katello-configure is tested on daily basis) > > > > -- Ivan > >> > >> David > >> > >> _______________________________________________ > >> katello-devel mailing list > >> katello-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > If rake:bootstrap is a common thing, then why don't' we tie it into > the > script you wrote? Similar to make configure of old. > > -J > > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > github/identi.ca: knowncitizen > > _______________________________________________ > 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 Tue Oct 23 17:47:42 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 23 Oct 2012 13:47:42 -0400 Subject: [katello-devel] Nightly installed! Message-ID: <5086D83E.6080209@redhat.com> Ok... got it installed with lots of help from Lukas and Petr. Here were the changes to [1]. let me know what I should file bugs for, or change wiki pages: 1) Need to use nightly, not 1.1 or 1.0 2) After installing the rpms, I applied the following patch to foreman: https://github.com/theforeman/foreman/pull/202 3) Edit the /etc/foreman/settings.yml file so that :login: true 4) From /usr/share/foreman run rake console and then execute User.create_admin. You need (3) to make (4) work I believe that Petr said that 4 woudl be fix if we get foreman dev into the nightly build. I am not sure about the setting in 3 however, if that it needed. -- bk From bkearney at redhat.com Tue Oct 23 17:49:05 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 23 Oct 2012 13:49:05 -0400 Subject: [katello-devel] Nightly installed! In-Reply-To: <5086D83E.6080209@redhat.com> References: <5086D83E.6080209@redhat.com> Message-ID: <5086D891.7080701@redhat.com> On 10/23/2012 01:47 PM, Bryan Kearney wrote: > Ok... got it installed with lots of help from Lukas and Petr. Here were > the changes to [1]. let me know what I should file bugs for, or change > wiki pages: > > 1) Need to use nightly, not 1.1 or 1.0 > 2) After installing the rpms, I applied the following patch to foreman: > https://github.com/theforeman/foreman/pull/202 > 3) Edit the /etc/foreman/settings.yml file so that :login: true > 4) From /usr/share/foreman run rake console and then execute > User.create_admin. You need (3) to make (4) work > > > I believe that Petr said that 4 woudl be fix if we get foreman dev into > the nightly build. I am not sure about the setting in 3 however, if that > it needed. > > -- bk > As a follow up.. I assumed I would see the new admin section which Pavel showed the other day. is that in master yet? -- bk From bkearney at redhat.com Tue Oct 23 18:12:27 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 23 Oct 2012 14:12:27 -0400 Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <5086B6C8.5080201@redhat.com> References: <5086B6C8.5080201@redhat.com> Message-ID: <5086DE0B.8080209@redhat.com> On 10/23/2012 11:24 AM, Jason Rist wrote: > Hi Everyone - I started a discussion on IRC because I can't just walk > over to people's cubes and question things, but I thought an email would > be best to expand the conversation. > > This morning I was going through my emails and I saw two emails for pull > request 898. ( https://github.com/Katello/katello/pull/898 ). One for > the pull request and 12 minutes later an ACK and merge. Unless I'm > checking my email all the time, I would have missed that. And I did > miss it. > > Now I'm picking on one pull request but the fact of the matter is that > this has happened a bunch lately. > > The whole point of the pull request process is to make sure we're > getting a chance to prevent errors like the one that pull request #903 > was made to fix. > > Eric pointed out that there isn't a specified wait time but can we > please take into consideration that 12 minutes isn't enough for a pull > request to be fully discussed? What is enought time? Keep in mind that for +5 hours of each day, the other half of the team is not there. -- bk From jrist at redhat.com Tue Oct 23 19:52:17 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 23 Oct 2012 13:52:17 -0600 Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <5086DE0B.8080209@redhat.com> References: <5086B6C8.5080201@redhat.com> <5086DE0B.8080209@redhat.com> Message-ID: <5086F571.8040504@redhat.com> On Tue 23 Oct 2012 12:12:27 PM MDT, Bryan Kearney wrote: > On 10/23/2012 11:24 AM, Jason Rist wrote: >> Hi Everyone - I started a discussion on IRC because I can't just walk >> over to people's cubes and question things, but I thought an email would >> be best to expand the conversation. >> >> This morning I was going through my emails and I saw two emails for pull >> request 898. ( https://github.com/Katello/katello/pull/898 ). One for >> the pull request and 12 minutes later an ACK and merge. Unless I'm >> checking my email all the time, I would have missed that. And I did >> miss it. >> >> Now I'm picking on one pull request but the fact of the matter is that >> this has happened a bunch lately. >> >> The whole point of the pull request process is to make sure we're >> getting a chance to prevent errors like the one that pull request #903 >> was made to fix. >> >> Eric pointed out that there isn't a specified wait time but can we >> please take into consideration that 12 minutes isn't enough for a pull >> request to be fully discussed? > > What is enought time? Keep in mind that for +5 hours of each day, the > other half of the team is not there. > -- bk > Then doesn't it have to be at least +5 hours? -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From bkearney at redhat.com Tue Oct 23 20:21:17 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 23 Oct 2012 16:21:17 -0400 Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <5086F571.8040504@redhat.com> References: <5086B6C8.5080201@redhat.com> <5086DE0B.8080209@redhat.com> <5086F571.8040504@redhat.com> Message-ID: <5086FC3D.5020609@redhat.com> On 10/23/2012 03:52 PM, Jason Rist wrote: > On Tue 23 Oct 2012 12:12:27 PM MDT, Bryan Kearney wrote: >> On 10/23/2012 11:24 AM, Jason Rist wrote: >>> Hi Everyone - I started a discussion on IRC because I can't just walk >>> over to people's cubes and question things, but I thought an email would >>> be best to expand the conversation. >>> >>> This morning I was going through my emails and I saw two emails for pull >>> request 898. ( https://github.com/Katello/katello/pull/898 ). One for >>> the pull request and 12 minutes later an ACK and merge. Unless I'm >>> checking my email all the time, I would have missed that. And I did >>> miss it. >>> >>> Now I'm picking on one pull request but the fact of the matter is that >>> this has happened a bunch lately. >>> >>> The whole point of the pull request process is to make sure we're >>> getting a chance to prevent errors like the one that pull request #903 >>> was made to fix. >>> >>> Eric pointed out that there isn't a specified wait time but can we >>> please take into consideration that 12 minutes isn't enough for a pull >>> request to be fully discussed? >> >> What is enought time? Keep in mind that for +5 hours of each day, the >> other half of the team is not there. >> -- bk >> > > > Then doesn't it have to be at least +5 hours? > > -J So, here is my take. Feel free to jump in and disagree. I think the goal of reviews and acks is to get a second set of eyes on the code to improve quality. There is an secondary benefit of educating / including other team members as well. However, I dont believe that is the primary goal. I think watching the commit logs is how that needs to be done. If we do not, then we have to go to a 24 hour delay on commits to ensure folks from all time zones can participate. -- bk From hbrock at redhat.com Tue Oct 23 20:23:15 2012 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 23 Oct 2012 16:23:15 -0400 Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <5086FC3D.5020609@redhat.com> References: <5086B6C8.5080201@redhat.com> <5086DE0B.8080209@redhat.com> <5086F571.8040504@redhat.com> <5086FC3D.5020609@redhat.com> Message-ID: <20121023202315.GN3729@redhat.com> On Tue, Oct 23, 2012 at 04:21:17PM -0400, Bryan Kearney wrote: > On 10/23/2012 03:52 PM, Jason Rist wrote: > >On Tue 23 Oct 2012 12:12:27 PM MDT, Bryan Kearney wrote: > >>On 10/23/2012 11:24 AM, Jason Rist wrote: > >>>Hi Everyone - I started a discussion on IRC because I can't just walk > >>>over to people's cubes and question things, but I thought an email would > >>>be best to expand the conversation. > >>> > >>>This morning I was going through my emails and I saw two emails for pull > >>>request 898. ( https://github.com/Katello/katello/pull/898 ). One for > >>>the pull request and 12 minutes later an ACK and merge. Unless I'm > >>>checking my email all the time, I would have missed that. And I did > >>>miss it. > >>> > >>>Now I'm picking on one pull request but the fact of the matter is that > >>>this has happened a bunch lately. > >>> > >>>The whole point of the pull request process is to make sure we're > >>>getting a chance to prevent errors like the one that pull request #903 > >>>was made to fix. > >>> > >>>Eric pointed out that there isn't a specified wait time but can we > >>>please take into consideration that 12 minutes isn't enough for a pull > >>>request to be fully discussed? > >> > >>What is enought time? Keep in mind that for +5 hours of each day, the > >>other half of the team is not there. > >>-- bk > >> > > > > > >Then doesn't it have to be at least +5 hours? > > > >-J > > So, here is my take. Feel free to jump in and disagree. I think the > goal of reviews and acks is to get a second set of eyes on the code > to improve quality. There is an secondary benefit of educating / > including other team members as well. However, I dont believe that > is the primary goal. I think watching the commit logs is how that > needs to be done. If we do not, then we have to go to a 24 hour > delay on commits to ensure folks from all time zones can > participate. Not to argue with Jason, who has a valid point about the need for discussion of patches, but: A wise man once told me that the reason you have a version control system is so you can roll things back if necessary :). This seems like the kind of situation where that maxim is appropriate. --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 thomasmckay at redhat.com Tue Oct 23 20:35:52 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 23 Oct 2012 16:35:52 -0400 (EDT) Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <5086FC3D.5020609@redhat.com> Message-ID: <1373750030.11493834.1351024552817.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Bryan Kearney" > To: katello-devel at redhat.com > Sent: Tuesday, October 23, 2012 4:21:17 PM > Subject: Re: [katello-devel] Merging and Pulling with no wait > > On 10/23/2012 03:52 PM, Jason Rist wrote: > > On Tue 23 Oct 2012 12:12:27 PM MDT, Bryan Kearney wrote: > >> On 10/23/2012 11:24 AM, Jason Rist wrote: > >>> Hi Everyone - I started a discussion on IRC because I can't just > >>> walk > >>> over to people's cubes and question things, but I thought an > >>> email would > >>> be best to expand the conversation. > >>> > >>> This morning I was going through my emails and I saw two emails > >>> for pull > >>> request 898. ( https://github.com/Katello/katello/pull/898 ). > >>> One for > >>> the pull request and 12 minutes later an ACK and merge. Unless > >>> I'm > >>> checking my email all the time, I would have missed that. And I > >>> did > >>> miss it. > >>> > >>> Now I'm picking on one pull request but the fact of the matter is > >>> that > >>> this has happened a bunch lately. > >>> > >>> The whole point of the pull request process is to make sure we're > >>> getting a chance to prevent errors like the one that pull request > >>> #903 > >>> was made to fix. > >>> > >>> Eric pointed out that there isn't a specified wait time but can > >>> we > >>> please take into consideration that 12 minutes isn't enough for a > >>> pull > >>> request to be fully discussed? > >> > >> What is enought time? Keep in mind that for +5 hours of each day, > >> the > >> other half of the team is not there. > >> -- bk > >> > > > > > > Then doesn't it have to be at least +5 hours? > > > > -J > > So, here is my take. Feel free to jump in and disagree. I think the > goal > of reviews and acks is to get a second set of eyes on the code to > improve quality. There is an secondary benefit of educating / > including > other team members as well. However, I dont believe that is the > primary > goal. I think watching the commit logs is how that needs to be done. > If > we do not, then we have to go to a 24 hour delay on commits to ensure > folks from all time zones can participate. > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > I am against a mandated waiting period. Rather, I think, I would like to see a continuation of what I see now: Team members getting to know what other team members strengths and interests are. For example, I am very interested in manifest and subscription areas of the code and try to keep my eye open for pull-requests that are in this area. Some, knowing my interest, include me directly in the pull-request comment or reach out on IRC. Similarly, if I'm going to do something with javascript or css I will seek out @jrist or @ehelms when I'm in that area. For katello-configure it's @lzap. For CDN stuff it's @inecas. etc. This is not to say they "own" these sections but rather that I trust their opinion and respect their interest. Maybe this is misplaced thinking but I don't think so. It is my belief that with some purposeful forethought we can be more inclusive in our pull-request reviews. Again, though, I don't think making it mandatory is necessary. If you have an interest in areas of the code, sharing that with the rest of us is perfectly reasonable. On the secondary issue of code stability, we are certainly iterating towards something better than what is there now. With @lzap and @ehelms efforts for automated testing per pull-request, plus @jweiss, @omaciel, and QE crew ramping up jenkins runs, and finally speed improvements to spec tests, I think stability and accountability has already increased. Overall I really like working within our current structure and with our team. I've worked at a lot of companies (feel free to verify on linkedin ;) and I can say this product team is outstanding. From ehelms at redhat.com Tue Oct 23 20:52:30 2012 From: ehelms at redhat.com (Eric Helms) Date: Tue, 23 Oct 2012 16:52:30 -0400 (EDT) Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <1373750030.11493834.1351024552817.JavaMail.root@redhat.com> Message-ID: <408505080.11497178.1351025550325.JavaMail.root@redhat.com> We have previously adhered to a sense of self-responsibility on the part of the pull-requester. They can leave it wide open on who reviews, or request reviews. They can choose to put someone in charge of review+merge or merge it themselves with a review. A waiting period seems to detract from that, especially without a reliable way to clearly know if the time period is up. I do, however, agree with Jason's point that sometimes we do seem hasty to merge here lately. That being said, and given the previous caveat, we as developers should be exercising our responsibility to as Tom said, request other eyes specifically on given pull requests, and let "large" pull requests sit longer than others. We don't all have time to get to reading a pull request as soon as it is opened, but I think the combination of tested (and linted) pull requests and greater developer awareness should help alleviate (and if it does not, we can re-visit). Two things: 1) Tom, based on your notion of where people specialize, perhaps we should take a page from the Aeolus playbook http://aeolusproject.org/aeolus_team.html 2) Should we add a caveat to our process, whereby a developer can request the desire to review a pull request prior to it's merging for cases where you don't have time at that exact moment? Similar to how the author of a pull request can request review. -Eric ----- Original Message ----- From: "Tom McKay" To: "Bryan Kearney" Cc: katello-devel at redhat.com Sent: Tuesday, October 23, 2012 4:35:52 PM Subject: Re: [katello-devel] Merging and Pulling with no wait ----- Original Message ----- > From: "Bryan Kearney" > To: katello-devel at redhat.com > Sent: Tuesday, October 23, 2012 4:21:17 PM > Subject: Re: [katello-devel] Merging and Pulling with no wait > > On 10/23/2012 03:52 PM, Jason Rist wrote: > > On Tue 23 Oct 2012 12:12:27 PM MDT, Bryan Kearney wrote: > >> On 10/23/2012 11:24 AM, Jason Rist wrote: > >>> Hi Everyone - I started a discussion on IRC because I can't just > >>> walk > >>> over to people's cubes and question things, but I thought an > >>> email would > >>> be best to expand the conversation. > >>> > >>> This morning I was going through my emails and I saw two emails > >>> for pull > >>> request 898. ( https://github.com/Katello/katello/pull/898 ). > >>> One for > >>> the pull request and 12 minutes later an ACK and merge. Unless > >>> I'm > >>> checking my email all the time, I would have missed that. And I > >>> did > >>> miss it. > >>> > >>> Now I'm picking on one pull request but the fact of the matter is > >>> that > >>> this has happened a bunch lately. > >>> > >>> The whole point of the pull request process is to make sure we're > >>> getting a chance to prevent errors like the one that pull request > >>> #903 > >>> was made to fix. > >>> > >>> Eric pointed out that there isn't a specified wait time but can > >>> we > >>> please take into consideration that 12 minutes isn't enough for a > >>> pull > >>> request to be fully discussed? > >> > >> What is enought time? Keep in mind that for +5 hours of each day, > >> the > >> other half of the team is not there. > >> -- bk > >> > > > > > > Then doesn't it have to be at least +5 hours? > > > > -J > > So, here is my take. Feel free to jump in and disagree. I think the > goal > of reviews and acks is to get a second set of eyes on the code to > improve quality. There is an secondary benefit of educating / > including > other team members as well. However, I dont believe that is the > primary > goal. I think watching the commit logs is how that needs to be done. > If > we do not, then we have to go to a 24 hour delay on commits to ensure > folks from all time zones can participate. > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > I am against a mandated waiting period. Rather, I think, I would like to see a continuation of what I see now: Team members getting to know what other team members strengths and interests are. For example, I am very interested in manifest and subscription areas of the code and try to keep my eye open for pull-requests that are in this area. Some, knowing my interest, include me directly in the pull-request comment or reach out on IRC. Similarly, if I'm going to do something with javascript or css I will seek out @jrist or @ehelms when I'm in that area. For katello-configure it's @lzap. For CDN stuff it's @inecas. etc. This is not to say they "own" these sections but rather that I trust their opinion and respect their interest. Maybe this is misplaced thinking but I don't think so. It is my belief that with some purposeful forethought we can be more inclusive in our pull-request reviews. Again, though, I don't think making it mandatory is necessary. If you have an interest in areas of the code, sharing that with the rest of us is perfectly reasonable. On the secondary issue of code stability, we are certainly iterating towards something better than what is there now. With @lzap and @ehelms efforts for automated testing per pull-request, plus @jweiss, @omaciel, and QE crew ramping up jenkins runs, and finally speed improvements to spec tests, I think stability and accountability has already increased. Overall I really like working within our current structure and with our team. I've worked at a lot of companies (feel free to verify on linkedin ;) and I can say this product team is outstanding. _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Tue Oct 23 21:03:35 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 23 Oct 2012 17:03:35 -0400 Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <408505080.11497178.1351025550325.JavaMail.root@redhat.com> References: <408505080.11497178.1351025550325.JavaMail.root@redhat.com> Message-ID: <50870627.3040006@redhat.com> On 10/23/2012 04:52 PM, Eric Helms wrote: > We have previously adhered to a sense of self-responsibility on the part of the pull-requester. They can leave it wide open on who reviews, or request reviews. They can choose to put someone in charge of review+merge or merge it themselves with a review. A waiting period seems to detract from that, especially without a reliable way to clearly know if the time period is up. > > I do, however, agree with Jason's point that sometimes we do seem hasty to merge here lately. That being said, and given the previous caveat, we as developers should be exercising our responsibility to as Tom said, request other eyes specifically on given pull requests, and let "large" pull requests sit longer than others. We don't all have time to get to reading a pull request as soon as it is opened, but I think the combination of tested (and linted) pull requests and greater developer awareness should help alleviate (and if it does not, we can re-visit). > > Two things: > 1) Tom, based on your notion of where people specialize, perhaps we should take a page from the Aeolus playbook http://aeolusproject.org/aeolus_team.html > 2) Should we add a caveat to our process, whereby a developer can request the desire to review a pull request prior to it's merging for cases where you don't have time at that exact moment? Similar to how the author of a pull request can request review. We can, but as with any process I think it is important to understand the real goal. If it is education of the whole team as to what is going on in the code base, is pre-merge the best time to do that? -- bk From jrist at redhat.com Tue Oct 23 21:59:29 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 23 Oct 2012 15:59:29 -0600 Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <1373750030.11493834.1351024552817.JavaMail.root@redhat.com> References: <1373750030.11493834.1351024552817.JavaMail.root@redhat.com> Message-ID: <50871341.9000205@redhat.com> On 10/23/2012 02:35 PM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Bryan Kearney" >> To: katello-devel at redhat.com >> Sent: Tuesday, October 23, 2012 4:21:17 PM >> Subject: Re: [katello-devel] Merging and Pulling with no wait >> >> On 10/23/2012 03:52 PM, Jason Rist wrote: >>> On Tue 23 Oct 2012 12:12:27 PM MDT, Bryan Kearney wrote: >>>> On 10/23/2012 11:24 AM, Jason Rist wrote: >>>>> Hi Everyone - I started a discussion on IRC because I can't just >>>>> walk >>>>> over to people's cubes and question things, but I thought an >>>>> email would >>>>> be best to expand the conversation. >>>>> >>>>> This morning I was going through my emails and I saw two emails >>>>> for pull >>>>> request 898. ( https://github.com/Katello/katello/pull/898 ). >>>>> One for >>>>> the pull request and 12 minutes later an ACK and merge. Unless >>>>> I'm >>>>> checking my email all the time, I would have missed that. And I >>>>> did >>>>> miss it. >>>>> >>>>> Now I'm picking on one pull request but the fact of the matter is >>>>> that >>>>> this has happened a bunch lately. >>>>> >>>>> The whole point of the pull request process is to make sure we're >>>>> getting a chance to prevent errors like the one that pull request >>>>> #903 >>>>> was made to fix. >>>>> >>>>> Eric pointed out that there isn't a specified wait time but can >>>>> we >>>>> please take into consideration that 12 minutes isn't enough for a >>>>> pull >>>>> request to be fully discussed? >>>> >>>> What is enought time? Keep in mind that for +5 hours of each day, >>>> the >>>> other half of the team is not there. >>>> -- bk >>>> >>> >>> >>> Then doesn't it have to be at least +5 hours? >>> >>> -J >> >> So, here is my take. Feel free to jump in and disagree. I think the >> goal >> of reviews and acks is to get a second set of eyes on the code to >> improve quality. There is an secondary benefit of educating / >> including >> other team members as well. However, I dont believe that is the >> primary >> goal. I think watching the commit logs is how that needs to be done. >> If >> we do not, then we have to go to a 24 hour delay on commits to ensure >> folks from all time zones can participate. >> >> -- bk >> > > I am against a mandated waiting period. Rather, I think, I would like to see a continuation of what I see now: Team members getting to know what other team members strengths and interests are. > > For example, I am very interested in manifest and subscription areas of the code and try to keep my eye open for pull-requests that are in this area. Some, knowing my interest, include me directly in the pull-request comment or reach out on IRC. > > Similarly, if I'm going to do something with javascript or css I will seek out @jrist or @ehelms when I'm in that area. For katello-configure it's @lzap. For CDN stuff it's @inecas. etc. > > This is not to say they "own" these sections but rather that I trust their opinion and respect their interest. Maybe this is misplaced thinking but I don't think so. > > It is my belief that with some purposeful forethought we can be more inclusive in our pull-request reviews. Again, though, I don't think making it mandatory is necessary. If you have an interest in areas of the code, sharing that with the rest of us is perfectly reasonable. > > On the secondary issue of code stability, we are certainly iterating towards something better than what is there now. With @lzap and @ehelms efforts for automated testing per pull-request, plus @jweiss, @omaciel, and QE crew ramping up jenkins runs, and finally speed improvements to spec tests, I think stability and accountability has already increased. > > Overall I really like working within our current structure and with our team. I've worked at a lot of companies (feel free to verify on linkedin ;) and I can say this product team is outstanding. > Tom - you know, I totally agree with you. I hadn't really thought of the Ozzak/Travis stuff that @ehelms and @lzap had been working on, but obviously it didn't catch Adam's pylint error, so it's not perfect. Perhaps I jumped the gun sending my email out, but my main goal is to make the product stable each and every check-in. Education is great, and I like that side of pull-requests, but it's not the primary reason for my concern. Plus, there is nothing stopping someone from viewing the committed files via the closed pull request. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From lzap at redhat.com Wed Oct 24 08:40:02 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 24 Oct 2012 10:40:02 +0200 Subject: [katello-devel] Bootstrapping katello In-Reply-To: <5086D2C1.50201@redhat.com> References: <1212464577.11431062.1351011516040.JavaMail.root@redhat.com> <5086D2C1.50201@redhat.com> Message-ID: <20121024084002.GB13385@lzapx.brq.redhat.com> Right, that is a good point. Can you delete Gemfile.lock and then to run your rake task? No, you need to do bundle install before running it, I guess. I miss the purpose of the task then. I think this is maybe too complicated, simple script can do the work. In addition to that, this will only work on Fedora and RHEL. LZ On Tue, Oct 23, 2012 at 07:24:17PM +0200, Ivan Necas wrote: > When running rake, it usually load all the rake tasks you have. > Which might be a problem because some deps you just don't have yet > and the devsetup calls bundle install for you (leveraging the > Gemfile.lock from the "production" installation, so that you get the > packages from the system first and then get the rest from rubygems. > I'm not sure how spread the "rake bootstrap" command is (honestly: > I've read about it here for the first time, but that might be my > ignorance). > > I prefer scripts against rake tasks because the rake task doesn't > have nice args parsing and help messages. But feel free to update > that or reuse it to make it into `rake bootstrap`. However, I think > the important think is to document, which needs to be done for both > cases. I think users doesn't care what command they run provided it > works. > > -- Ivan > > On 10/23/2012 06:58 PM, Eric Helms wrote: > >+1 to what Jason said. If the Ruby/Rails community at large is used to a rake:boostrap task, and we can take our bash script and wrap a rake task around it and achieve both with easy maintainability lets do it. > > > >-Eric > > > >----- Original Message ----- > >From: "Jason Rist" > >To: "Ivan Ne?as" > >Cc: katello-devel at redhat.com > >Sent: Tuesday, October 23, 2012 12:44:32 PM > >Subject: Re: [katello-devel] Bootstrapping katello > > > >On 10/23/2012 12:15 AM, Ivan Ne?as wrote: > >>On 10/23/2012 01:08 AM, David Davis wrote: > >>>Typically in Rails and Ruby projects, there's a boostrap rake task > >>>that'll take care of setting up the project so you can develop it > >>>and/or run it. I figured it might be worthwhile to set up something > >>>similar for Katello after some recent problems people have been > >>>experiencing. Not only will it appeal to Ruby/Rails developers but it > >>>might also make it easier for us to setup development instances of > >>>Katello. In addition, I think it might be easier to maintain than the > >>>wiki page and we could also allow for custom logic in the boostrap > >>>task in order to support different ways of setting up katello. To > >>>illustrate this last point, you could have some tasks like: > >>> > >>>rake bootstrap > >>>rake bootstrap:pulpv2 > >>>rake bootstrap:sam > >>>(and so forth) > >>> > >>>Anyway, I've worked on a rough draft (http://fpaste.org/HwRc/). The > >>>hope is that in order to setup a new project for development, one > >>>would just have to run: > >>> > >>>git clone --recursive git at github.com:daviddavis/katello.git > >>>cd katello/src > >>>bundle install > >>>rake bootstrap > >>> > >>>Let me know what you all think. Thanks! > >>If you don't insist on the rake task, I thing this does what you had in > >>mind https://github.com/Katello/katello/pull/894 . IMO it needs to be > >>run before the bundle install (in fact it's good to run bundle install > >>from the script, making sure the development dependencies are met. This > >>script bases the installation on katello-configure which lets us to have > >>the basic installation on one place and have it maintained (since > >>katello-configure is tested on daily basis) > >> > >>-- Ivan > >>>David > >>> > >>>_______________________________________________ > >>>katello-devel mailing list > >>>katello-devel at redhat.com > >>>https://www.redhat.com/mailman/listinfo/katello-devel > >> > >If rake:bootstrap is a common thing, then why don't' we tie it into the > >script you wrote? Similar to make configure of old. > > > >-J > > > > > -- > 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 lzap at redhat.com Wed Oct 24 08:52:52 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 24 Oct 2012 10:52:52 +0200 Subject: [katello-devel] Nightly installed! In-Reply-To: <5086D83E.6080209@redhat.com> References: <5086D83E.6080209@redhat.com> Message-ID: <20121024085252.GC13385@lzapx.brq.redhat.com> The foreman branch merge was a big change. Currently I am building new foreman rpms and I will be creating new nightly repo in an hour or something. Builds were broken and we needed to get Petr's commit in order to get Katello-Foreman working. I will inform on the user list. LZ On Tue, Oct 23, 2012 at 01:47:42PM -0400, Bryan Kearney wrote: > Ok... got it installed with lots of help from Lukas and Petr. Here > were the changes to [1]. let me know what I should file bugs for, or > change wiki pages: > > 1) Need to use nightly, not 1.1 or 1.0 > 2) After installing the rpms, I applied the following patch to > foreman: https://github.com/theforeman/foreman/pull/202 > 3) Edit the /etc/foreman/settings.yml file so that :login: true > 4) From /usr/share/foreman run rake console and then execute > User.create_admin. You need (3) to make (4) work > > > I believe that Petr said that 4 woudl be fix if we get foreman dev > into the nightly build. I am not sure about the setting in 3 > however, if that it needed. > > -- 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 Oct 24 09:07:21 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 24 Oct 2012 11:07:21 +0200 Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <50871341.9000205@redhat.com> References: <1373750030.11493834.1351024552817.JavaMail.root@redhat.com> <50871341.9000205@redhat.com> Message-ID: <20121024090721.GE13385@lzapx.brq.redhat.com> On Tue, Oct 23, 2012 at 03:59:29PM -0600, Jason Rist wrote: > Tom - you know, I totally agree with you. I hadn't really thought of > the Ozzak/Travis stuff that @ehelms and @lzap had been working on, but > obviously it didn't catch Adam's pylint error, so it's not perfect. > Perhaps I jumped the gun sending my email out, but my main goal is to > make the product stable each and every check-in. Education is great, > and I like that side of pull-requests, but it's not the primary reason > for my concern. Plus, there is nothing stopping someone from viewing > the committed files via the closed pull request. > Just to fine-tune the information - Erik is working on TravicCI-Github integration and I am just helping him to integrate the new Gemfile. And it is looking good. No other works on Ozzak, I turned it off because I thought Eric is done (but he is still tuning the stuff). No more Ozzak, expect big announcement very soon :-) I want to change ozzak script to run koji scratch builds against git pull requests. The git pull you picked as an example is not a good example of request that should be put on hold for 24 hours. We have having annoying amount of "fuzzy i18n messages" during our unit test runs and it was literally blocking Eric from doing anything on Travis (because what you get is 10 MB log which does not pretty work with all that javascript that is on Travis). And that was reason for the quick merge. I agree with you that for *important* changes we should not do this and let everyone to read the patch, but I am totally fine with quick-merging those tiny things, blockers and cosmetic changes. One can always rise his hand even after a pull request was merged and if the objections are reasonable - yes - we have the revert thing. I have to admit I raised this topic for the first time, but it was after I saw several big merges I was not totally comfortable with. Let's agree on that and if you (or anyone) encounter a "fast&bad" merge, just scream in the comments. -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Wed Oct 24 12:12:01 2012 From: daviddavis at redhat.com (David Davis) Date: Wed, 24 Oct 2012 08:12:01 -0400 (EDT) Subject: [katello-devel] Python books In-Reply-To: <1693365076.16743836.1351080692939.JavaMail.root@redhat.com> Message-ID: <1382882345.16743925.1351080721781.JavaMail.root@redhat.com> Hi, Got two questions: 1. Are there any Python books that you all recommend for learning python (preferably for someone who knows how to program)? 2. Does anyone have a Python book I could borrow? Thanks! David From lzap at redhat.com Wed Oct 24 13:15:09 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 24 Oct 2012 15:15:09 +0200 Subject: [katello-devel] Python books In-Reply-To: <1382882345.16743925.1351080721781.JavaMail.root@redhat.com> References: <1693365076.16743836.1351080692939.JavaMail.root@redhat.com> <1382882345.16743925.1351080721781.JavaMail.root@redhat.com> Message-ID: <20121024131508.GH13385@lzapx.brq.redhat.com> Instead recommending something, I can give you the opposite. I have bought Dive Into Python 3 book (Czech translation) the other day because I already knew this series are free on the internet and I rarely googled its examples. I have to say its the worst programming book I have ever read about Python, very bad in general. Style of text >looks< like it is funny, but it is not. Examples are not good, pieces of working programs are not clear for beginners and the whole concept sucks. Also, author goes from B to A and vice versa, it is not a tutorial, it is not a documentation, it is nothing. It's just a bunch of long examples with lame text. This guy from Apex NC is not good author of programming books, I have to say. Signing this: http://oppugn.us/posts/1272050135.html Yes, it's free as in free beer. But it is not good. LZ On Wed, Oct 24, 2012 at 08:12:01AM -0400, David Davis wrote: > Hi, > > Got two questions: > > 1. Are there any Python books that you all recommend for learning python (preferably for someone who knows how to program)? > 2. Does anyone have a Python book I could borrow? > > Thanks! > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From ehelms at redhat.com Wed Oct 24 13:23:05 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 24 Oct 2012 09:23:05 -0400 Subject: [katello-devel] Python books In-Reply-To: <20121024131508.GH13385@lzapx.brq.redhat.com> References: <1693365076.16743836.1351080692939.JavaMail.root@redhat.com> <1382882345.16743925.1351080721781.JavaMail.root@redhat.com> <20121024131508.GH13385@lzapx.brq.redhat.com> Message-ID: <5087EBB9.4040108@redhat.com> No personal experience but http://learnpythonthehardway.org/ get's a lot of good reviews. The Python documentation itself is quite good and I have found in the past you can learn by googling when it comes to Python. - Eric On 10/24/2012 09:15 AM, Lukas Zapletal wrote: > Instead recommending something, I can give you the opposite. > > I have bought Dive Into Python 3 book (Czech translation) the other day > because I already knew this series are free on the internet and I rarely > googled its examples. > > I have to say its the worst programming book I have ever read about > Python, very bad in general. Style of text>looks< like it is funny, but > it is not. Examples are not good, pieces of working programs are not > clear for beginners and the whole concept sucks. Also, author goes from > B to A and vice versa, it is not a tutorial, it is not a documentation, > it is nothing. > > It's just a bunch of long examples with lame text. This guy from Apex NC > is not good author of programming books, I have to say. Signing this: > > http://oppugn.us/posts/1272050135.html > > Yes, it's free as in free beer. But it is not good. > > LZ > > On Wed, Oct 24, 2012 at 08:12:01AM -0400, David Davis wrote: >> Hi, >> >> Got two questions: >> >> 1. Are there any Python books that you all recommend for learning python (preferably for someone who knows how to program)? >> 2. Does anyone have a Python book I could borrow? >> >> Thanks! >> >> David >> >> _______________________________________________ >> 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 jweiss at redhat.com Wed Oct 24 18:32:34 2012 From: jweiss at redhat.com (Jeff Weiss) Date: Wed, 24 Oct 2012 14:32:34 -0400 (EDT) Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <20121024090721.GE13385@lzapx.brq.redhat.com> Message-ID: <471761589.1425569.1351103554678.JavaMail.root@redhat.com> We did have a lengthy and productive discussion related to this problem at the QE Summit in Brno last week. I think the major takeaway from that is, we want automated tests running on changes BEFORE they hit master, not only after. So what we'll be working towards is some system whereby Pull Requests are tested, and some kind of feedback of the automated test results will be posted to the PR comments. This process should take less than 1 hour after the PR is submitted. I was planning on using Jenkins, since aside from the PR interaction, the steps are exactly the same as what we do for master today: 1) build rpms from the commit we want to test 2) Install them on fresh vm 3) Run automation against vm We just need to add 0) Monitor PR's 4) Add feedback to PR -Jeff ----- Original Message ----- From: "Lukas Zapletal" To: katello-devel at redhat.com Sent: Wednesday, October 24, 2012 5:07:21 AM Subject: Re: [katello-devel] Merging and Pulling with no wait On Tue, Oct 23, 2012 at 03:59:29PM -0600, Jason Rist wrote: > Tom - you know, I totally agree with you. I hadn't really thought of > the Ozzak/Travis stuff that @ehelms and @lzap had been working on, but > obviously it didn't catch Adam's pylint error, so it's not perfect. > Perhaps I jumped the gun sending my email out, but my main goal is to > make the product stable each and every check-in. Education is great, > and I like that side of pull-requests, but it's not the primary reason > for my concern. Plus, there is nothing stopping someone from viewing > the committed files via the closed pull request. > Just to fine-tune the information - Erik is working on TravicCI-Github integration and I am just helping him to integrate the new Gemfile. And it is looking good. No other works on Ozzak, I turned it off because I thought Eric is done (but he is still tuning the stuff). No more Ozzak, expect big announcement very soon :-) I want to change ozzak script to run koji scratch builds against git pull requests. The git pull you picked as an example is not a good example of request that should be put on hold for 24 hours. We have having annoying amount of "fuzzy i18n messages" during our unit test runs and it was literally blocking Eric from doing anything on Travis (because what you get is 10 MB log which does not pretty work with all that javascript that is on Travis). And that was reason for the quick merge. I agree with you that for *important* changes we should not do this and let everyone to read the patch, but I am totally fine with quick-merging those tiny things, blockers and cosmetic changes. One can always rise his hand even after a pull request was merged and if the objections are reasonable - yes - we have the revert thing. I have to admit I raised this topic for the first time, but it was after I saw several big merges I was not totally comfortable with. Let's agree on that and if you (or anyone) encounter a "fast&bad" merge, just scream in the comments. -- Later, Lukas "lzap" Zapletal #katello #systemengine _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From hbrock at redhat.com Wed Oct 24 18:35:42 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 24 Oct 2012 14:35:42 -0400 Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <471761589.1425569.1351103554678.JavaMail.root@redhat.com> References: <20121024090721.GE13385@lzapx.brq.redhat.com> <471761589.1425569.1351103554678.JavaMail.root@redhat.com> Message-ID: <20121024183542.GD16162@redhat.com> On Wed, Oct 24, 2012 at 02:32:34PM -0400, Jeff Weiss wrote: > We did have a lengthy and productive discussion related to this problem at the QE Summit in Brno last week. > > I think the major takeaway from that is, we want automated tests running on changes BEFORE they hit master, not only after. > > So what we'll be working towards is some system whereby Pull Requests are tested, and some kind of feedback of the automated test results will be posted to the PR comments. > > This process should take less than 1 hour after the PR is submitted. I was planning on using Jenkins, since aside from the PR interaction, the steps are exactly the same as what we do for master today: > > 1) build rpms from the commit we want to test > 2) Install them on fresh vm > 3) Run automation against vm > > We just need to add > 0) Monitor PR's > 4) Add feedback to PR > > > > -Jeff +1000 to this, can we also haz 4 aeolus plz? kthxbai --Hugh > > ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, October 24, 2012 5:07:21 AM > Subject: Re: [katello-devel] Merging and Pulling with no wait > > On Tue, Oct 23, 2012 at 03:59:29PM -0600, Jason Rist wrote: > > Tom - you know, I totally agree with you. I hadn't really thought of > > the Ozzak/Travis stuff that @ehelms and @lzap had been working on, but > > obviously it didn't catch Adam's pylint error, so it's not perfect. > > Perhaps I jumped the gun sending my email out, but my main goal is to > > make the product stable each and every check-in. Education is great, > > and I like that side of pull-requests, but it's not the primary reason > > for my concern. Plus, there is nothing stopping someone from viewing > > the committed files via the closed pull request. > > > > Just to fine-tune the information - Erik is working on TravicCI-Github > integration and I am just helping him to integrate the new Gemfile. And > it is looking good. No other works on Ozzak, I turned it off because I > thought Eric is done (but he is still tuning the stuff). No more Ozzak, > expect big announcement very soon :-) I want to change ozzak script to > run koji scratch builds against git pull requests. > > The git pull you picked as an example is not a good example of request > that should be put on hold for 24 hours. We have having annoying amount > of "fuzzy i18n messages" during our unit test runs and it was literally > blocking Eric from doing anything on Travis (because what you get is 10 > MB log which does not pretty work with all that javascript that is on > Travis). And that was reason for the quick merge. > > I agree with you that for *important* changes we should not do this and > let everyone to read the patch, but I am totally fine with quick-merging > those tiny things, blockers and cosmetic changes. One can always rise > his hand even after a pull request was merged and if the objections are > reasonable - yes - we have the revert thing. > > I have to admit I raised this topic for the first time, but it was after > I saw several big merges I was not totally comfortable with. > > Let's agree on that and if you (or anyone) encounter a "fast&bad" merge, > just scream in the comments. > > -- > 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 -- == 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 thomasmckay at redhat.com Wed Oct 24 18:38:28 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 24 Oct 2012 14:38:28 -0400 (EDT) Subject: [katello-devel] automated testing, who's doing what? (was: Re: Merging and Pulling with no wait) In-Reply-To: <471761589.1425569.1351103554678.JavaMail.root@redhat.com> Message-ID: <683364440.11979976.1351103908968.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Jeff Weiss" > To: "Lukas Zapletal" > Cc: katello-devel at redhat.com > Sent: Wednesday, October 24, 2012 2:32:34 PM > Subject: Re: [katello-devel] Merging and Pulling with no wait > > We did have a lengthy and productive discussion related to this > problem at the QE Summit in Brno last week. > > I think the major takeaway from that is, we want automated tests > running on changes BEFORE they hit master, not only after. > > So what we'll be working towards is some system whereby Pull Requests > are tested, and some kind of feedback of the automated test results > will be posted to the PR comments. > > This process should take less than 1 hour after the PR is submitted. > I was planning on using Jenkins, since aside from the PR > interaction, the steps are exactly the same as what we do for master > today: > > 1) build rpms from the commit we want to test > 2) Install them on fresh vm > 3) Run automation against vm > > We just need to add > 0) Monitor PR's > 4) Add feedback to PR > > > > -Jeff > Is everyone working together on the automation stuff or individually? Jeff, are you working with Lukas and Eric? I hope we're pooling resources and efforts. > ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, October 24, 2012 5:07:21 AM > Subject: Re: [katello-devel] Merging and Pulling with no wait > > On Tue, Oct 23, 2012 at 03:59:29PM -0600, Jason Rist wrote: > > Tom - you know, I totally agree with you. I hadn't really thought > > of > > the Ozzak/Travis stuff that @ehelms and @lzap had been working on, > > but > > obviously it didn't catch Adam's pylint error, so it's not perfect. > > Perhaps I jumped the gun sending my email out, but my main goal is > > to > > make the product stable each and every check-in. Education is > > great, > > and I like that side of pull-requests, but it's not the primary > > reason > > for my concern. Plus, there is nothing stopping someone from > > viewing > > the committed files via the closed pull request. > > > > Just to fine-tune the information - Erik is working on > TravicCI-Github > integration and I am just helping him to integrate the new Gemfile. > And > it is looking good. No other works on Ozzak, I turned it off because > I > thought Eric is done (but he is still tuning the stuff). No more > Ozzak, > expect big announcement very soon :-) I want to change ozzak script > to > run koji scratch builds against git pull requests. > > The git pull you picked as an example is not a good example of > request > that should be put on hold for 24 hours. We have having annoying > amount > of "fuzzy i18n messages" during our unit test runs and it was > literally > blocking Eric from doing anything on Travis (because what you get is > 10 > MB log which does not pretty work with all that javascript that is on > Travis). And that was reason for the quick merge. > > I agree with you that for *important* changes we should not do this > and > let everyone to read the patch, but I am totally fine with > quick-merging > those tiny things, blockers and cosmetic changes. One can always rise > his hand even after a pull request was merged and if the objections > are > reasonable - yes - we have the revert thing. > > I have to admit I raised this topic for the first time, but it was > after > I saw several big merges I was not totally comfortable with. > > Let's agree on that and if you (or anyone) encounter a "fast&bad" > merge, > just scream in the comments. > > -- > 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 ehelms at redhat.com Wed Oct 24 18:51:23 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 24 Oct 2012 14:51:23 -0400 Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <471761589.1425569.1351103554678.JavaMail.root@redhat.com> References: <471761589.1425569.1351103554678.JavaMail.root@redhat.com> Message-ID: <508838AB.8020204@redhat.com> For your information, working with Lukas, we have put together a Travis config that will run on every pull request and every update to a pull request the following: - CLI unit tests - pylint - SCSS compilation - RSpec unit tests And run them against both Ruby 1.8.7 and Ruby 1.9.3 Figuring out how to incorporate testing RPM builds and installation will make the pull request testing more robust. As long as what is output to the pull request does not contain closed door links and provides developers with meaningful information on how to solve their problems. Jeff, I have done some prior investigation into Jenkins with pull requests if you want to compare notes at any point. -Eric On 10/24/2012 02:32 PM, Jeff Weiss wrote: > We did have a lengthy and productive discussion related to this problem at the QE Summit in Brno last week. > > I think the major takeaway from that is, we want automated tests running on changes BEFORE they hit master, not only after. > > So what we'll be working towards is some system whereby Pull Requests are tested, and some kind of feedback of the automated test results will be posted to the PR comments. > > This process should take less than 1 hour after the PR is submitted. I was planning on using Jenkins, since aside from the PR interaction, the steps are exactly the same as what we do for master today: > > 1) build rpms from the commit we want to test > 2) Install them on fresh vm > 3) Run automation against vm > > We just need to add > 0) Monitor PR's > 4) Add feedback to PR > > > -Jeff > > ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, October 24, 2012 5:07:21 AM > Subject: Re: [katello-devel] Merging and Pulling with no wait > > On Tue, Oct 23, 2012 at 03:59:29PM -0600, Jason Rist wrote: >> Tom - you know, I totally agree with you. I hadn't really thought of >> the Ozzak/Travis stuff that @ehelms and @lzap had been working on, but >> obviously it didn't catch Adam's pylint error, so it's not perfect. >> Perhaps I jumped the gun sending my email out, but my main goal is to >> make the product stable each and every check-in. Education is great, >> and I like that side of pull-requests, but it's not the primary reason >> for my concern. Plus, there is nothing stopping someone from viewing >> the committed files via the closed pull request. >> > Just to fine-tune the information - Erik is working on TravicCI-Github > integration and I am just helping him to integrate the new Gemfile. And > it is looking good. No other works on Ozzak, I turned it off because I > thought Eric is done (but he is still tuning the stuff). No more Ozzak, > expect big announcement very soon :-) I want to change ozzak script to > run koji scratch builds against git pull requests. > > The git pull you picked as an example is not a good example of request > that should be put on hold for 24 hours. We have having annoying amount > of "fuzzy i18n messages" during our unit test runs and it was literally > blocking Eric from doing anything on Travis (because what you get is 10 > MB log which does not pretty work with all that javascript that is on > Travis). And that was reason for the quick merge. > > I agree with you that for *important* changes we should not do this and > let everyone to read the patch, but I am totally fine with quick-merging > those tiny things, blockers and cosmetic changes. One can always rise > his hand even after a pull request was merged and if the objections are > reasonable - yes - we have the revert thing. > > I have to admit I raised this topic for the first time, but it was after > I saw several big merges I was not totally comfortable with. > > Let's agree on that and if you (or anyone) encounter a "fast&bad" merge, > just scream in the comments. > From daviddavis at redhat.com Wed Oct 24 19:51:07 2012 From: daviddavis at redhat.com (David Davis) Date: Wed, 24 Oct 2012 15:51:07 -0400 (EDT) Subject: [katello-devel] Content view filter logic Message-ID: <812586147.16991446.1351108267514.JavaMail.root@redhat.com> Here are my notes from today's meeting. Please review them and let me know what you all think and then I'll add them to the content view page on the wiki. 1. a. If there is no include filter (aka whitelist filter), everything is included. b. If there are no include filters and only exclude filters (aka blacklist filters), those exclude filters then run on all packages/errata. 2. If there is an include filter (aka whitelist) then only the packages/errata included will get included. Everything else is thus excluded. 3. If there are include and exclude filters, the exclude filters take presidence. That is to say the include filters get processed first, then the exclude filter excludes content from the set included by the include filters. Thanks! David From bkearney at redhat.com Wed Oct 24 20:04:45 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 24 Oct 2012 16:04:45 -0400 Subject: [katello-devel] Content view filter logic In-Reply-To: <812586147.16991446.1351108267514.JavaMail.root@redhat.com> References: <812586147.16991446.1351108267514.JavaMail.root@redhat.com> Message-ID: <508849DD.2090603@redhat.com> On 10/24/2012 03:51 PM, David Davis wrote: > Here are my notes from today's meeting. Please review them and let me know what you all think and then I'll add them to the content view page on the wiki. > > 1. a. If there is no include filter (aka whitelist filter), everything is included. > b. If there are no include filters and only exclude filters (aka blacklist filters), those exclude filters then run on all packages/errata. > > 2. If there is an include filter (aka whitelist) then only the packages/errata included will get included. Everything else is thus excluded. > > 3. If there are include and exclude filters, the exclude filters take presidence. That is to say the include filters get processed first, then the exclude filter excludes content from the set included by the include filters. > > Thanks! > Some other questions: 1) What does deleting a definition do to the views which have been promoted. 2) The refreshing a view concept is not 100 clear to me. Perhaps We can push off doing refresh now, or ceate "refresh only" content views. 3) For me, the relationship between errata and packages is not clear. if the filter excludes httpd, and includes all errata then what happens when an errata comes in with httpd? If I include only httpd, and include all errata what happens? 4) Justin says he has a solution, but I would like to understand how I would apply Errata X and Errata Y (both of which are RHEL 6.3 errata) onto the RHEL 6.2 content steam. Currently, 6.2 and 6.3 are unique repositories in a single product. -- bk From jsherril at redhat.com Wed Oct 24 20:29:00 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 24 Oct 2012 16:29:00 -0400 Subject: [katello-devel] Content view filter logic In-Reply-To: <508849DD.2090603@redhat.com> References: <812586147.16991446.1351108267514.JavaMail.root@redhat.com> <508849DD.2090603@redhat.com> Message-ID: <50884F8C.1030106@redhat.com> On 10/24/2012 04:04 PM, Bryan Kearney wrote: > On 10/24/2012 03:51 PM, David Davis wrote: >> Here are my notes from today's meeting. Please review them and let me >> know what you all think and then I'll add them to the content view >> page on the wiki. >> >> 1. a. If there is no include filter (aka whitelist filter), >> everything is included. >> b. If there are no include filters and only exclude filters (aka >> blacklist filters), those exclude filters then run on all >> packages/errata. >> >> 2. If there is an include filter (aka whitelist) then only the >> packages/errata included will get included. Everything else is thus >> excluded. >> >> 3. If there are include and exclude filters, the exclude filters take >> presidence. That is to say the include filters get processed first, >> then the exclude filter excludes content from the set included by the >> include filters. >> >> Thanks! >> > > Some other questions: > > 1) What does deleting a definition do to the views which have been > promoted. I don't think anything happens to the views. They stay where they are. > 2) The refreshing a view concept is not 100 clear to me. Perhaps We > can push off doing refresh now, or ceate "refresh only" content views. The idea is to regenerate all of the repositories. So we would probably wipe them all and recreate them (if thats easiest). We could push off doing refreshing, but as eric mentions that leaves around a lot of cruft. If a common workflow is: 1. Generate a new view 2. Promote new view to next environmnet 3. Migrate all systems from old view to new view 4. Delete old view in next environment 5. repeat for all environments You're introducing 2 additional steps for each environment. I think this will be more common that wanting to leave dozens of old views around. If we do push off refreshing, we need to make it VERY easy to move large numbers of systems around. We still need to make it easy regardless, but its much more important if you can't refresh the views. > 3) For me, the relationship between errata and packages is not clear. > if the filter excludes httpd, and includes all errata then what > happens when an errata comes in with httpd? If I include only httpd, > and include all errata what happens? So as I said, some discussion and brainstorming needs to be done around this. We intentionally didn't get into these details when we planned out this feature months ago just due to the detailed complexity. But for this case to me, if i exclude 'httpd' that should exclude any errata that only includes 'httpd', even if i have included it in my time frame. Goes back to the exclude filters take precedence. I would probably argue that we should only have 'package' excludes, no 'errata' or 'package group' excludes. > 4) Justin says he has a solution, but I would like to understand how I > would apply Errata X and Errata Y (both of which are RHEL 6.3 errata) > onto the RHEL 6.2 content steam. Currently, 6.2 and 6.3 are unique > repositories in a single product. 1. Create a content view definition 2. Add "Red hat enterprise linux product" with only "6Server" repo selected. 6Server will have all updates up until today. 3. Add a filter for the 6Server repo only including Errata up to 6.2's release date. 4. Add an additional filter that satisfies this user story: * As a user with administer privileges on Content View Definitions or modify privilege on a Content View Definition, I should be able to define an errata filter to whitelist errata by IDs. For Errata X & Errata Y. I'm not sure that this was shown in the mockups, but it needs to be added if its not there. 5. Publish view, promote, and subscribe a system. -Justin > > -- bk > > > _______________________________________________ > 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 bkearney at redhat.com Wed Oct 24 20:42:24 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 24 Oct 2012 16:42:24 -0400 Subject: [katello-devel] Content view filter logic In-Reply-To: <50884F8C.1030106@redhat.com> References: <812586147.16991446.1351108267514.JavaMail.root@redhat.com> <508849DD.2090603@redhat.com> <50884F8C.1030106@redhat.com> Message-ID: <508852B0.8040609@redhat.com> On 10/24/2012 04:29 PM, Justin Sherrill wrote: > On 10/24/2012 04:04 PM, Bryan Kearney wrote: >> On 10/24/2012 03:51 PM, David Davis wrote: >>> Here are my notes from today's meeting. Please review them and let me >>> know what you all think and then I'll add them to the content view >>> page on the wiki. >>> >>> 1. a. If there is no include filter (aka whitelist filter), >>> everything is included. >>> b. If there are no include filters and only exclude filters (aka >>> blacklist filters), those exclude filters then run on all >>> packages/errata. >>> >>> 2. If there is an include filter (aka whitelist) then only the >>> packages/errata included will get included. Everything else is thus >>> excluded. >>> >>> 3. If there are include and exclude filters, the exclude filters take >>> presidence. That is to say the include filters get processed first, >>> then the exclude filter excludes content from the set included by the >>> include filters. >>> >>> Thanks! >>> >> >> Some other questions: >> >> 1) What does deleting a definition do to the views which have been >> promoted. > I don't think anything happens to the views. They stay where > they are. > >> 2) The refreshing a view concept is not 100 clear to me. Perhaps We >> can push off doing refresh now, or ceate "refresh only" content views. > The idea is to regenerate all of the repositories. So we would > probably wipe them all and recreate them (if thats easiest). We could > push off doing refreshing, but as eric mentions that leaves around a lot > of cruft. > > If a common workflow is: > > 1. Generate a new view > 2. Promote new view to next environmnet > 3. Migrate all systems from old view to new view > 4. Delete old view in next environment > 5. repeat for all environments > > You're introducing 2 additional steps for each environment. I think > this will be more common that wanting to leave dozens of old views around. > > If we do push off refreshing, we need to make it VERY easy to move large > numbers of systems around. We still need to make it easy regardless, > but its much more important if you can't refresh the views. So,can we dothis at promotion then? Make part of the change set: promote this view, and move all system from that view to this view? That way, you make promotion decisions in one place, and content veiew definitions in another. > >> 3) For me, the relationship between errata and packages is not clear. >> if the filter excludes httpd, and includes all errata then what >> happens when an errata comes in with httpd? If I include only httpd, >> and include all errata what happens? > So as I said, some discussion and brainstorming needs to be done around > this. We intentionally didn't get into these details when we planned > out this feature months ago just due to the detailed complexity. But > for this case to me, if i exclude 'httpd' that should exclude any errata > that only includes 'httpd', even if i have included it in my time > frame. Goes back to the exclude filters take precedence. I would > probably argue that we should only have 'package' excludes, no 'errata' > or 'package group' excludes. Dunno.. need to think on this a bit. > > >> 4) Justin says he has a solution, but I would like to understand how I >> would apply Errata X and Errata Y (both of which are RHEL 6.3 errata) >> onto the RHEL 6.2 content steam. Currently, 6.2 and 6.3 are unique >> repositories in a single product. > 1. Create a content view definition > 2. Add "Red hat enterprise linux product" with only "6Server" repo > selected. 6Server will have all updates up until today. > 3. Add a filter for the 6Server repo only including Errata up to 6.2's > release date. > 4. Add an additional filter that satisfies this user story: > > * As a user with administer privileges on Content View Definitions or > modify privilege on a Content View Definition, I should be able to > define an errata filter to whitelist errata by IDs. Will folks know this date? I can see how this will work, but it seems cumbersome. It is probably good enough for v2.0 > > For Errata X & Errata Y. I'm not sure that this was shown in the > mockups, but it needs to be added if its not there. I did not see it, I only saw date range. > > 5. Publish view, promote, and subscribe a system. > > > -Justin > > >> >> -- 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 mmccune at redhat.com Wed Oct 24 20:51:29 2012 From: mmccune at redhat.com (Mike McCune) Date: Wed, 24 Oct 2012 13:51:29 -0700 Subject: [katello-devel] Content view filter logic In-Reply-To: <508852B0.8040609@redhat.com> References: <812586147.16991446.1351108267514.JavaMail.root@redhat.com> <508849DD.2090603@redhat.com> <50884F8C.1030106@redhat.com> <508852B0.8040609@redhat.com> Message-ID: <508854D1.9080507@redhat.com> On 10/24/2012 01:42 PM, Bryan Kearney wrote: > On 10/24/2012 04:29 PM, Justin Sherrill wrote: >> On 10/24/2012 04:04 PM, Bryan Kearney wrote: >>> On 10/24/2012 03:51 PM, David Davis wrote: >>>> Here are my notes from today's meeting. Please review them and let me >>>> know what you all think and then I'll add them to the content view >>>> page on the wiki. >>>> >>>> 1. a. If there is no include filter (aka whitelist filter), >>>> everything is included. >>>> b. If there are no include filters and only exclude filters (aka >>>> blacklist filters), those exclude filters then run on all >>>> packages/errata. >>>> >>>> 2. If there is an include filter (aka whitelist) then only the >>>> packages/errata included will get included. Everything else is thus >>>> excluded. >>>> >>>> 3. If there are include and exclude filters, the exclude filters take >>>> presidence. That is to say the include filters get processed first, >>>> then the exclude filter excludes content from the set included by the >>>> include filters. >>>> >>>> Thanks! >>>> >>> >>> Some other questions: >>> >>> 1) What does deleting a definition do to the views which have been >>> promoted. >> I don't think anything happens to the views. They stay where >> they are. >> >>> 2) The refreshing a view concept is not 100 clear to me. Perhaps We >>> can push off doing refresh now, or ceate "refresh only" content views. >> The idea is to regenerate all of the repositories. So we would >> probably wipe them all and recreate them (if thats easiest). We could >> push off doing refreshing, but as eric mentions that leaves around a lot >> of cruft. >> >> If a common workflow is: >> >> 1. Generate a new view >> 2. Promote new view to next environmnet >> 3. Migrate all systems from old view to new view >> 4. Delete old view in next environment >> 5. repeat for all environments >> >> You're introducing 2 additional steps for each environment. I think >> this will be more common that wanting to leave dozens of old views around. >> >> If we do push off refreshing, we need to make it VERY easy to move large >> numbers of systems around. We still need to make it easy regardless, >> but its much more important if you can't refresh the views. > > So,can we dothis at promotion then? Make part of the change set: > > promote this view, and move all system from that view to this view? That > way, you make promotion decisions in one place, and content veiew > definitions in another. > we could but if the view is baked into the client as a variable, similar to how we do with $ENV it may be hard todo. Would be easier to keep them pointed at the same thing which changes if you need it updated. >> >>> 3) For me, the relationship between errata and packages is not clear. >>> if the filter excludes httpd, and includes all errata then what >>> happens when an errata comes in with httpd? If I include only httpd, >>> and include all errata what happens? >> So as I said, some discussion and brainstorming needs to be done around >> this. We intentionally didn't get into these details when we planned >> out this feature months ago just due to the detailed complexity. But >> for this case to me, if i exclude 'httpd' that should exclude any errata >> that only includes 'httpd', even if i have included it in my time >> frame. Goes back to the exclude filters take precedence. I would >> probably argue that we should only have 'package' excludes, no 'errata' >> or 'package group' excludes. > > Dunno.. need to think on this a bit. > eventually you could offer the user a choice of precedence but I think our first attempt would go as Justin says: blacklisting beats whitelisting we could eventually offer policy where users could construct AND vs OR conditions when you stack filters to determine the venn-diagram of what is included within the view but I think the first time around we just code these conditions in with an eye for future flexibility. > >> >> >>> 4) Justin says he has a solution, but I would like to understand how I >>> would apply Errata X and Errata Y (both of which are RHEL 6.3 errata) >>> onto the RHEL 6.2 content steam. Currently, 6.2 and 6.3 are unique >>> repositories in a single product. >> 1. Create a content view definition >> 2. Add "Red hat enterprise linux product" with only "6Server" repo >> selected. 6Server will have all updates up until today. >> 3. Add a filter for the 6Server repo only including Errata up to 6.2's >> release date. >> 4. Add an additional filter that satisfies this user story: >> >> * As a user with administer privileges on Content View Definitions or >> modify privilege on a Content View Definition, I should be able to >> define an errata filter to whitelist errata by IDs. > > Will folks know this date? I can see how this will work, but it seems > cumbersome. It is probably good enough for v2.0 X.Y dates are not something we can know yet pragmatically. Users will have to follow announcements to calculate the date. I'd argue it is good enough for a first cut at this feature. Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From lzap at redhat.com Thu Oct 25 06:33:19 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 25 Oct 2012 08:33:19 +0200 Subject: [katello-devel] Merging and Pulling with no wait In-Reply-To: <508838AB.8020204@redhat.com> References: <471761589.1425569.1351103554678.JavaMail.root@redhat.com> <508838AB.8020204@redhat.com> Message-ID: <20121025063319.GA4752@lzapx.brq.redhat.com> I think we can roll out this version, RPM building is not what we can do in Travis and since Jeff has these plans - we would duplicate the effort. Until Jeff implements the stuff, I can run Koji builds from Ozzak. LZ On Wed, Oct 24, 2012 at 02:51:23PM -0400, Eric Helms wrote: > For your information, working with Lukas, we have put together a > Travis config that will run on every pull request and every update > to a pull request the following: > > - CLI unit tests > - pylint > - SCSS compilation > - RSpec unit tests > > And run them against both Ruby 1.8.7 and Ruby 1.9.3 > > Figuring out how to incorporate testing RPM builds and installation > will make the pull request testing more robust. As long as what is > output to the pull request does not contain closed door links and > provides developers with meaningful information on how to solve > their problems. > > Jeff, I have done some prior investigation into Jenkins with pull > requests if you want to compare notes at any point. > > -Eric > > On 10/24/2012 02:32 PM, Jeff Weiss wrote: > >We did have a lengthy and productive discussion related to this problem at the QE Summit in Brno last week. > > > >I think the major takeaway from that is, we want automated tests running on changes BEFORE they hit master, not only after. > > > >So what we'll be working towards is some system whereby Pull Requests are tested, and some kind of feedback of the automated test results will be posted to the PR comments. > > > >This process should take less than 1 hour after the PR is submitted. I was planning on using Jenkins, since aside from the PR interaction, the steps are exactly the same as what we do for master today: > > > >1) build rpms from the commit we want to test > >2) Install them on fresh vm > >3) Run automation against vm > > > >We just need to add > >0) Monitor PR's > >4) Add feedback to PR > > > > > >-Jeff > > > >----- Original Message ----- > >From: "Lukas Zapletal" > >To: katello-devel at redhat.com > >Sent: Wednesday, October 24, 2012 5:07:21 AM > >Subject: Re: [katello-devel] Merging and Pulling with no wait > > > >On Tue, Oct 23, 2012 at 03:59:29PM -0600, Jason Rist wrote: > >>Tom - you know, I totally agree with you. I hadn't really thought of > >>the Ozzak/Travis stuff that @ehelms and @lzap had been working on, but > >>obviously it didn't catch Adam's pylint error, so it's not perfect. > >>Perhaps I jumped the gun sending my email out, but my main goal is to > >>make the product stable each and every check-in. Education is great, > >>and I like that side of pull-requests, but it's not the primary reason > >>for my concern. Plus, there is nothing stopping someone from viewing > >>the committed files via the closed pull request. > >> > >Just to fine-tune the information - Erik is working on TravicCI-Github > >integration and I am just helping him to integrate the new Gemfile. And > >it is looking good. No other works on Ozzak, I turned it off because I > >thought Eric is done (but he is still tuning the stuff). No more Ozzak, > >expect big announcement very soon :-) I want to change ozzak script to > >run koji scratch builds against git pull requests. > > > >The git pull you picked as an example is not a good example of request > >that should be put on hold for 24 hours. We have having annoying amount > >of "fuzzy i18n messages" during our unit test runs and it was literally > >blocking Eric from doing anything on Travis (because what you get is 10 > >MB log which does not pretty work with all that javascript that is on > >Travis). And that was reason for the quick merge. > > > >I agree with you that for *important* changes we should not do this and > >let everyone to read the patch, but I am totally fine with quick-merging > >those tiny things, blockers and cosmetic changes. One can always rise > >his hand even after a pull request was merged and if the objections are > >reasonable - yes - we have the revert thing. > > > >I have to admit I raised this topic for the first time, but it was after > >I saw several big merges I was not totally comfortable with. > > > >Let's agree on that and if you (or anyone) encounter a "fast&bad" merge, > >just scream in the comments. > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From cperry at redhat.com Thu Oct 25 08:07:52 2012 From: cperry at redhat.com (Cliff Perry) Date: Thu, 25 Oct 2012 09:07:52 +0100 Subject: [katello-devel] Python books In-Reply-To: <5087EBB9.4040108@redhat.com> References: <1693365076.16743836.1351080692939.JavaMail.root@redhat.com> <1382882345.16743925.1351080721781.JavaMail.root@redhat.com> <20121024131508.GH13385@lzapx.brq.redhat.com> <5087EBB9.4040108@redhat.com> Message-ID: <5088F358.7050309@redhat.com> On 10/24/2012 02:23 PM, Eric Helms wrote: > No personal experience but http://learnpythonthehardway.org/ get's a lot > of good reviews. The Python documentation itself is quite good and I I did not think the above was for experienced programmers, looking to pick up another language. - My 10 yr old is on Chapter 24 of the above url, and he is enjoying it. I get to help him learn how to debug tracebacks ;) Cliff From jsherril at redhat.com Thu Oct 25 13:30:34 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 25 Oct 2012 09:30:34 -0400 Subject: [katello-devel] Content view filter logic In-Reply-To: <508852B0.8040609@redhat.com> References: <812586147.16991446.1351108267514.JavaMail.root@redhat.com> <508849DD.2090603@redhat.com> <50884F8C.1030106@redhat.com> <508852B0.8040609@redhat.com> Message-ID: <50893EFA.1080104@redhat.com> On 10/24/2012 04:42 PM, Bryan Kearney wrote: > On 10/24/2012 04:29 PM, Justin Sherrill wrote: >> On 10/24/2012 04:04 PM, Bryan Kearney wrote: >>> On 10/24/2012 03:51 PM, David Davis wrote: >>>> Here are my notes from today's meeting. Please review them and let me >>>> know what you all think and then I'll add them to the content view >>>> page on the wiki. >>>> >>>> 1. a. If there is no include filter (aka whitelist filter), >>>> everything is included. >>>> b. If there are no include filters and only exclude filters (aka >>>> blacklist filters), those exclude filters then run on all >>>> packages/errata. >>>> >>>> 2. If there is an include filter (aka whitelist) then only the >>>> packages/errata included will get included. Everything else is thus >>>> excluded. >>>> >>>> 3. If there are include and exclude filters, the exclude filters take >>>> presidence. That is to say the include filters get processed first, >>>> then the exclude filter excludes content from the set included by the >>>> include filters. >>>> >>>> Thanks! >>>> >>> >>> Some other questions: >>> >>> 1) What does deleting a definition do to the views which have been >>> promoted. >> I don't think anything happens to the views. They stay where >> they are. >> >>> 2) The refreshing a view concept is not 100 clear to me. Perhaps We >>> can push off doing refresh now, or ceate "refresh only" content views. >> The idea is to regenerate all of the repositories. So we would >> probably wipe them all and recreate them (if thats easiest). We could >> push off doing refreshing, but as eric mentions that leaves around a lot >> of cruft. >> >> If a common workflow is: >> >> 1. Generate a new view >> 2. Promote new view to next environmnet >> 3. Migrate all systems from old view to new view >> 4. Delete old view in next environment >> 5. repeat for all environments >> >> You're introducing 2 additional steps for each environment. I think >> this will be more common that wanting to leave dozens of old views >> around. >> >> If we do push off refreshing, we need to make it VERY easy to move large >> numbers of systems around. We still need to make it easy regardless, >> but its much more important if you can't refresh the views. > > So,can we dothis at promotion then? Make part of the change set: > > promote this view, and move all system from that view to this view? > That way, you make promotion decisions in one place, and content veiew > definitions in another. > >> >>> 3) For me, the relationship between errata and packages is not clear. >>> if the filter excludes httpd, and includes all errata then what >>> happens when an errata comes in with httpd? If I include only httpd, >>> and include all errata what happens? >> So as I said, some discussion and brainstorming needs to be done around >> this. We intentionally didn't get into these details when we planned >> out this feature months ago just due to the detailed complexity. But >> for this case to me, if i exclude 'httpd' that should exclude any errata >> that only includes 'httpd', even if i have included it in my time >> frame. Goes back to the exclude filters take precedence. I would >> probably argue that we should only have 'package' excludes, no 'errata' >> or 'package group' excludes. > > Dunno.. need to think on this a bit. > > >> >> >>> 4) Justin says he has a solution, but I would like to understand how I >>> would apply Errata X and Errata Y (both of which are RHEL 6.3 errata) >>> onto the RHEL 6.2 content steam. Currently, 6.2 and 6.3 are unique >>> repositories in a single product. >> 1. Create a content view definition >> 2. Add "Red hat enterprise linux product" with only "6Server" repo >> selected. 6Server will have all updates up until today. >> 3. Add a filter for the 6Server repo only including Errata up to 6.2's >> release date. >> 4. Add an additional filter that satisfies this user story: >> >> * As a user with administer privileges on Content View Definitions or >> modify privilege on a Content View Definition, I should be able to >> define an errata filter to whitelist errata by IDs. > > Will folks know this date? I can see how this will work, but it seems > cumbersome. It is probably good enough for v2.0 So for satellite customers they seemed smart enough to find this information. But it really gets down to when you say "6.2" what does that mean? Generally customers mean the package set when 6.2 is released. The "Rhel 6.2" repo does not give them this does it? From my understanding the 6.2 repo contains all package up to the release of RHEl 6.3. I'm not sure that this is really what customers want anyways. -Justin > >> >> For Errata X & Errata Y. I'm not sure that this was shown in the >> mockups, but it needs to be added if its not there. > > I did not see it, I only saw date range. > >> >> 5. Publish view, promote, and subscribe a system. >> >> >> -Justin >> >> >>> >>> -- 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 >> > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Thu Oct 25 14:54:17 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 25 Oct 2012 16:54:17 +0200 Subject: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 Ruby merged Message-ID: <20121025145417.GA31023@lzapx.brq.redhat.com> Hey all, after long testing and review I have merged the new Gemfile. Once you pull, please delete your Gemfile.lock and do "bundle install", now fetching from rubygems.org. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Thu Oct 25 14:59:08 2012 From: daviddavis at redhat.com (David Davis) Date: Thu, 25 Oct 2012 10:59:08 -0400 (EDT) Subject: [katello-devel] Checking in Gemfile.lock files Message-ID: <1173796156.17342307.1351177148239.JavaMail.root@redhat.com> I think we should add some new files to the project: src/gemfiles/Gemfilef16.lock src/gemfiles/Gemfilef17.lock src/gemfiles/Gemfilerhel6.lock That way, when I checkout the project, I can symlink in the Gemfile.lock for the system I am using: cd $KATELLO_HOME/src ln -s gemfiles/Gemfilef16.lock Gemfile.lock I think this has a lot of benefits: 1. We can still use rubygems and everyone on the same system will be using the same versions of the same gems. This ought to be the same as what's in the repos. 2. If someone updates the version of a gem, it has to be in the Gemfile.lock and it has to go through the same pull request process as the rest of our code. When we see a pull request that adds a new gem or updates a gem version, we can validate that the person has done the work to package it. 3. People don't have to use it if they don't want to, the project won't be shipped with a lock file by default, etc. 4. This helps to support different systems and there is a place in the project where I can check to see what gem version a system is using. Thanks. David From dmitri at redhat.com Thu Oct 25 15:01:22 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 25 Oct 2012 16:01:22 +0100 Subject: [katello-devel] Checking in Gemfile.lock files In-Reply-To: <1173796156.17342307.1351177148239.JavaMail.root@redhat.com> References: <1173796156.17342307.1351177148239.JavaMail.root@redhat.com> Message-ID: <50895442.4010202@redhat.com> On 25/10/12 03:59 PM, David Davis wrote: > I think we should add some new files to the project: > > src/gemfiles/Gemfilef16.lock > src/gemfiles/Gemfilef17.lock > src/gemfiles/Gemfilerhel6.lock > > That way, when I checkout the project, I can symlink in the Gemfile.lock for the system I am using: > > cd $KATELLO_HOME/src > ln -s gemfiles/Gemfilef16.lock Gemfile.lock > > I think this has a lot of benefits: > > 1. We can still use rubygems and everyone on the same system will be using the same versions of the same gems. This ought to be the same as what's in the repos. > 2. If someone updates the version of a gem, it has to be in the Gemfile.lock and it has to go through the same pull request process as the rest of our code. When we see a pull request that adds a new gem or updates a gem version, we can validate that the person has done the work to package it. > 3. People don't have to use it if they don't want to, the project won't be shipped with a lock file by default, etc. > 4. This helps to support different systems and there is a place in the project where I can check to see what gem version a system is using. > > Thanks. > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I think this is a must, as f16/rhel6 and f17 will have different Gemfile.lock. -d From lzap at redhat.com Thu Oct 25 15:13:12 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 25 Oct 2012 17:13:12 +0200 Subject: [katello-devel] Nightly builds In-Reply-To: <20121023150445.GY4702@lzapx.brq.redhat.com> References: <20121023150445.GY4702@lzapx.brq.redhat.com> Message-ID: <20121025151312.GD31023@lzapx.brq.redhat.com> It is okay, nightly builds are getting built automatically. FYI LZ On Tue, Oct 23, 2012 at 05:04:46PM +0200, Lukas Zapletal wrote: > Hey, > > I suspect Mirek's server which do the nigtly builds in koji is not > running due to power outage (migration) in Brno "minilab". If this is > confirmed tomorrow, I will keep building nightly builds very Brno > morning :-) > > Anyone can do this, by simply executing: > > ./rel-eng/build-missing-builds-in-koji.sh > > watching http://koji.katello.org/koji/tasks > > and waiting until new repo is created (4 times a day). > > It is very simple FYI ;-) > > LZ > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > 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 Oct 25 17:16:51 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 25 Oct 2012 13:16:51 -0400 (EDT) Subject: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 Ruby merged In-Reply-To: <20121025145417.GA31023@lzapx.brq.redhat.com> Message-ID: <1068512692.12412524.1351185411004.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Thursday, October 25, 2012 10:54:17 AM > Subject: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 Ruby merged > > Hey all, > > after long testing and review I have merged the new Gemfile. > > Once you pull, please delete your Gemfile.lock and do "bundle > install", > now fetching from rubygems.org. > > LZ > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > bundle install does not work for me for therubyracer make g++ -I. -I. -I/usr/lib64/ruby/1.8/x86_64-linux -I. -Wall -g -rdynamic -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing -fPIC -c v8_template.cpp In file included from rr.h:5, from v8_template.cpp:1: /usr/include/v8.h:1829: error: expected identifier before ?&? token make: *** [v8_template.o] Error 1 Gem files will remain installed in /home/tomckay/.bundler/tmp/1208/gems/therubyracer-0.8.2 for inspection. Results logged to /home/tomckay/.bundler/tmp/1208/gems/therubyracer-0.8.2/ext/v8/gem_make.out from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:509:in `each' from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:509:in `build_extensions' from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:180:in `install' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/source.rb:101:in `install' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/rubygems_integration.rb:78:in `preserve_paths' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/source.rb:91:in `install' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:58:in `run' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/rubygems_integration.rb:93:in `with_build_args' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:57:in `run' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:49:in `run' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:8:in `install' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/cli.rb:220:in `install' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in `send' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in `run' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor.rb:263:in `dispatch' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/base.rb:386:in `start' from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/bin/bundle:13 from /usr/bin/bundle:19:in `load' from /usr/bin/bundle:19 From jweiss at redhat.com Thu Oct 25 18:06:52 2012 From: jweiss at redhat.com (Jeff Weiss) Date: Thu, 25 Oct 2012 14:06:52 -0400 (EDT) Subject: [katello-devel] Need tools to diagnose performance issues Message-ID: <1365718278.2066946.1351188412344.JavaMail.root@redhat.com> Starting this week, I've been seeing terrible performance issues in katello/master. My test servers have a few dozen orgs, and deleting just one of them (with little or no content in it) sends a delayed-jobs thin process to 100% CPU for a solid 7 minutes. There are also performance issues with sync and manifest upload and possibly every async job - where even with 3 delayed jobs processes, these actions are suddenly taking many times longer than they did last week. Mike pointed out https://fedorahosted.org/katello/wiki/Profiling but I don't see how that is very useful since it doesn't seem to tell us which *Katello* classes are the bottleneck. Maybe it's useful if you're developing Rails itself. Or maybe it's configurable, I'm not sure. However, when Mike tried it, it coredumped. We're going to need some kind of story for profiling. Otherwise performance issues are going to accumulate without any efficient means to diagnose and fix them. -Jeff -- Jeff Weiss Principal Quality Assurance Engineer jweiss at redhat.com (919)886-6533 From kybaker at redhat.com Thu Oct 25 20:00:34 2012 From: kybaker at redhat.com (Kyle Baker) Date: Thu, 25 Oct 2012 16:00:34 -0400 (EDT) Subject: [katello-devel] Content Views Wireframes from Meeting 10-24-2012 In-Reply-To: <1927580194.2109350.1351195214564.JavaMail.root@redhat.com> Message-ID: <1530768557.2109493.1351195234024.JavaMail.root@redhat.com> This and future versions of the Content Views wireframes can be found on the Katello wiki - https://fedorahosted.org/katello/wiki/Content%20Views Kyle Baker --- UX Team Desk 978 392 3116 IRC kylebaker From kybaker at redhat.com Thu Oct 25 20:28:22 2012 From: kybaker at redhat.com (Kyle Baker) Date: Thu, 25 Oct 2012 16:28:22 -0400 (EDT) Subject: [katello-devel] Content view filter logic In-Reply-To: <50893EFA.1080104@redhat.com> Message-ID: <1652111295.2117970.1351196902258.JavaMail.root@redhat.com> Kyle Baker --- UX Team Desk 978 392 3116 IRC kylebaker ----- Original Message ----- > On 10/24/2012 04:42 PM, Bryan Kearney wrote: > > On 10/24/2012 04:29 PM, Justin Sherrill wrote: > >> On 10/24/2012 04:04 PM, Bryan Kearney wrote: > >>> On 10/24/2012 03:51 PM, David Davis wrote: > >>>> Here are my notes from today's meeting. Please review them and > >>>> let me > >>>> know what you all think and then I'll add them to the content > >>>> view > >>>> page on the wiki. > >>>> > >>>> 1. a. If there is no include filter (aka whitelist filter), > >>>> everything is included. > >>>> b. If there are no include filters and only exclude filters > >>>> (aka > >>>> blacklist filters), those exclude filters then run on all > >>>> packages/errata. > >>>> > >>>> 2. If there is an include filter (aka whitelist) then only the > >>>> packages/errata included will get included. Everything else is > >>>> thus > >>>> excluded. > >>>> > >>>> 3. If there are include and exclude filters, the exclude filters > >>>> take > >>>> presidence. That is to say the include filters get processed > >>>> first, > >>>> then the exclude filter excludes content from the set included > >>>> by the > >>>> include filters. > >>>> > >>>> Thanks! > >>>> > >>> > >>> Some other questions: > >>> > >>> 1) What does deleting a definition do to the views which have > >>> been > >>> promoted. > >> I don't think anything happens to the views. They stay > >> where > >> they are. > >> > >>> 2) The refreshing a view concept is not 100 clear to me. Perhaps > >>> We > >>> can push off doing refresh now, or ceate "refresh only" content > >>> views. > >> The idea is to regenerate all of the repositories. So we > >> would > >> probably wipe them all and recreate them (if thats easiest). We > >> could > >> push off doing refreshing, but as eric mentions that leaves around > >> a lot > >> of cruft. > >> > >> If a common workflow is: > >> > >> 1. Generate a new view > >> 2. Promote new view to next environmnet > >> 3. Migrate all systems from old view to new view > >> 4. Delete old view in next environment > >> 5. repeat for all environments > >> > >> You're introducing 2 additional steps for each environment. I > >> think > >> this will be more common that wanting to leave dozens of old views > >> around. > >> > >> If we do push off refreshing, we need to make it VERY easy to move > >> large > >> numbers of systems around. We still need to make it easy > >> regardless, > >> but its much more important if you can't refresh the views. > > > > So,can we dothis at promotion then? Make part of the change set: > > > > promote this view, and move all system from that view to this view? > > That way, you make promotion decisions in one place, and content > > veiew > > definitions in another. > > > >> > >>> 3) For me, the relationship between errata and packages is not > >>> clear. > >>> if the filter excludes httpd, and includes all errata then what > >>> happens when an errata comes in with httpd? If I include only > >>> httpd, > >>> and include all errata what happens? > >> So as I said, some discussion and brainstorming needs to be done > >> around > >> this. We intentionally didn't get into these details when we > >> planned > >> out this feature months ago just due to the detailed complexity. > >> But > >> for this case to me, if i exclude 'httpd' that should exclude any > >> errata > >> that only includes 'httpd', even if i have included it in my time > >> frame. Goes back to the exclude filters take precedence. I > >> would > >> probably argue that we should only have 'package' excludes, no > >> 'errata' > >> or 'package group' excludes. > > > > Dunno.. need to think on this a bit. > > > > > >> > >> > >>> 4) Justin says he has a solution, but I would like to understand > >>> how I > >>> would apply Errata X and Errata Y (both of which are RHEL 6.3 > >>> errata) > >>> onto the RHEL 6.2 content steam. Currently, 6.2 and 6.3 are > >>> unique > >>> repositories in a single product. > >> 1. Create a content view definition > >> 2. Add "Red hat enterprise linux product" with only "6Server" > >> repo > >> selected. 6Server will have all updates up until today. > >> 3. Add a filter for the 6Server repo only including Errata up to > >> 6.2's > >> release date. > >> 4. Add an additional filter that satisfies this user story: > >> > >> * As a user with administer privileges on Content View > >> Definitions or > >> modify privilege on a Content View Definition, I should be > >> able to > >> define an errata filter to whitelist errata by IDs. > > > > Will folks know this date? I can see how this will work, but it > > seems > > cumbersome. It is probably good enough for v2.0 > > So for satellite customers they seemed smart enough to find this > information. But it really gets down to when you say "6.2" what does > that mean? Generally customers mean the package set when 6.2 is > released. The "Rhel 6.2" repo does not give them this does it? From > my > understanding the 6.2 repo contains all package up to the release of > RHEl 6.3. I'm not sure that this is really what customers want > anyways. [Kyle] Can we give the user the choice to specify errata which are included, excluded, date/type, or for a specific product. When a user chooses a specific product it could pre-populate a whitelist of the errata pushed for that product. > > -Justin > > > > >> > >> For Errata X & Errata Y. I'm not sure that this was shown in the > >> mockups, but it needs to be added if its not there. > > > > I did not see it, I only saw date range. [Kyle] In the wireframes the user can specify errata which are included, excluded, by date. I only showed the detail view for date and type. > > > >> > >> 5. Publish view, promote, and subscribe a system. > >> > >> > >> -Justin > >> > >> > >>> > >>> -- 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 > >> > > > > _______________________________________________ > > 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 Fri Oct 26 09:15:54 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 26 Oct 2012 11:15:54 +0200 Subject: [katello-devel] Checking in Gemfile.lock files In-Reply-To: <1173796156.17342307.1351177148239.JavaMail.root@redhat.com> References: <1173796156.17342307.1351177148239.JavaMail.root@redhat.com> Message-ID: <20121026091554.GB3926@lzapx.brq.redhat.com> > I think we should add some new files to the project: > > src/gemfiles/Gemfilef16.lock > src/gemfiles/Gemfilef17.lock > src/gemfiles/Gemfilerhel6.lock > In the pull request I see this: src/gemfiles/Gemfile.lock src/gemfiles/Gemfilef16.lock src/gemfiles/Gemfilerhel6.lock I like what you propose in this mail rather than having "generic" one in that directory. I mean, instead Gemfile.lock I would expect Gemfilef17.lock. Also I vote for different pattern - something like Gemfile.f17.lock which is more readable. > 3. People don't have to use it if they don't want to, the project won't be shipped with a lock file by default, etc. > 4. This helps to support different systems and there is a place in the project where I can check to see what gem version a system is using. Please make sure you build RPM and katello is installable and runnable. It should not be problem, I believe we do not distribute the lock file. -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Fri Oct 26 10:04:25 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 26 Oct 2012 11:04:25 +0100 Subject: [katello-devel] Need tools to diagnose performance issues In-Reply-To: <1365718278.2066946.1351188412344.JavaMail.root@redhat.com> References: <1365718278.2066946.1351188412344.JavaMail.root@redhat.com> Message-ID: <508A6029.9080107@redhat.com> I just used ruby-profiler for figuring out tests performance issues, although not the version specified in the Gemfile, but rather rdp-ruby-prof. It works. Also see [1] for some helpful advice on performance testing of rails. Let me know if you need help with that. -d [1]. http://guides.rubyonrails.org/performance_testing.html On 25/10/12 07:06 PM, Jeff Weiss wrote: > Starting this week, I've been seeing terrible performance issues in katello/master. > > My test servers have a few dozen orgs, and deleting just one of them (with little or no content in it) sends a delayed-jobs thin process to 100% CPU for a solid 7 minutes. > > There are also performance issues with sync and manifest upload and possibly every async job - where even with 3 delayed jobs processes, these actions are suddenly taking many times longer than they did last week. > > Mike pointed out https://fedorahosted.org/katello/wiki/Profiling but I don't see how that is very useful since it doesn't seem to tell us which *Katello* classes are the bottleneck. Maybe it's useful if you're developing Rails itself. Or maybe it's configurable, I'm not sure. > > However, when Mike tried it, it coredumped. > > We're going to need some kind of story for profiling. Otherwise performance issues are going to accumulate without any efficient means to diagnose and fix them. > > -Jeff > > -- > Jeff Weiss > Principal Quality Assurance Engineer > jweiss at redhat.com > (919)886-6533 > > _______________________________________________ > 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 lzap at redhat.com Fri Oct 26 10:05:24 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 26 Oct 2012 12:05:24 +0200 Subject: [katello-devel] Katello upgrade redesign Message-ID: <20121026100524.GC3926@lzapx.brq.redhat.com> Hello, working on https://bugzilla.redhat.com/show_bug.cgi?id=868916 , I found we have some bugs and also design issues with katello upgrade. The current design is simple, we have two kinds of upgrade scripts which are in two directories. /usr/share/katello/install/upgrade-scripts/default/* and /usr/share/katello/install/upgrade-scripts/upgrade/* Katello-upgrade first shuts downs all the services and then starts upgrading by calling upgrade scripts in this order: default, upgrade. Default scripts are executed every katello-upgrade call, while upgrade scripts are only executed once (and then katello-upgrade "marks" them in the /var/lib/katello/upgrade-history file (just a list of files which have been already executed). Default scripts (executed every time) are: 0002_update_pulp.sh - starts mongod - does pulp-migrate 0003_update_candlepin.sh - executes dpdb 0004_migrate_katello_db.s - starts candlepin and elasticsearch - runs katello migration Upgrade scripts (executed only once) are: (none for CFSE 1.0/1.1 - just two examples that does nothing) 0001_preallocate_mongo.sh - prepares mongo journal for new version of mongo 0002_create_foreman_user - creates foreman user Now there are couple of issues which are blockers for CFSE 1.1 and couple of design issues I would like to also fix for Katello. Basically katello-upgrade currently does not work in CFSE 1.1 because we have some code logic in the migration scripts (filters) which require all the backend engines to be running. We are not starting pulp and also elasticsearch starts slowly and we need to wait until it is available. Also there are couple of example migration scripts which does nothing, but creating pyc/pyo bytecode files which are then added to the executed list. I will remove them and make sure python scripts does not create those. That is necessary for CFSE 1.1 upgrades, now for Katello we have a design issue. Some scripts need the services to be running (like pulp migration), others must not have services running (candlepin migration). Therefore for Katello, I plan to split our upgrade scripts into two categories (by script numbers): 0001-2999: Will be executed when backend engines are down 3000-5999: Will be executed when backend engines are up 6000-9999: Will be executed when backend engines and Katello are up This will be the same for both default and upgrade scripts. It would look (default scripts) like: 0001_stop_all_services 0010_migrate_candlepin 3000_start_backend_engines 3010_migrate_pulp 3020_migrate_katello 6000_start_katello Please note I am not increasing numbers by one, but by ten. REMEMBER BASIC? Then you know the reason for that (we will be adding foreman there soon). This way we will be able to put a script (either defaul or upgrade - one execution only) into the desired phase easily. In short, this is the todo: CFSE 1.1 issues (blockers): - services should be ALL started before katello db migration - elasticsearch start is not blocking (start is slow and we need to wait) - python example scripts are creating pyc/pyo objects in the upgrade folder Katello issues (non-blockers but MUSTFIX for the next release): - split the migration (both default and upgrade) into phases - no way of executing custom scripts before and after services are up - 0002_create_foreman_users script is missing header - make sure python scripts are not creating pyc/pyo files - numbering for default scrits should be loose (0001-0004 is too tight) - assumeyes option does not work - help page and man page are not complete - write README file with tutorial how to create migration script I am working on the fix for that bug (first part) and also adding the latter on the backlog. Discuss -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Fri Oct 26 10:06:28 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 26 Oct 2012 11:06:28 +0100 Subject: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 Ruby merged In-Reply-To: <1068512692.12412524.1351185411004.JavaMail.root@redhat.com> References: <1068512692.12412524.1351185411004.JavaMail.root@redhat.com> Message-ID: <508A60A4.6030701@redhat.com> I didn't have time to figure out the exact problem, running 'gem install therubyracer' works, and bundle install completes successfully after that. -d On 25/10/12 06:16 PM, Tom McKay wrote: > > ----- Original Message ----- >> From: "Lukas Zapletal" >> To: katello-devel at redhat.com >> Sent: Thursday, October 25, 2012 10:54:17 AM >> Subject: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 Ruby merged >> >> Hey all, >> >> after long testing and review I have merged the new Gemfile. >> >> Once you pull, please delete your Gemfile.lock and do "bundle >> install", >> now fetching from rubygems.org. >> >> LZ >> >> -- >> Later, >> >> Lukas "lzap" Zapletal >> #katello #systemengine >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > bundle install does not work for me for therubyracer > > > make > g++ -I. -I. -I/usr/lib64/ruby/1.8/x86_64-linux -I. -Wall -g -rdynamic -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing -fPIC -c v8_template.cpp > In file included from rr.h:5, > from v8_template.cpp:1: > /usr/include/v8.h:1829: error: expected identifier before ?&? token > make: *** [v8_template.o] Error 1 > > > Gem files will remain installed in /home/tomckay/.bundler/tmp/1208/gems/therubyracer-0.8.2 for inspection. > Results logged to /home/tomckay/.bundler/tmp/1208/gems/therubyracer-0.8.2/ext/v8/gem_make.out > from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:509:in `each' > from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:509:in `build_extensions' > from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:180:in `install' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/source.rb:101:in `install' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/rubygems_integration.rb:78:in `preserve_paths' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/source.rb:91:in `install' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:58:in `run' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/rubygems_integration.rb:93:in `with_build_args' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:57:in `run' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:49:in `run' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:8:in `install' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/cli.rb:220:in `install' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in `send' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in `run' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor.rb:263:in `dispatch' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/base.rb:386:in `start' > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/bin/bundle:13 > from /usr/bin/bundle:19:in `load' > from /usr/bin/bundle:19 > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Fri Oct 26 10:19:20 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 26 Oct 2012 12:19:20 +0200 Subject: [katello-devel] Need tools to diagnose performance issues In-Reply-To: <1365718278.2066946.1351188412344.JavaMail.root@redhat.com> References: <1365718278.2066946.1351188412344.JavaMail.root@redhat.com> Message-ID: <20121026101919.GD3926@lzapx.brq.redhat.com> http://lukas.zapletalovi.com/2012/01/probing-ruby-apps-with-systemtap-in.html http://lukas.zapletalovi.com/2012/02/peek-into-your-ruby-app-with-systemtap.html If there is no volunteer, I can try to find what is wrong. Can you just give me the box with the reproducer? The nicest thing about SystemTap is I can profile production mode machines - I just need to install systemtap and to compile a kernel module. LZ On Thu, Oct 25, 2012 at 02:06:52PM -0400, Jeff Weiss wrote: > Starting this week, I've been seeing terrible performance issues in katello/master. > > My test servers have a few dozen orgs, and deleting just one of them (with little or no content in it) sends a delayed-jobs thin process to 100% CPU for a solid 7 minutes. > > There are also performance issues with sync and manifest upload and possibly every async job - where even with 3 delayed jobs processes, these actions are suddenly taking many times longer than they did last week. > > Mike pointed out https://fedorahosted.org/katello/wiki/Profiling but I don't see how that is very useful since it doesn't seem to tell us which *Katello* classes are the bottleneck. Maybe it's useful if you're developing Rails itself. Or maybe it's configurable, I'm not sure. > > However, when Mike tried it, it coredumped. > > We're going to need some kind of story for profiling. Otherwise performance issues are going to accumulate without any efficient means to diagnose and fix them. > > -Jeff > > -- > Jeff Weiss > Principal Quality Assurance Engineer > jweiss at redhat.com > (919)886-6533 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Fri Oct 26 12:13:59 2012 From: daviddavis at redhat.com (David Davis) Date: Fri, 26 Oct 2012 08:13:59 -0400 (EDT) Subject: [katello-devel] Fedora 17 Gemfile.lock Message-ID: <510144918.17742820.1351253639607.JavaMail.root@redhat.com> Hi all, I'm adding Gemfile.lock files into version control so we can ensure we're all using the same gem versions per OS. This should also allow us to code review gem version changes in addition to gems being added. I still need a Gemfile.lock for Fedora 17. I would prefer on that is up to date (i.e. it must be pointing to rubygems.org and it must not contain ruport). Thanks. David From daviddavis at redhat.com Fri Oct 26 12:18:09 2012 From: daviddavis at redhat.com (David Davis) Date: Fri, 26 Oct 2012 08:18:09 -0400 (EDT) Subject: [katello-devel] Checking in Gemfile.lock files In-Reply-To: <20121026091554.GB3926@lzapx.brq.redhat.com> Message-ID: <1019421713.17743821.1351253889801.JavaMail.root@redhat.com> I'm working on adding the Gemfile.lock for F17. I think I like the Gemfile.xxx.lock pattern too so I'll make that change. Also, I don't think this should affect the build at all since the Gemfile.lock is only being symlinked into place in development (via devsetup). I could certainly have it symlinked into place during build/install though in which case I would test it out. Thanks. David ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Friday, October 26, 2012 5:15:54 AM > Subject: Re: [katello-devel] Checking in Gemfile.lock files > > > I think we should add some new files to the project: > > > > src/gemfiles/Gemfilef16.lock > > src/gemfiles/Gemfilef17.lock > > src/gemfiles/Gemfilerhel6.lock > > > > In the pull request I see this: > > src/gemfiles/Gemfile.lock > src/gemfiles/Gemfilef16.lock > src/gemfiles/Gemfilerhel6.lock > > I like what you propose in this mail rather than having "generic" one > in > that directory. I mean, instead Gemfile.lock I would expect > Gemfilef17.lock. > > Also I vote for different pattern - something like Gemfile.f17.lock > which is more readable. > > > 3. People don't have to use it if they don't want to, the project > > won't be shipped with a lock file by default, etc. > > 4. This helps to support different systems and there is a place in > > the project where I can check to see what gem version a system is > > using. > > Please make sure you build RPM and katello is installable and > runnable. > It should not be problem, I believe we do not distribute the lock > file. > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From bkearney at redhat.com Fri Oct 26 12:22:49 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 26 Oct 2012 08:22:49 -0400 Subject: [katello-devel] Content view filter logic In-Reply-To: <50893EFA.1080104@redhat.com> References: <812586147.16991446.1351108267514.JavaMail.root@redhat.com> <508849DD.2090603@redhat.com> <50884F8C.1030106@redhat.com> <508852B0.8040609@redhat.com> <50893EFA.1080104@redhat.com> Message-ID: <508A8099.9090507@redhat.com> On 10/25/2012 09:30 AM, Justin Sherrill wrote: > On 10/24/2012 04:42 PM, Bryan Kearney wrote: >> On 10/24/2012 04:29 PM, Justin Sherrill wrote: >>> On 10/24/2012 04:04 PM, Bryan Kearney wrote: >>>> On 10/24/2012 03:51 PM, David Davis wrote: >>>>> Here are my notes from today's meeting. Please review them and let me >>>>> know what you all think and then I'll add them to the content view >>>>> page on the wiki. >>>>> >>>>> 1. a. If there is no include filter (aka whitelist filter), >>>>> everything is included. >>>>> b. If there are no include filters and only exclude filters (aka >>>>> blacklist filters), those exclude filters then run on all >>>>> packages/errata. >>>>> >>>>> 2. If there is an include filter (aka whitelist) then only the >>>>> packages/errata included will get included. Everything else is thus >>>>> excluded. >>>>> >>>>> 3. If there are include and exclude filters, the exclude filters take >>>>> presidence. That is to say the include filters get processed first, >>>>> then the exclude filter excludes content from the set included by the >>>>> include filters. >>>>> >>>>> Thanks! >>>>> >>>> >>>> Some other questions: >>>> >>>> 1) What does deleting a definition do to the views which have been >>>> promoted. >>> I don't think anything happens to the views. They stay where >>> they are. >>> >>>> 2) The refreshing a view concept is not 100 clear to me. Perhaps We >>>> can push off doing refresh now, or ceate "refresh only" content views. >>> The idea is to regenerate all of the repositories. So we would >>> probably wipe them all and recreate them (if thats easiest). We could >>> push off doing refreshing, but as eric mentions that leaves around a lot >>> of cruft. >>> >>> If a common workflow is: >>> >>> 1. Generate a new view >>> 2. Promote new view to next environmnet >>> 3. Migrate all systems from old view to new view >>> 4. Delete old view in next environment >>> 5. repeat for all environments >>> >>> You're introducing 2 additional steps for each environment. I think >>> this will be more common that wanting to leave dozens of old views >>> around. >>> >>> If we do push off refreshing, we need to make it VERY easy to move large >>> numbers of systems around. We still need to make it easy regardless, >>> but its much more important if you can't refresh the views. >> >> So,can we dothis at promotion then? Make part of the change set: >> >> promote this view, and move all system from that view to this view? >> That way, you make promotion decisions in one place, and content veiew >> definitions in another. >> >>> >>>> 3) For me, the relationship between errata and packages is not clear. >>>> if the filter excludes httpd, and includes all errata then what >>>> happens when an errata comes in with httpd? If I include only httpd, >>>> and include all errata what happens? >>> So as I said, some discussion and brainstorming needs to be done around >>> this. We intentionally didn't get into these details when we planned >>> out this feature months ago just due to the detailed complexity. But >>> for this case to me, if i exclude 'httpd' that should exclude any errata >>> that only includes 'httpd', even if i have included it in my time >>> frame. Goes back to the exclude filters take precedence. I would >>> probably argue that we should only have 'package' excludes, no 'errata' >>> or 'package group' excludes. >> >> Dunno.. need to think on this a bit. >> >> >>> >>> >>>> 4) Justin says he has a solution, but I would like to understand how I >>>> would apply Errata X and Errata Y (both of which are RHEL 6.3 errata) >>>> onto the RHEL 6.2 content steam. Currently, 6.2 and 6.3 are unique >>>> repositories in a single product. >>> 1. Create a content view definition >>> 2. Add "Red hat enterprise linux product" with only "6Server" repo >>> selected. 6Server will have all updates up until today. >>> 3. Add a filter for the 6Server repo only including Errata up to 6.2's >>> release date. >>> 4. Add an additional filter that satisfies this user story: >>> >>> * As a user with administer privileges on Content View Definitions or >>> modify privilege on a Content View Definition, I should be able to >>> define an errata filter to whitelist errata by IDs. >> >> Will folks know this date? I can see how this will work, but it seems >> cumbersome. It is probably good enough for v2.0 > > So for satellite customers they seemed smart enough to find this > information. But it really gets down to when you say "6.2" what does > that mean? Generally customers mean the package set when 6.2 is > released. The "Rhel 6.2" repo does not give them this does it? From my > understanding the 6.2 repo contains all package up to the release of > RHEl 6.3. I'm not sure that this is really what customers want anyways. True.. it is closer but may not be exact. Per the earlier discussions, I think I am fine with this for 2.0. I think it gets us to maintenance windows which is a huge step forward. -- bk From thomasmckay at redhat.com Fri Oct 26 12:22:36 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 26 Oct 2012 08:22:36 -0400 (EDT) Subject: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 Ruby merged In-Reply-To: <508A60A4.6030701@redhat.com> Message-ID: <1703733902.12715787.1351254156844.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dmitri Dolguikh" > To: katello-devel at redhat.com > Sent: Friday, October 26, 2012 6:06:28 AM > Subject: Re: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 Ruby merged > > I didn't have time to figure out the exact problem, running 'gem > install > therubyracer' works, and bundle install completes successfully after > that. > -d > > On 25/10/12 06:16 PM, Tom McKay wrote: > > > > ----- Original Message ----- > >> From: "Lukas Zapletal" > >> To: katello-devel at redhat.com > >> Sent: Thursday, October 25, 2012 10:54:17 AM > >> Subject: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 > >> Ruby merged > >> > >> Hey all, > >> > >> after long testing and review I have merged the new Gemfile. > >> > >> Once you pull, please delete your Gemfile.lock and do "bundle > >> install", > >> now fetching from rubygems.org. > >> > >> LZ > >> > >> -- > >> Later, > >> > >> Lukas "lzap" Zapletal > >> #katello #systemengine > >> > >> _______________________________________________ > >> katello-devel mailing list > >> katello-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/katello-devel > >> > > bundle install does not work for me for therubyracer > > > > > > make > > g++ -I. -I. -I/usr/lib64/ruby/1.8/x86_64-linux -I. -Wall -g > > -rdynamic -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 > > -mtune=generic -fno-strict-aliasing -fPIC -c v8_template.cpp > > In file included from rr.h:5, > > from v8_template.cpp:1: > > /usr/include/v8.h:1829: error: expected identifier before ?&? token > > make: *** [v8_template.o] Error 1 > > > > > > Gem files will remain installed in > > /home/tomckay/.bundler/tmp/1208/gems/therubyracer-0.8.2 for > > inspection. > > Results logged to > > /home/tomckay/.bundler/tmp/1208/gems/therubyracer-0.8.2/ext/v8/gem_make.out > > from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:509:in > > `each' > > from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:509:in > > `build_extensions' > > from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:180:in > > `install' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/source.rb:101:in > > `install' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/rubygems_integration.rb:78:in > > `preserve_paths' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/source.rb:91:in > > `install' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:58:in > > `run' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/rubygems_integration.rb:93:in > > `with_build_args' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:57:in > > `run' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:49:in > > `run' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:8:in > > `install' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/cli.rb:220:in > > `install' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in > > `send' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in > > `run' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/invocation.rb:118:in > > `invoke_task' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor.rb:263:in > > `dispatch' > > from > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/base.rb:386:in > > `start' > > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/bin/bundle:13 > > from /usr/bin/bundle:19:in `load' > > from /usr/bin/bundle:19 > > > > > > > > _______________________________________________ > > 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 Succeeded w/ 'bundle install --without jshintrb' From daviddavis at redhat.com Fri Oct 26 12:29:43 2012 From: daviddavis at redhat.com (David Davis) Date: Fri, 26 Oct 2012 08:29:43 -0400 (EDT) Subject: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 Ruby merged In-Reply-To: <1703733902.12715787.1351254156844.JavaMail.root@redhat.com> Message-ID: <190104147.17746609.1351254583473.JavaMail.root@redhat.com> I think I was able to install therubyracer by yum installing v8 first. David ----- Original Message ----- > From: "Tom McKay" > To: "Dmitri Dolguikh" > Cc: katello-devel at redhat.com > Sent: Friday, October 26, 2012 8:22:36 AM > Subject: Re: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 Ruby merged > > > > ----- Original Message ----- > > From: "Dmitri Dolguikh" > > To: katello-devel at redhat.com > > Sent: Friday, October 26, 2012 6:06:28 AM > > Subject: Re: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and > > 1.9 Ruby merged > > > > I didn't have time to figure out the exact problem, running 'gem > > install > > therubyracer' works, and bundle install completes successfully > > after > > that. > > -d > > > > On 25/10/12 06:16 PM, Tom McKay wrote: > > > > > > ----- Original Message ----- > > >> From: "Lukas Zapletal" > > >> To: katello-devel at redhat.com > > >> Sent: Thursday, October 25, 2012 10:54:17 AM > > >> Subject: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 > > >> Ruby merged > > >> > > >> Hey all, > > >> > > >> after long testing and review I have merged the new Gemfile. > > >> > > >> Once you pull, please delete your Gemfile.lock and do "bundle > > >> install", > > >> now fetching from rubygems.org. > > >> > > >> LZ > > >> > > >> -- > > >> Later, > > >> > > >> Lukas "lzap" Zapletal > > >> #katello #systemengine > > >> > > >> _______________________________________________ > > >> katello-devel mailing list > > >> katello-devel at redhat.com > > >> https://www.redhat.com/mailman/listinfo/katello-devel > > >> > > > bundle install does not work for me for therubyracer > > > > > > > > > make > > > g++ -I. -I. -I/usr/lib64/ruby/1.8/x86_64-linux -I. -Wall -g > > > -rdynamic -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > > > -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 > > > -mtune=generic -fno-strict-aliasing -fPIC -c v8_template.cpp > > > In file included from rr.h:5, > > > from v8_template.cpp:1: > > > /usr/include/v8.h:1829: error: expected identifier before ?&? > > > token > > > make: *** [v8_template.o] Error 1 > > > > > > > > > Gem files will remain installed in > > > /home/tomckay/.bundler/tmp/1208/gems/therubyracer-0.8.2 for > > > inspection. > > > Results logged to > > > /home/tomckay/.bundler/tmp/1208/gems/therubyracer-0.8.2/ext/v8/gem_make.out > > > from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:509:in > > > `each' > > > from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:509:in > > > `build_extensions' > > > from /usr/lib/ruby/site_ruby/1.8/rubygems/installer.rb:180:in > > > `install' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/source.rb:101:in > > > `install' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/rubygems_integration.rb:78:in > > > `preserve_paths' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/source.rb:91:in > > > `install' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:58:in > > > `run' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/rubygems_integration.rb:93:in > > > `with_build_args' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:57:in > > > `run' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:49:in > > > `run' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/installer.rb:8:in > > > `install' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/cli.rb:220:in > > > `install' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in > > > `send' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/task.rb:22:in > > > `run' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/invocation.rb:118:in > > > `invoke_task' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor.rb:263:in > > > `dispatch' > > > from > > > /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/lib/bundler/vendor/thor/base.rb:386:in > > > `start' > > > from /usr/lib64/ruby/gems/1.8/gems/bundler-1.0.18/bin/bundle:13 > > > from /usr/bin/bundle:19:in `load' > > > from /usr/bin/bundle:19 > > > > > > > > > > > > _______________________________________________ > > > 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 > > Succeeded w/ 'bundle install --without jshintrb' > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From inecas at redhat.com Fri Oct 26 12:58:19 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Fri, 26 Oct 2012 14:58:19 +0200 Subject: [katello-devel] Fedora 17 Gemfile.lock In-Reply-To: <510144918.17742820.1351253639607.JavaMail.root@redhat.com> References: <510144918.17742820.1351253639607.JavaMail.root@redhat.com> Message-ID: <508A88EB.80204@redhat.com> On 10/26/2012 02:13 PM, David Davis wrote: > Hi all, > > I'm adding Gemfile.lock files into version control so we can ensure we're all using the same gem versions per OS. This should also allow us to code review gem version changes in addition to gems being added. I still need a Gemfile.lock for Fedora 17. I would prefer on that is up to date (i.e. it must be pointing to rubygems.org and it must not contain ruport). By saying the same gem versions per OS, you mean in case not system rubygems through yum are used, such as in rvm/rbenv, right? -- Ivan > > Thanks. > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Iva From bkearney at redhat.com Fri Oct 26 13:00:59 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 26 Oct 2012 09:00:59 -0400 Subject: [katello-devel] Fedora 17 Gemfile.lock In-Reply-To: <508A88EB.80204@redhat.com> References: <510144918.17742820.1351253639607.JavaMail.root@redhat.com> <508A88EB.80204@redhat.com> Message-ID: <508A898B.3030903@redhat.com> On 10/26/2012 08:58 AM, Ivan Ne?as wrote: > On 10/26/2012 02:13 PM, David Davis wrote: >> Hi all, >> >> I'm adding Gemfile.lock files into version control so we can ensure >> we're all using the same gem versions per OS. This should also allow >> us to code review gem version changes in addition to gems being added. >> I still need a Gemfile.lock for Fedora 17. I would prefer on that is >> up to date (i.e. it must be pointing to rubygems.org and it must not >> contain ruport). > By saying the same gem versions per OS, you mean in case not system > rubygems through yum are used, such as in rvm/rbenv, right? > please make sure that https://fedorahosted.org/katello/wiki/DevelopmentSetup is kept up2date. -- bk From bkearney at redhat.com Fri Oct 26 13:07:41 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 26 Oct 2012 09:07:41 -0400 Subject: [katello-devel] Katello upgrade redesign In-Reply-To: <20121026100524.GC3926@lzapx.brq.redhat.com> References: <20121026100524.GC3926@lzapx.brq.redhat.com> Message-ID: <508A8B1D.6040106@redhat.com> On 10/26/2012 06:05 AM, Lukas Zapletal wrote: > Hello, > > working on https://bugzilla.redhat.com/show_bug.cgi?id=868916 , I found we > have some bugs and also design issues with katello upgrade. > > The current design is simple, we have two kinds of upgrade scripts which > are in two directories. > > /usr/share/katello/install/upgrade-scripts/default/* > > and > > /usr/share/katello/install/upgrade-scripts/upgrade/* > > Katello-upgrade first shuts downs all the services and then starts > upgrading by calling upgrade scripts in this order: default, upgrade. > Default scripts are executed every katello-upgrade call, while upgrade > scripts are only executed once (and then katello-upgrade "marks" them in > the /var/lib/katello/upgrade-history file (just a list of files which > have been already executed). > > Default scripts (executed every time) are: > > 0002_update_pulp.sh > - starts mongod > - does pulp-migrate > 0003_update_candlepin.sh > - executes dpdb > 0004_migrate_katello_db.s > - starts candlepin and elasticsearch > - runs katello migration > > Upgrade scripts (executed only once) are: > > (none for CFSE 1.0/1.1 - just two examples that does nothing) > > 0001_preallocate_mongo.sh > - prepares mongo journal for new version of mongo > 0002_create_foreman_user > - creates foreman user > > Now there are couple of issues which are blockers for CFSE 1.1 and > couple of design issues I would like to also fix for Katello. > > Basically katello-upgrade currently does not work in CFSE 1.1 because we > have some code logic in the migration scripts (filters) which require > all the backend engines to be running. We are not starting pulp and also > elasticsearch starts slowly and we need to wait until it is available. > > Also there are couple of example migration scripts which does nothing, > but creating pyc/pyo bytecode files which are then added to the executed > list. I will remove them and make sure python scripts does not create > those. > > That is necessary for CFSE 1.1 upgrades, now for Katello we have a > design issue. Some scripts need the services to be running (like > pulp migration), others must not have services running (candlepin > migration). > > Therefore for Katello, I plan to split our upgrade scripts into two > categories (by script numbers): > > 0001-2999: Will be executed when backend engines are down > 3000-5999: Will be executed when backend engines are up > 6000-9999: Will be executed when backend engines and Katello are up > > This will be the same for both default and upgrade scripts. It would > look (default scripts) like: > > 0001_stop_all_services > 0010_migrate_candlepin > 3000_start_backend_engines > 3010_migrate_pulp > 3020_migrate_katello > 6000_start_katello I dont know if it matters.. but should we just do different directories, instead of using magic numbers? -- bk From inecas at redhat.com Fri Oct 26 13:16:36 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Fri, 26 Oct 2012 15:16:36 +0200 Subject: [katello-devel] Katello upgrade redesign In-Reply-To: <508A8B1D.6040106@redhat.com> References: <20121026100524.GC3926@lzapx.brq.redhat.com> <508A8B1D.6040106@redhat.com> Message-ID: <508A8D34.9030105@redhat.com> On 10/26/2012 03:07 PM, Bryan Kearney wrote: > On 10/26/2012 06:05 AM, Lukas Zapletal wrote: >> Hello, >> >> working on https://bugzilla.redhat.com/show_bug.cgi?id=868916 , I >> found we >> have some bugs and also design issues with katello upgrade. >> >> The current design is simple, we have two kinds of upgrade scripts which >> are in two directories. >> >> /usr/share/katello/install/upgrade-scripts/default/* >> >> and >> >> /usr/share/katello/install/upgrade-scripts/upgrade/* >> >> Katello-upgrade first shuts downs all the services and then starts >> upgrading by calling upgrade scripts in this order: default, upgrade. >> Default scripts are executed every katello-upgrade call, while upgrade >> scripts are only executed once (and then katello-upgrade "marks" them in >> the /var/lib/katello/upgrade-history file (just a list of files which >> have been already executed). >> >> Default scripts (executed every time) are: >> >> 0002_update_pulp.sh >> - starts mongod >> - does pulp-migrate >> 0003_update_candlepin.sh >> - executes dpdb >> 0004_migrate_katello_db.s >> - starts candlepin and elasticsearch >> - runs katello migration >> >> Upgrade scripts (executed only once) are: >> >> (none for CFSE 1.0/1.1 - just two examples that does nothing) >> >> 0001_preallocate_mongo.sh >> - prepares mongo journal for new version of mongo >> 0002_create_foreman_user >> - creates foreman user >> >> Now there are couple of issues which are blockers for CFSE 1.1 and >> couple of design issues I would like to also fix for Katello. >> >> Basically katello-upgrade currently does not work in CFSE 1.1 because we >> have some code logic in the migration scripts (filters) which require >> all the backend engines to be running. We are not starting pulp and also >> elasticsearch starts slowly and we need to wait until it is available. >> >> Also there are couple of example migration scripts which does nothing, >> but creating pyc/pyo bytecode files which are then added to the executed >> list. I will remove them and make sure python scripts does not create >> those. >> >> That is necessary for CFSE 1.1 upgrades, now for Katello we have a >> design issue. Some scripts need the services to be running (like >> pulp migration), others must not have services running (candlepin >> migration). >> >> Therefore for Katello, I plan to split our upgrade scripts into two >> categories (by script numbers): >> >> 0001-2999: Will be executed when backend engines are down >> 3000-5999: Will be executed when backend engines are up >> 6000-9999: Will be executed when backend engines and Katello are up >> >> This will be the same for both default and upgrade scripts. It would >> look (default scripts) like: >> >> 0001_stop_all_services >> 0010_migrate_candlepin >> 3000_start_backend_engines >> 3010_migrate_pulp >> 3020_migrate_katello >> 6000_start_katello > > I dont know if it matters.. but should we just do different > directories, instead of using magic numbers? If what this should solve is order of scripts, I can't see how directories help solving it, since the order in the subdirs should be specified as well. -- Ivan > > -- bk > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From bkearney at redhat.com Fri Oct 26 13:23:34 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 26 Oct 2012 09:23:34 -0400 Subject: [katello-devel] Katello upgrade redesign In-Reply-To: <508A8D34.9030105@redhat.com> References: <20121026100524.GC3926@lzapx.brq.redhat.com> <508A8B1D.6040106@redhat.com> <508A8D34.9030105@redhat.com> Message-ID: <508A8ED6.3040607@redhat.com> On 10/26/2012 09:16 AM, Ivan Ne?as wrote: > On 10/26/2012 03:07 PM, Bryan Kearney wrote: >> On 10/26/2012 06:05 AM, Lukas Zapletal wrote: >>> Hello, >>> >>> working on https://bugzilla.redhat.com/show_bug.cgi?id=868916 , I >>> found we >>> have some bugs and also design issues with katello upgrade. >>> >>> The current design is simple, we have two kinds of upgrade scripts which >>> are in two directories. >>> >>> /usr/share/katello/install/upgrade-scripts/default/* >>> >>> and >>> >>> /usr/share/katello/install/upgrade-scripts/upgrade/* >>> >>> Katello-upgrade first shuts downs all the services and then starts >>> upgrading by calling upgrade scripts in this order: default, upgrade. >>> Default scripts are executed every katello-upgrade call, while upgrade >>> scripts are only executed once (and then katello-upgrade "marks" them in >>> the /var/lib/katello/upgrade-history file (just a list of files which >>> have been already executed). >>> >>> Default scripts (executed every time) are: >>> >>> 0002_update_pulp.sh >>> - starts mongod >>> - does pulp-migrate >>> 0003_update_candlepin.sh >>> - executes dpdb >>> 0004_migrate_katello_db.s >>> - starts candlepin and elasticsearch >>> - runs katello migration >>> >>> Upgrade scripts (executed only once) are: >>> >>> (none for CFSE 1.0/1.1 - just two examples that does nothing) >>> >>> 0001_preallocate_mongo.sh >>> - prepares mongo journal for new version of mongo >>> 0002_create_foreman_user >>> - creates foreman user >>> >>> Now there are couple of issues which are blockers for CFSE 1.1 and >>> couple of design issues I would like to also fix for Katello. >>> >>> Basically katello-upgrade currently does not work in CFSE 1.1 because we >>> have some code logic in the migration scripts (filters) which require >>> all the backend engines to be running. We are not starting pulp and also >>> elasticsearch starts slowly and we need to wait until it is available. >>> >>> Also there are couple of example migration scripts which does nothing, >>> but creating pyc/pyo bytecode files which are then added to the executed >>> list. I will remove them and make sure python scripts does not create >>> those. >>> >>> That is necessary for CFSE 1.1 upgrades, now for Katello we have a >>> design issue. Some scripts need the services to be running (like >>> pulp migration), others must not have services running (candlepin >>> migration). >>> >>> Therefore for Katello, I plan to split our upgrade scripts into two >>> categories (by script numbers): >>> >>> 0001-2999: Will be executed when backend engines are down >>> 3000-5999: Will be executed when backend engines are up >>> 6000-9999: Will be executed when backend engines and Katello are up >>> >>> This will be the same for both default and upgrade scripts. It would >>> look (default scripts) like: >>> >>> 0001_stop_all_services >>> 0010_migrate_candlepin >>> 3000_start_backend_engines >>> 3010_migrate_pulp >>> 3020_migrate_katello >>> 6000_start_katello >> >> I dont know if it matters.. but should we just do different >> directories, instead of using magic numbers? > If what this should solve is order of scripts, I can't see how > directories help solving it, since the order in the subdirs should be > specified as well. You still need numbers in the directories, but then you dont need to remember that 3000 means after engines are up, instead you could see: after_engines_are_up -- bk From thomasmckay at redhat.com Fri Oct 26 13:23:33 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 26 Oct 2012 09:23:33 -0400 (EDT) Subject: [katello-devel] Katello upgrade redesign In-Reply-To: <508A8D34.9030105@redhat.com> Message-ID: <952094893.12738189.1351257813561.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ivan Ne?as" > To: katello-devel at redhat.com > Sent: Friday, October 26, 2012 9:16:36 AM > Subject: Re: [katello-devel] Katello upgrade redesign > > On 10/26/2012 03:07 PM, Bryan Kearney wrote: > > On 10/26/2012 06:05 AM, Lukas Zapletal wrote: > >> Hello, > >> > >> working on https://bugzilla.redhat.com/show_bug.cgi?id=868916 , I > >> found we > >> have some bugs and also design issues with katello upgrade. > >> > >> The current design is simple, we have two kinds of upgrade scripts > >> which > >> are in two directories. > >> > >> /usr/share/katello/install/upgrade-scripts/default/* > >> > >> and > >> > >> /usr/share/katello/install/upgrade-scripts/upgrade/* > >> > >> Katello-upgrade first shuts downs all the services and then starts > >> upgrading by calling upgrade scripts in this order: default, > >> upgrade. > >> Default scripts are executed every katello-upgrade call, while > >> upgrade > >> scripts are only executed once (and then katello-upgrade "marks" > >> them in > >> the /var/lib/katello/upgrade-history file (just a list of files > >> which > >> have been already executed). > >> > >> Default scripts (executed every time) are: > >> > >> 0002_update_pulp.sh > >> - starts mongod > >> - does pulp-migrate > >> 0003_update_candlepin.sh > >> - executes dpdb > >> 0004_migrate_katello_db.s > >> - starts candlepin and elasticsearch > >> - runs katello migration > >> > >> Upgrade scripts (executed only once) are: > >> > >> (none for CFSE 1.0/1.1 - just two examples that does nothing) > >> > >> 0001_preallocate_mongo.sh > >> - prepares mongo journal for new version of mongo > >> 0002_create_foreman_user > >> - creates foreman user > >> > >> Now there are couple of issues which are blockers for CFSE 1.1 and > >> couple of design issues I would like to also fix for Katello. > >> > >> Basically katello-upgrade currently does not work in CFSE 1.1 > >> because we > >> have some code logic in the migration scripts (filters) which > >> require > >> all the backend engines to be running. We are not starting pulp > >> and also > >> elasticsearch starts slowly and we need to wait until it is > >> available. > >> > >> Also there are couple of example migration scripts which does > >> nothing, > >> but creating pyc/pyo bytecode files which are then added to the > >> executed > >> list. I will remove them and make sure python scripts does not > >> create > >> those. > >> > >> That is necessary for CFSE 1.1 upgrades, now for Katello we have a > >> design issue. Some scripts need the services to be running (like > >> pulp migration), others must not have services running (candlepin > >> migration). > >> > >> Therefore for Katello, I plan to split our upgrade scripts into > >> two > >> categories (by script numbers): > >> > >> 0001-2999: Will be executed when backend engines are down > >> 3000-5999: Will be executed when backend engines are up > >> 6000-9999: Will be executed when backend engines and Katello are > >> up > >> > >> This will be the same for both default and upgrade scripts. It > >> would > >> look (default scripts) like: > >> > >> 0001_stop_all_services > >> 0010_migrate_candlepin > >> 3000_start_backend_engines > >> 3010_migrate_pulp > >> 3020_migrate_katello > >> 6000_start_katello > > > > I dont know if it matters.. but should we just do different > > directories, instead of using magic numbers? > If what this should solve is order of scripts, I can't see how > directories help solving it, since the order in the subdirs should be > specified as well. > > -- Ivan > > > > -- bk > > > > > > > > _______________________________________________ > > 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 > Will there never be a case where an upgrade w/o services needs to be run after an upgrade with services? Would it be simpler just to put the scripts in order in a single dir but include a meta tag in them that says what services have to be on/off? # elasticsearch=on # candlepin=off # pulp=off It may be slower overall, but I'd rather wait and know my upgrade worked. :) From inecas at redhat.com Fri Oct 26 13:28:33 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Fri, 26 Oct 2012 15:28:33 +0200 Subject: [katello-devel] Katello upgrade redesign In-Reply-To: <508A8ED6.3040607@redhat.com> References: <20121026100524.GC3926@lzapx.brq.redhat.com> <508A8B1D.6040106@redhat.com> <508A8D34.9030105@redhat.com> <508A8ED6.3040607@redhat.com> Message-ID: <508A9001.7020702@redhat.com> On 10/26/2012 03:23 PM, Bryan Kearney wrote: > On 10/26/2012 09:16 AM, Ivan Ne?as wrote: >> On 10/26/2012 03:07 PM, Bryan Kearney wrote: >>> On 10/26/2012 06:05 AM, Lukas Zapletal wrote: >>>> Hello, >>>> >>>> working on https://bugzilla.redhat.com/show_bug.cgi?id=868916 , I >>>> found we >>>> have some bugs and also design issues with katello upgrade. >>>> >>>> The current design is simple, we have two kinds of upgrade scripts >>>> which >>>> are in two directories. >>>> >>>> /usr/share/katello/install/upgrade-scripts/default/* >>>> >>>> and >>>> >>>> /usr/share/katello/install/upgrade-scripts/upgrade/* >>>> >>>> Katello-upgrade first shuts downs all the services and then starts >>>> upgrading by calling upgrade scripts in this order: default, upgrade. >>>> Default scripts are executed every katello-upgrade call, while upgrade >>>> scripts are only executed once (and then katello-upgrade "marks" >>>> them in >>>> the /var/lib/katello/upgrade-history file (just a list of files which >>>> have been already executed). >>>> >>>> Default scripts (executed every time) are: >>>> >>>> 0002_update_pulp.sh >>>> - starts mongod >>>> - does pulp-migrate >>>> 0003_update_candlepin.sh >>>> - executes dpdb >>>> 0004_migrate_katello_db.s >>>> - starts candlepin and elasticsearch >>>> - runs katello migration >>>> >>>> Upgrade scripts (executed only once) are: >>>> >>>> (none for CFSE 1.0/1.1 - just two examples that does nothing) >>>> >>>> 0001_preallocate_mongo.sh >>>> - prepares mongo journal for new version of mongo >>>> 0002_create_foreman_user >>>> - creates foreman user >>>> >>>> Now there are couple of issues which are blockers for CFSE 1.1 and >>>> couple of design issues I would like to also fix for Katello. >>>> >>>> Basically katello-upgrade currently does not work in CFSE 1.1 >>>> because we >>>> have some code logic in the migration scripts (filters) which require >>>> all the backend engines to be running. We are not starting pulp and >>>> also >>>> elasticsearch starts slowly and we need to wait until it is available. >>>> >>>> Also there are couple of example migration scripts which does nothing, >>>> but creating pyc/pyo bytecode files which are then added to the >>>> executed >>>> list. I will remove them and make sure python scripts does not create >>>> those. >>>> >>>> That is necessary for CFSE 1.1 upgrades, now for Katello we have a >>>> design issue. Some scripts need the services to be running (like >>>> pulp migration), others must not have services running (candlepin >>>> migration). >>>> >>>> Therefore for Katello, I plan to split our upgrade scripts into two >>>> categories (by script numbers): >>>> >>>> 0001-2999: Will be executed when backend engines are down >>>> 3000-5999: Will be executed when backend engines are up >>>> 6000-9999: Will be executed when backend engines and Katello are up >>>> >>>> This will be the same for both default and upgrade scripts. It would >>>> look (default scripts) like: >>>> >>>> 0001_stop_all_services >>>> 0010_migrate_candlepin >>>> 3000_start_backend_engines >>>> 3010_migrate_pulp >>>> 3020_migrate_katello >>>> 6000_start_katello >>> >>> I dont know if it matters.. but should we just do different >>> directories, instead of using magic numbers? >> If what this should solve is order of scripts, I can't see how >> directories help solving it, since the order in the subdirs should be >> specified as well. > > You still need numbers in the directories, but then you dont need to > remember that 3000 means after engines are up, instead you could see: > > after_engines_are_up That makes sense. +1 > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From daviddavis at redhat.com Fri Oct 26 13:29:56 2012 From: daviddavis at redhat.com (David Davis) Date: Fri, 26 Oct 2012 09:29:56 -0400 (EDT) Subject: [katello-devel] Fedora 17 Gemfile.lock In-Reply-To: <508A88EB.80204@redhat.com> Message-ID: <296767076.17787542.1351258196342.JavaMail.root@redhat.com> Yes, I suppose. My hope was that the Gemfile.lock for each system would match the gem rpms being used on each particular system. That way we're all using the same versions of gems per system and when a gem version is changed, it would be subject to code review (thus we could check if it was properly packaged, etc before accepting any code changes). I know that you can specify which gems ought to be used in katello.spec and Gemfile but it doesn't tell you exactly which gem versions are actually being used for each OS. This might not be the right solution for that though and if it's not, it might not be worth implementing. David ----- Original Message ----- > From: "Ivan Ne?as" > To: katello-devel at redhat.com > Sent: Friday, October 26, 2012 8:58:19 AM > Subject: Re: [katello-devel] Fedora 17 Gemfile.lock > > On 10/26/2012 02:13 PM, David Davis wrote: > > Hi all, > > > > I'm adding Gemfile.lock files into version control so we can ensure > > we're all using the same gem versions per OS. This should also > > allow us to code review gem version changes in addition to gems > > being added. I still need a Gemfile.lock for Fedora 17. I would > > prefer on that is up to date (i.e. it must be pointing to > > rubygems.org and it must not contain ruport). > By saying the same gem versions per OS, you mean in case not system > rubygems through yum are used, such as in rvm/rbenv, right? > > -- Ivan > > > > Thanks. > > > > David > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > -- > Iva > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Fri Oct 26 13:30:36 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 26 Oct 2012 15:30:36 +0200 Subject: [katello-devel] Join the package collection maintainers in Fedora Message-ID: <20121026133036.GM3926@lzapx.brq.redhat.com> Team, after short chat with one folk, I realized the best way to learn packaging, koji, dependencies and stuff is simply to join Fedora project as package maintainer. There is a very nice review process which teach everyone how to do proper packages. It's vital for our project, Katello, to have multiple package maintainers in Fedora. Because when we add a dependency, there are usually only 1, 2 or three packagers which has read-write access to the dist-git. It's good to have more, e.g. Mirek is on PTO, I could also have a rest and then - no way of bumping version or fixing a bug in an upstream Fedora package. Also more hands is also good. And the best is Fedora has very nice and up-to-date documentation about processes, koji and stuff. You can't go wrong by reading it. If you want to try a package, please go and grab one of our development ruby dependencies which are not in Fedora. If you are not in the packager role, please give it a try. It's a fairly long process (you need to prove your skills), but we all are willing to help you to find your sponsor and get involved (e.g. by doing reviews). Do not wait for tomorrow, read the wiki and join the package collection maintainers - NOW! https://fedoraproject.org/wiki/Join_the_package_collection_maintainers LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From jomara at redhat.com Fri Oct 26 13:35:09 2012 From: jomara at redhat.com (Jordan OMara) Date: Fri, 26 Oct 2012 09:35:09 -0400 Subject: [katello-devel] Join the package collection maintainers in Fedora In-Reply-To: <20121026133036.GM3926@lzapx.brq.redhat.com> References: <20121026133036.GM3926@lzapx.brq.redhat.com> Message-ID: <20121026133509.GQ28693@redhat.com> On 26/10/12 15:30 +0200, Lukas Zapletal wrote: >Team, > >If you want to try a package, please go and grab one of our development >ruby dependencies which are not in Fedora. > >If you are not in the packager role, please give it a try. It's a fairly >long process (you need to prove your skills), but we all are willing to >help you to find your sponsor and get involved (e.g. by doing reviews). > >Do not wait for tomorrow, read the wiki and join the package collection >maintainers - NOW! > >https://fedoraproject.org/wiki/Join_the_package_collection_maintainers > +10000 your country needs you. join today! (seriously, this will make getting katello into fedora 1000000 times better) -- 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 lzap at redhat.com Fri Oct 26 14:31:35 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 26 Oct 2012 16:31:35 +0200 Subject: [katello-devel] [ACTION NEEDED] Gemfile for 1.8 and 1.9 Ruby merged In-Reply-To: <1703733902.12715787.1351254156844.JavaMail.root@redhat.com> References: <508A60A4.6030701@redhat.com> <1703733902.12715787.1351254156844.JavaMail.root@redhat.com> Message-ID: <20121026143135.GR3926@lzapx.brq.redhat.com> On Fri, Oct 26, 2012 at 08:22:36AM -0400, Tom McKay wrote: > Succeeded w/ 'bundle install --without jshintrb' > Maybe we can wrap these "source validators" into a separate group that would be disabled by default. Folks can enable it if they want to use it, and we can do the same on the Travis. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Oct 26 14:35:17 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 26 Oct 2012 16:35:17 +0200 Subject: [katello-devel] Katello upgrade redesign In-Reply-To: <952094893.12738189.1351257813561.JavaMail.root@redhat.com> References: <508A8D34.9030105@redhat.com> <952094893.12738189.1351257813561.JavaMail.root@redhat.com> Message-ID: <20121026143517.GS3926@lzapx.brq.redhat.com> > Will there never be a case where an upgrade w/o services needs to be run after an upgrade with services? Would it be simpler just to put the scripts in order in a single dir but include a meta tag in them that says what services have to be on/off? > > Yes, for example ElasticSearch reindex which Martin is currently working on. Or anything that is doing "offline" upgrade. But having a place for script without any services running is a side effect, the main reason is to have possibility to run scripts: - with only backend engines running - with katello and BE running running Currently it's kinda "random" - each scripts starts it's own services and I want to make an order here. I don't like idea of directories, because this should really be linear process. And scripts for starting services are scripts themselves - it looks like nice design to me. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Oct 26 14:42:08 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 26 Oct 2012 16:42:08 +0200 Subject: [katello-devel] Katello upgrade redesign In-Reply-To: <508A8ED6.3040607@redhat.com> References: <20121026100524.GC3926@lzapx.brq.redhat.com> <508A8B1D.6040106@redhat.com> <508A8D34.9030105@redhat.com> <508A8ED6.3040607@redhat.com> Message-ID: <20121026144208.GT3926@lzapx.brq.redhat.com> On Fri, Oct 26, 2012 at 09:23:34AM -0400, Bryan Kearney wrote: > You still need numbers in the directories, but then you dont need to > remember that 3000 means after engines are up, instead you could > see: > > after_engines_are_up I disagree, because then you would have this: after_engines_are_up/0010_migrate_pulp after_engines_are_up/0020_migrate_katello after_katello_is_up/00XX_some_other_script before_engines_are_up/0010_migrate_candlepin I have sorted it like ls do by default. To me, this looks more straightforward. Remember how RHEL is starting services? Come on, it's not that bad. I like it. And after systemd is rebased into RHEL, we will be thinking back to these days :-) 0001_stop_all_services 0010_migrate_candlepin 3000_start_backend_engines 3010_migrate_pulp 3020_migrate_katello 6000_start_katello You don't need to remember anything, just read the steps and put your script where it needs to be. It's not magic. Also the implementation is more simple :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Fri Oct 26 14:56:32 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 26 Oct 2012 10:56:32 -0400 Subject: [katello-devel] F16 nightly Message-ID: <508AA4A0.3060709@redhat.com> Still failing for me. this is what i am doind/seeing: 1) clean install of Fedora 16 minimal, fully updated. 2) rpm -Uvh http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-latest.rpm 3) yum install katello-all 4) katello-configure 5) see the following in Initializing Katello data ########################################################### Failed, please check [/var/log/katello/katello-configure/db_seed.log] Report errors using # katello-debug tool. 6) Looking in the log file I see: ** Invoke seed_with_logging (first_time) ** Invoke db:seed (first_time) ** Invoke db:abort_if_pending_migrations (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:abort_if_pending_migrations ** Execute db:seed rake aborted! could not find foreman-admin-user /usr/share/katello/db/seeds.rb:45 /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in `load' /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in `load' /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:227:in `load_dependency' /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in `load' /usr/lib/ruby/gems/1.8/gems/activerecord-3.0.10/lib/active_record/railties/databases.rake:290 /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `invoke_with_call_chain' -- bk From thomasmckay at redhat.com Fri Oct 26 14:58:36 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 26 Oct 2012 10:58:36 -0400 (EDT) Subject: [katello-devel] F16 nightly In-Reply-To: <508AA4A0.3060709@redhat.com> Message-ID: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Bryan Kearney" > To: katello-devel at redhat.com > Sent: Friday, October 26, 2012 10:56:32 AM > Subject: [katello-devel] F16 nightly > > Still failing for me. this is what i am doind/seeing: > > 1) clean install of Fedora 16 minimal, fully updated. > 2) rpm -Uvh > http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-latest.rpm > 3) yum install katello-all > 4) katello-configure > 5) see the following in > > Initializing Katello data > ########################################################### > Failed, please check > [/var/log/katello/katello-configure/db_seed.log] > Report errors using # katello-debug tool. > > 6) Looking in the log file I see: > > > > ** Invoke seed_with_logging (first_time) > ** Invoke db:seed (first_time) > ** Invoke db:abort_if_pending_migrations (first_time) > ** Invoke environment (first_time) > ** Execute environment > ** Execute db:abort_if_pending_migrations > ** Execute db:seed > rake aborted! > could not find foreman-admin-user > /usr/share/katello/db/seeds.rb:45 > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in > `load' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in > `load' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:227:in > `load_dependency' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in > `load' > /usr/lib/ruby/gems/1.8/gems/activerecord-3.0.10/lib/active_record/railties/databases.rake:290 > /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in > `call' > /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in > `execute' > /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in > `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in > `execute' > /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in > `invoke_with_call_chain' > > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > Since nightly is a bit behind, perhaps try the koji build that just completed: http://koji.katello.org/releases/yum/ From bkearney at redhat.com Fri Oct 26 15:01:08 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 26 Oct 2012 11:01:08 -0400 Subject: [katello-devel] F16 nightly In-Reply-To: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> Message-ID: <508AA5B4.1020106@redhat.com> On 10/26/2012 10:58 AM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Bryan Kearney" >> To: katello-devel at redhat.com >> Sent: Friday, October 26, 2012 10:56:32 AM >> Subject: [katello-devel] F16 nightly >> >> Still failing for me. this is what i am doind/seeing: >> >> 1) clean install of Fedora 16 minimal, fully updated. >> 2) rpm -Uvh >> http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-latest.rpm >> 3) yum install katello-all >> 4) katello-configure >> 5) see the following in >> >> Initializing Katello data >> ########################################################### >> Failed, please check >> [/var/log/katello/katello-configure/db_seed.log] >> Report errors using # katello-debug tool. >> >> 6) Looking in the log file I see: >> >> >> >> ** Invoke seed_with_logging (first_time) >> ** Invoke db:seed (first_time) >> ** Invoke db:abort_if_pending_migrations (first_time) >> ** Invoke environment (first_time) >> ** Execute environment >> ** Execute db:abort_if_pending_migrations >> ** Execute db:seed >> rake aborted! >> could not find foreman-admin-user >> /usr/share/katello/db/seeds.rb:45 >> /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in >> `load' >> /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in >> `load' >> /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:227:in >> `load_dependency' >> /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in >> `load' >> /usr/lib/ruby/gems/1.8/gems/activerecord-3.0.10/lib/active_record/railties/databases.rake:290 >> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in >> `call' >> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in >> `execute' >> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in >> `each' >> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in >> `execute' >> /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in >> `invoke_with_call_chain' >> >> >> -- bk >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > > Since nightly is a bit behind, perhaps try the koji build that just completed: > http://koji.katello.org/releases/yum/ > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > How behind? Should be last night, yes? -- bk From bkearney at redhat.com Fri Oct 26 15:03:18 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 26 Oct 2012 11:03:18 -0400 Subject: [katello-devel] Katello upgrade redesign In-Reply-To: <20121026144208.GT3926@lzapx.brq.redhat.com> References: <20121026100524.GC3926@lzapx.brq.redhat.com> <508A8B1D.6040106@redhat.com> <508A8D34.9030105@redhat.com> <508A8ED6.3040607@redhat.com> <20121026144208.GT3926@lzapx.brq.redhat.com> Message-ID: <508AA636.7000804@redhat.com> On 10/26/2012 10:42 AM, Lukas Zapletal wrote: > On Fri, Oct 26, 2012 at 09:23:34AM -0400, Bryan Kearney wrote: >> You still need numbers in the directories, but then you dont need to >> remember that 3000 means after engines are up, instead you could >> see: >> >> after_engines_are_up > > I disagree, because then you would have this: > > after_engines_are_up/0010_migrate_pulp > after_engines_are_up/0020_migrate_katello > after_katello_is_up/00XX_some_other_script > before_engines_are_up/0010_migrate_candlepin > > I have sorted it like ls do by default. To me, this looks more > straightforward. > > Remember how RHEL is starting services? Come on, it's not that bad. I > like it. And after systemd is rebased into RHEL, we will be thinking > back to these days :-) > > 0001_stop_all_services > 0010_migrate_candlepin > 3000_start_backend_engines > 3010_migrate_pulp > 3020_migrate_katello > 6000_start_katello > > You don't need to remember anything, just read the steps and put your > script where it needs to be. It's not magic. Also the implementation is > more simple :-) > if it is just me, go ahead and ignore :) -- bk From mmccune at redhat.com Fri Oct 26 15:04:20 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 26 Oct 2012 08:04:20 -0700 Subject: [katello-devel] Katello upgrade redesign In-Reply-To: <20121026144208.GT3926@lzapx.brq.redhat.com> References: <20121026100524.GC3926@lzapx.brq.redhat.com> <508A8B1D.6040106@redhat.com> <508A8D34.9030105@redhat.com> <508A8ED6.3040607@redhat.com> <20121026144208.GT3926@lzapx.brq.redhat.com> Message-ID: <508AA674.1070908@redhat.com> On 10/26/2012 07:42 AM, Lukas Zapletal wrote: > On Fri, Oct 26, 2012 at 09:23:34AM -0400, Bryan Kearney wrote: >> You still need numbers in the directories, but then you dont need to >> remember that 3000 means after engines are up, instead you could >> see: >> >> after_engines_are_up > > I disagree, because then you would have this: > > after_engines_are_up/0010_migrate_pulp > after_engines_are_up/0020_migrate_katello > after_katello_is_up/00XX_some_other_script > before_engines_are_up/0010_migrate_candlepin > > I have sorted it like ls do by default. To me, this looks more > straightforward. > > Remember how RHEL is starting services? Come on, it's not that bad. I > like it. And after systemd is rebased into RHEL, we will be thinking > back to these days :-) > > 0001_stop_all_services > 0010_migrate_candlepin > 3000_start_backend_engines > 3010_migrate_pulp > 3020_migrate_katello > 6000_start_katello > > You don't need to remember anything, just read the steps and put your > script where it needs to be. It's not magic. Also the implementation is > more simple :-) > +1, a flat large list is easier to parse in this case. Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From lzap at redhat.com Fri Oct 26 15:14:16 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 26 Oct 2012 17:14:16 +0200 Subject: [katello-devel] F16 nightly In-Reply-To: <508AA5B4.1020106@redhat.com> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> <508AA5B4.1020106@redhat.com> Message-ID: <20121026151416.GV3926@lzapx.brq.redhat.com> On Fri, Oct 26, 2012 at 11:01:08AM -0400, Bryan Kearney wrote: > How behind? Should be last night, yes? > You dont read lists, you dont know :-) I have announced that due to build issue, nightly was not generated this night. What you saw is state from day before tomorrow. Now its fixed, I have initiated build this afternoon and repos were finally generated and mirrored hour ago. Try now, it's working for me. -- Later, Lukas "lzap" Zapletal #katello #systemengine From ehelms at redhat.com Fri Oct 26 15:20:01 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 26 Oct 2012 11:20:01 -0400 Subject: [katello-devel] Travis Testing Pull Requests Message-ID: <508AAA21.4000304@redhat.com> Howdy All, You may notice from today forward that as you open pull requests and make commits to them there will be a status indicator about testing on Travis. As of https://github.com/Katello/katello/pull/925 we are trying out a Travis configuration that will run the following on all pull requests, repository merges, and updates to pull requests. - CLI unittests - Pylint - SCSS compilation - Rspec unittests The configuration is currently setup to fail-fast. In other words, it will not run all 4 all of the time, it attempts to be as quick as possible, such that if one fails, the build is flagged as failed and execution stops. This may require some tuning as we get used to it, so please provide any feedback or thoughts on the process as we begin to use it. - Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmorsi at redhat.com Fri Oct 26 15:32:49 2012 From: mmorsi at redhat.com (Mo Morsi) Date: Fri, 26 Oct 2012 11:32:49 -0400 Subject: [katello-devel] Fedora 17 Gemfile.lock In-Reply-To: <296767076.17787542.1351258196342.JavaMail.root@redhat.com> References: <296767076.17787542.1351258196342.JavaMail.root@redhat.com> Message-ID: <508AAD21.6030307@redhat.com> Not fully sure if this addresses the issue, but you can compare your Gemfile and Gemfile against fedora here: http://isitfedoraruby.com/stats/gemfile_tool I'm hoping this helps for synchronization purposes. The source code is here incase you want to improve the tool: https://github.com/zuhao/isitfedoraruby/blob/master/app/controllers/stats_controller.rb It's currently a bit hacky, I am willing to give anyone that wants to work on the codebase full commit access, no patch-review needed, and will push any changes live immediately. Alternatively if there is an interest we can host isitfedoraruby on openshift or similar so that other people can push changes to the live site. -Mo On 10/26/2012 09:29 AM, David Davis wrote: > Yes, I suppose. My hope was that the Gemfile.lock for each system would match the gem rpms being used on each particular system. That way we're all using the same versions of gems per system and when a gem version is changed, it would be subject to code review (thus we could check if it was properly packaged, etc before accepting any code changes). I know that you can specify which gems ought to be used in katello.spec and Gemfile but it doesn't tell you exactly which gem versions are actually being used for each OS. This might not be the right solution for that though and if it's not, it might not be worth implementing. > > David > > ----- Original Message ----- >> From: "Ivan Ne?as" >> To: katello-devel at redhat.com >> Sent: Friday, October 26, 2012 8:58:19 AM >> Subject: Re: [katello-devel] Fedora 17 Gemfile.lock >> >> On 10/26/2012 02:13 PM, David Davis wrote: >>> Hi all, >>> >>> I'm adding Gemfile.lock files into version control so we can ensure >>> we're all using the same gem versions per OS. This should also >>> allow us to code review gem version changes in addition to gems >>> being added. I still need a Gemfile.lock for Fedora 17. I would >>> prefer on that is up to date (i.e. it must be pointing to >>> rubygems.org and it must not contain ruport). >> By saying the same gem versions per OS, you mean in case not system >> rubygems through yum are used, such as in rvm/rbenv, right? >> >> -- Ivan >>> Thanks. >>> >>> David >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> >> -- >> Iva >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > From mmorsi at redhat.com Fri Oct 26 15:36:26 2012 From: mmorsi at redhat.com (Mo Morsi) Date: Fri, 26 Oct 2012 11:36:26 -0400 Subject: [katello-devel] Fedora 17 Gemfile.lock In-Reply-To: <508AAD21.6030307@redhat.com> References: <296767076.17787542.1351258196342.JavaMail.root@redhat.com> <508AAD21.6030307@redhat.com> Message-ID: <508AADFA.8060507@redhat.com> The site is also in major need of UI improvements, it's functional but not pretty. If any of the UI designers on the projects could help out with this, it'd be much appreciated. If you just send us mockups, we probably could implement them when we get the cycles, but patches to the codebase is always more than welcome as well! (its standard js and css). Thanks alot! -Mo On 10/26/2012 11:32 AM, Mo Morsi wrote: > Not fully sure if this addresses the issue, but you can compare your > Gemfile and Gemfile against fedora here: > > http://isitfedoraruby.com/stats/gemfile_tool > > I'm hoping this helps for synchronization purposes. The source code is > here incase you want to improve the tool: > > https://github.com/zuhao/isitfedoraruby/blob/master/app/controllers/stats_controller.rb > > It's currently a bit hacky, I am willing to give anyone that wants to > work on the codebase full commit access, no patch-review needed, and > will push any changes live immediately. > > Alternatively if there is an interest we can host isitfedoraruby on > openshift or similar so that other people can push changes to the live site. > > -Mo > > > > > On 10/26/2012 09:29 AM, David Davis wrote: >> Yes, I suppose. My hope was that the Gemfile.lock for each system would match the gem rpms being used on each particular system. That way we're all using the same versions of gems per system and when a gem version is changed, it would be subject to code review (thus we could check if it was properly packaged, etc before accepting any code changes). I know that you can specify which gems ought to be used in katello.spec and Gemfile but it doesn't tell you exactly which gem versions are actually being used for each OS. This might not be the right solution for that though and if it's not, it might not be worth implementing. >> >> David >> >> ----- Original Message ----- >>> From: "Ivan Ne?as" >>> To: katello-devel at redhat.com >>> Sent: Friday, October 26, 2012 8:58:19 AM >>> Subject: Re: [katello-devel] Fedora 17 Gemfile.lock >>> >>> On 10/26/2012 02:13 PM, David Davis wrote: >>>> Hi all, >>>> >>>> I'm adding Gemfile.lock files into version control so we can ensure >>>> we're all using the same gem versions per OS. This should also >>>> allow us to code review gem version changes in addition to gems >>>> being added. I still need a Gemfile.lock for Fedora 17. I would >>>> prefer on that is up to date (i.e. it must be pointing to >>>> rubygems.org and it must not contain ruport). >>> By saying the same gem versions per OS, you mean in case not system >>> rubygems through yum are used, such as in rvm/rbenv, right? >>> >>> -- Ivan >>>> Thanks. >>>> >>>> David >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> -- >>> Iva >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> From bkearney at redhat.com Fri Oct 26 16:16:29 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 26 Oct 2012 12:16:29 -0400 Subject: [katello-devel] F16 nightly In-Reply-To: <20121026151416.GV3926@lzapx.brq.redhat.com> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> <508AA5B4.1020106@redhat.com> <20121026151416.GV3926@lzapx.brq.redhat.com> Message-ID: <508AB75D.5050607@redhat.com> On 10/26/2012 11:14 AM, Lukas Zapletal wrote: > On Fri, Oct 26, 2012 at 11:01:08AM -0400, Bryan Kearney wrote: >> How behind? Should be last night, yes? >> > > You dont read lists, you dont know :-) > > I have announced that due to build issue, nightly was not generated this > night. What you saw is state from day before tomorrow. > > Now its fixed, I have initiated build this afternoon and repos were > finally generated and mirrored hour ago. > > Try now, it's working for me. > > Must be me. 1) I started with a clean install of F16 , then 2) rpm -Uvh http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-latest.rpm 3) yum install katello-all 4) katello-configure I got a failure ** Invoke seed_with_logging (first_time) ** Invoke db:seed (first_time) ** Invoke db:abort_if_pending_migrations (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:abort_if_pending_migrations ** Execute db:seed rake aborted! uninitialized constant Resources::Foreman::ForemanApi /usr/share/katello/lib/resources/foreman.rb:26 I notice that foreman_api is not in Gemfile nor in Gemfile.lock, so I add it and I get: ** Invoke seed_with_logging (first_time) ** Invoke db:seed (first_time) ** Invoke db:abort_if_pending_migrations (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:abort_if_pending_migrations ** Execute db:seed rake aborted! could not find foreman-admin-user /usr/share/katello/db/seeds.rb:45 /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in `load' /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in `load' /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:227:in `load_dependency' /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10 -- bk From bkearney at redhat.com Fri Oct 26 17:02:39 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 26 Oct 2012 13:02:39 -0400 Subject: [katello-devel] F16 nightly In-Reply-To: <508AA4A0.3060709@redhat.com> References: <508AA4A0.3060709@redhat.com> Message-ID: <508AC22F.9050701@redhat.com> On 10/26/2012 10:56 AM, Bryan Kearney wrote: > Still failing for me. this is what i am doind/seeing: > > 1) clean install of Fedora 16 minimal, fully updated. > 2) rpm -Uvh > http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-latest.rpm > > 3) yum install katello-all > 4) katello-configure > 5) see the following in > > Initializing Katello data > ########################################################### > Failed, please check [/var/log/katello/katello-configure/db_seed.log] > Report errors using # katello-debug tool. > > 6) Looking in the log file I see: > > > > ** Invoke seed_with_logging (first_time) > ** Invoke db:seed (first_time) > ** Invoke db:abort_if_pending_migrations (first_time) > ** Invoke environment (first_time) > ** Execute environment > ** Execute db:abort_if_pending_migrations > ** Execute db:seed > rake aborted! > could not find foreman-admin-user > /usr/share/katello/db/seeds.rb:45 > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in > `load' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in > `load' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:227:in > `load_dependency' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in > `load' > /usr/lib/ruby/gems/1.8/gems/activerecord-3.0.10/lib/active_record/railties/databases.rake:290 > > /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call' > /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `execute' > /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute' > /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in > `invoke_with_call_chain' > > > -- bk I see the same for RHEL6. Are you using a different foreman rpm location? -- bk From lzap at redhat.com Mon Oct 29 07:50:33 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 29 Oct 2012 08:50:33 +0100 Subject: [katello-devel] Fedora 17 Gemfile.lock In-Reply-To: <508AADFA.8060507@redhat.com> References: <296767076.17787542.1351258196342.JavaMail.root@redhat.com> <508AAD21.6030307@redhat.com> <508AADFA.8060507@redhat.com> Message-ID: <20121029075033.GB2137@lzapx.brq.redhat.com> It *is* pretty, everything made out of Twitter Bootstrap is pretty. Seriously, I like it. Thanks. LZ On Fri, Oct 26, 2012 at 11:36:26AM -0400, Mohammed Morsi wrote: > The site is also in major need of UI improvements, it's functional but > not pretty. > > If any of the UI designers on the projects could help out with this, > it'd be much appreciated. If you just send us mockups, we probably could > implement them when we get the cycles, but patches to the codebase is > always more than welcome as well! (its standard js and css). > > Thanks alot! > -Mo > > > On 10/26/2012 11:32 AM, Mo Morsi wrote: > > Not fully sure if this addresses the issue, but you can compare your > > Gemfile and Gemfile against fedora here: > > > > http://isitfedoraruby.com/stats/gemfile_tool > > > > I'm hoping this helps for synchronization purposes. The source code is > > here incase you want to improve the tool: > > > > https://github.com/zuhao/isitfedoraruby/blob/master/app/controllers/stats_controller.rb > > > > It's currently a bit hacky, I am willing to give anyone that wants to > > work on the codebase full commit access, no patch-review needed, and > > will push any changes live immediately. > > > > Alternatively if there is an interest we can host isitfedoraruby on > > openshift or similar so that other people can push changes to the live site. > > > > -Mo > > > > > > > > > > On 10/26/2012 09:29 AM, David Davis wrote: > >> Yes, I suppose. My hope was that the Gemfile.lock for each system would match the gem rpms being used on each particular system. That way we're all using the same versions of gems per system and when a gem version is changed, it would be subject to code review (thus we could check if it was properly packaged, etc before accepting any code changes). I know that you can specify which gems ought to be used in katello.spec and Gemfile but it doesn't tell you exactly which gem versions are actually being used for each OS. This might not be the right solution for that though and if it's not, it might not be worth implementing. > >> > >> David > >> > >> ----- Original Message ----- > >>> From: "Ivan Ne?as" > >>> To: katello-devel at redhat.com > >>> Sent: Friday, October 26, 2012 8:58:19 AM > >>> Subject: Re: [katello-devel] Fedora 17 Gemfile.lock > >>> > >>> On 10/26/2012 02:13 PM, David Davis wrote: > >>>> Hi all, > >>>> > >>>> I'm adding Gemfile.lock files into version control so we can ensure > >>>> we're all using the same gem versions per OS. This should also > >>>> allow us to code review gem version changes in addition to gems > >>>> being added. I still need a Gemfile.lock for Fedora 17. I would > >>>> prefer on that is up to date (i.e. it must be pointing to > >>>> rubygems.org and it must not contain ruport). > >>> By saying the same gem versions per OS, you mean in case not system > >>> rubygems through yum are used, such as in rvm/rbenv, right? > >>> > >>> -- Ivan > >>>> Thanks. > >>>> > >>>> David > >>>> > >>>> _______________________________________________ > >>>> katello-devel mailing list > >>>> katello-devel at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/katello-devel > >>> -- > >>> Iva > >>> > >>> _______________________________________________ > >>> 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 Mon Oct 29 08:14:29 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 29 Oct 2012 09:14:29 +0100 Subject: [katello-devel] F16 nightly In-Reply-To: <508AB75D.5050607@redhat.com> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> <508AA5B4.1020106@redhat.com> <20121026151416.GV3926@lzapx.brq.redhat.com> <508AB75D.5050607@redhat.com> Message-ID: <20121029081429.GC2137@lzapx.brq.redhat.com> Ok, this is a new problem I see too. I have accidentaly deleted foreman_api from the Gemfile, will fix this. But after I change it, it works for me again. No foreman-admin-user message for me... Petr, any ideas? LZ We have moved our foreman api into separate rpm because of headpin. On Fri, Oct 26, 2012 at 12:16:29PM -0400, Bryan Kearney wrote: > On 10/26/2012 11:14 AM, Lukas Zapletal wrote: > >On Fri, Oct 26, 2012 at 11:01:08AM -0400, Bryan Kearney wrote: > >>How behind? Should be last night, yes? > >> > > > >You dont read lists, you dont know :-) > > > >I have announced that due to build issue, nightly was not generated this > >night. What you saw is state from day before tomorrow. > > > >Now its fixed, I have initiated build this afternoon and repos were > >finally generated and mirrored hour ago. > > > >Try now, it's working for me. > > > > > Must be me. > > 1) I started with a clean install of F16 , then > 2) rpm -Uvh http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-latest.rpm > 3) yum install katello-all > 4) katello-configure > > I got a failure > ** Invoke seed_with_logging (first_time) > ** Invoke db:seed (first_time) > ** Invoke db:abort_if_pending_migrations (first_time) > ** Invoke environment (first_time) > ** Execute environment > ** Execute db:abort_if_pending_migrations > ** Execute db:seed > rake aborted! > uninitialized constant Resources::Foreman::ForemanApi > /usr/share/katello/lib/resources/foreman.rb:26 > > > I notice that foreman_api is not in Gemfile nor in Gemfile.lock, so > I add it and I get: > > ** Invoke seed_with_logging (first_time) > ** Invoke db:seed (first_time) > ** Invoke db:abort_if_pending_migrations (first_time) > ** Invoke environment (first_time) > ** Execute environment > ** Execute db:abort_if_pending_migrations > ** Execute db:seed > rake aborted! > could not find foreman-admin-user > /usr/share/katello/db/seeds.rb:45 > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in > `load' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in > `load' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:227:in > `load_dependency' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10 > > -- 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 Mon Oct 29 09:23:52 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 29 Oct 2012 10:23:52 +0100 Subject: [katello-devel] Nightly not working Message-ID: <20121029092352.GD2137@lzapx.brq.redhat.com> Guys, nightly is not working due to foreman api dependency problem. I am working on it, hopefully 2 PM build will work. I will announce on the list once I test it. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From tstrachota at redhat.com Mon Oct 29 09:42:52 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Mon, 29 Oct 2012 10:42:52 +0100 Subject: [katello-devel] Travis Testing Pull Requests In-Reply-To: <508AAA21.4000304@redhat.com> References: <508AAA21.4000304@redhat.com> Message-ID: <508E4F9C.2050907@redhat.com> On 10/26/2012 05:20 PM, Eric Helms wrote: > Howdy All, > > You may notice from today forward that as you open pull requests and > make commits to them there will be a status indicator about testing on > Travis. As of https://github.com/Katello/katello/pull/925 we are trying > out a Travis configuration that will run the following on all pull > requests, repository merges, and updates to pull requests. > > - CLI unittests > - Pylint > - SCSS compilation > - Rspec unittests > > The configuration is currently setup to fail-fast. In other words, it > will not run all 4 all of the time, it attempts to be as quick as > possible, such that if one fails, the build is flagged as failed and > execution stops. > > This may require some tuning as we get used to it, so please provide any > feedback or thoughts on the process as we begin to use it. > > - Eric > It looks great! Just one thought against the fail-fast approach: I made a pull request with some server side changes and the tests around it weren't executed at all because of failing cli unit tests. In this case the test report was not very useful. Is it possible to always run all the tests or is it too resource consuming? T. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Mon Oct 29 10:15:43 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 29 Oct 2012 11:15:43 +0100 Subject: [katello-devel] Travis Testing Pull Requests In-Reply-To: <508E4F9C.2050907@redhat.com> References: <508AAA21.4000304@redhat.com> <508E4F9C.2050907@redhat.com> Message-ID: <20121029101543.GE2137@lzapx.brq.redhat.com> On Mon, Oct 29, 2012 at 10:42:52AM +0100, Tomas Strachota wrote: > Just one thought against the fail-fast approach: > I made a pull request with some server side changes and the tests > around it weren't executed at all because of failing cli unit tests. > In this case the test report was not very useful. Is it possible to > always run all the tests or is it too resource consuming? It was an intention to throw errors earlier. We need to fix cli tests asap :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Mon Oct 29 10:32:21 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 29 Oct 2012 11:32:21 +0100 Subject: [katello-devel] F16 nightly In-Reply-To: <508AB75D.5050607@redhat.com> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> <508AA5B4.1020106@redhat.com> <20121026151416.GV3926@lzapx.brq.redhat.com> <508AB75D.5050607@redhat.com> Message-ID: <20121029103221.GF2137@lzapx.brq.redhat.com> Ok, I have fixed the first error now: https://github.com/Katello/katello/pull/941 LZ On Fri, Oct 26, 2012 at 12:16:29PM -0400, Bryan Kearney wrote: > On 10/26/2012 11:14 AM, Lukas Zapletal wrote: > >On Fri, Oct 26, 2012 at 11:01:08AM -0400, Bryan Kearney wrote: > >>How behind? Should be last night, yes? > >> > > > >You dont read lists, you dont know :-) > > > >I have announced that due to build issue, nightly was not generated this > >night. What you saw is state from day before tomorrow. > > > >Now its fixed, I have initiated build this afternoon and repos were > >finally generated and mirrored hour ago. > > > >Try now, it's working for me. > > > > > Must be me. > > 1) I started with a clean install of F16 , then > 2) rpm -Uvh http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-latest.rpm > 3) yum install katello-all > 4) katello-configure > > I got a failure > ** Invoke seed_with_logging (first_time) > ** Invoke db:seed (first_time) > ** Invoke db:abort_if_pending_migrations (first_time) > ** Invoke environment (first_time) > ** Execute environment > ** Execute db:abort_if_pending_migrations > ** Execute db:seed > rake aborted! > uninitialized constant Resources::Foreman::ForemanApi > /usr/share/katello/lib/resources/foreman.rb:26 > > > I notice that foreman_api is not in Gemfile nor in Gemfile.lock, so > I add it and I get: > > ** Invoke seed_with_logging (first_time) > ** Invoke db:seed (first_time) > ** Invoke db:abort_if_pending_migrations (first_time) > ** Invoke environment (first_time) > ** Execute environment > ** Execute db:abort_if_pending_migrations > ** Execute db:seed > rake aborted! > could not find foreman-admin-user > /usr/share/katello/db/seeds.rb:45 > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in > `load' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in > `load' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:227:in > `load_dependency' > /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10 > > -- 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 Duncan.Innes at virginmoney.com Mon Oct 29 10:53:41 2012 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Mon, 29 Oct 2012 10:53:41 -0000 Subject: [katello-devel] When does Puppet start In-Reply-To: <20121029103221.GF2137@lzapx.brq.redhat.com> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com><508AA5B4.1020106@redhat.com><20121026151416.GV3926@lzapx.brq.redhat.com><508AB75D.5050607@redhat.com> <20121029103221.GF2137@lzapx.brq.redhat.com> Message-ID: <56343345B145C043AE990701E3D19395B9E9C7@EXVS2.nrplc.localnet> Hi folks, Hopefully this isn't an entirely stupid question. I'm trying to find out where Puppet will start processing during the whole build phase in Katello. Is there anything of Puppet running during the install kernel? It would be neat if it does as that would enable machines to be fully configured on first boot. But I can see the scope of Puppet being large enough to avoid running it in the install kernel. What direction has Puppet integration taken? If there's any good documentation on the process that I can read, I'm happy to do that. Cheers Duncan This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Authorised and regulated by the Financial Services Authority. The following companies also trade as Virgin Money and are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482) are authorised and regulated by the Financial Services Authority. Virgin Money Cards Limited (Company no. 4232392) is introducer appointed representative only of Virgin Money Personal Financial Service Limited. For further details of Virgin Money group companies please visit our website at virginmoney.com From jweiss at redhat.com Mon Oct 29 12:18:16 2012 From: jweiss at redhat.com (Jeff Weiss) Date: Mon, 29 Oct 2012 08:18:16 -0400 (EDT) Subject: [katello-devel] Travis Testing Pull Requests In-Reply-To: <508E4F9C.2050907@redhat.com> Message-ID: <1286035342.3071490.1351513096411.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tomas Strachota" > To: "Eric Helms" > Cc: katello-devel at redhat.com > Sent: Monday, October 29, 2012 5:42:52 AM > Subject: Re: [katello-devel] Travis Testing Pull Requests > > On 10/26/2012 05:20 PM, Eric Helms wrote: > > Howdy All, > > > > You may notice from today forward that as you open pull requests > > and > > make commits to them there will be a status indicator about testing > > on > > Travis. As of https://github.com/Katello/katello/pull/925 we are > > trying > > out a Travis configuration that will run the following on all pull > > requests, repository merges, and updates to pull requests. > > > > - CLI unittests > > - Pylint > > - SCSS compilation > > - Rspec unittests > > > > The configuration is currently setup to fail-fast. In other words, > > it > > will not run all 4 all of the time, it attempts to be as quick as > > possible, such that if one fails, the build is flagged as failed > > and > > execution stops. > > > > This may require some tuning as we get used to it, so please > > provide any > > feedback or thoughts on the process as we begin to use it. > > > > - Eric > > > > It looks great! > > Just one thought against the fail-fast approach: > I made a pull request with some server side changes and the tests > around > it weren't executed at all because of failing cli unit tests. In this > case the test report was not very useful. Is it possible to always > run > all the tests or is it too resource consuming? > > T. > I agree with the fail-fast approach - in my experience, by trying to get a slower but complete result, you just end up with mostly slow incomplete results. So you might as well just make it fast. What you're aiming to find out here is "what changes in behavior did my PR cause". So it's not really about what the test results are, it's the diff between the PR's results, and master's. Of course it's a whole lot easier to determine that, if master's test runs are kept all green, so that you know any failed test on the PR is important. The fact that cli tests failed probably means they were failing on master too, which should not be happening, and is part of the problem I think we're trying to solve here. And then of course there's failures in the testing infrastructure that have nothing to do with katello at all. So pass == good, but fail == maybe not good. -Jeff > > > > > _______________________________________________ > > 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 dmitri at redhat.com Mon Oct 29 12:41:34 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 29 Oct 2012 12:41:34 +0000 Subject: [katello-devel] ruby 1.9, rails, and encodings Message-ID: <508E797E.5000000@redhat.com> Hey all, Ruby 1.9 is *much* less lax about String encodings, and there a few basic things everybody should know to avoid surprises (esp. when switching back and forth between 1.8 and 1.9). In the absence of "magic comment" (pls. see below) Ruby 1.9 assumes that source file encoding is US-ASCII. This is 7-bit encoding (true 7 bit ASCII) and is therefore incompatible with extended character sets. You can add a "magic comment" in the beginning of the source code file to mark the encoding: # encode: utf-8 Please note that this allows for use of extended characters set characters in variable, method, etc names. Probably not a good idea, however (ruby 1.8 for example, will be *very* disappointed). Under 1.9, when inside rails, it's safe to assume that strings you are dealing with are utf-8 encoded (you can check the values of Encoding.default_internal and Encoding.default_external if you are curious). Rails also takes care of handling of incoming non-utf-encoded strings (such as form data) into utf when the encoding of those strings is incorrectly specified, or not specified at all. Please see [1] for more details. Let me know if you have any questions, -d [1]. http://yehudakatz.com/2010/05/17/encodings-unabridged/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ehelms at redhat.com Mon Oct 29 13:22:50 2012 From: ehelms at redhat.com (Eric Helms) Date: Mon, 29 Oct 2012 09:22:50 -0400 Subject: [katello-devel] Travis Testing Pull Requests In-Reply-To: <508E4F9C.2050907@redhat.com> References: <508AAA21.4000304@redhat.com> <508E4F9C.2050907@redhat.com> Message-ID: <508E832A.8080907@redhat.com> Once our pull request testing goes green (which should be as soon as my pull request gets merged with updates), the fail fast shouldn't be as much of an issue as pull requests should be green from here on out before being merged. -Eric On 10/29/2012 05:42 AM, Tomas Strachota wrote: > On 10/26/2012 05:20 PM, Eric Helms wrote: >> Howdy All, >> >> You may notice from today forward that as you open pull requests and >> make commits to them there will be a status indicator about testing on >> Travis. As of https://github.com/Katello/katello/pull/925 we are trying >> out a Travis configuration that will run the following on all pull >> requests, repository merges, and updates to pull requests. >> >> - CLI unittests >> - Pylint >> - SCSS compilation >> - Rspec unittests >> >> The configuration is currently setup to fail-fast. In other words, it >> will not run all 4 all of the time, it attempts to be as quick as >> possible, such that if one fails, the build is flagged as failed and >> execution stops. >> >> This may require some tuning as we get used to it, so please provide any >> feedback or thoughts on the process as we begin to use it. >> >> - Eric >> > > It looks great! > > Just one thought against the fail-fast approach: > I made a pull request with some server side changes and the tests > around it weren't executed at all because of failing cli unit tests. > In this case the test report was not very useful. Is it possible to > always run all the tests or is it too resource consuming? > > T. > > >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > From lzap at redhat.com Mon Oct 29 13:54:49 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 29 Oct 2012 14:54:49 +0100 Subject: [katello-devel] When does Puppet start In-Reply-To: <56343345B145C043AE990701E3D19395B9E9C7@EXVS2.nrplc.localnet> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> <508AA5B4.1020106@redhat.com> <20121026151416.GV3926@lzapx.brq.redhat.com> <508AB75D.5050607@redhat.com> <20121029103221.GF2137@lzapx.brq.redhat.com> <56343345B145C043AE990701E3D19395B9E9C7@EXVS2.nrplc.localnet> Message-ID: <20121029135449.GM2137@lzapx.brq.redhat.com> Katello does not support Foreman yet, therefore our Puppet codebase is currently only for installing Katello itself. What you mean by install kernel? We will use Puppet the way it is integrated in Foreman. Have a look at www.theforeman.org to see how it works. Basically, puppet is usually integrated in the kickstart file. During the first boot, it negotiates SSL certificates with the puppet master and then makes initial configuration. Then you run it either from cron or using a daemon to re-apply the configuration over and over again. LZ On Mon, Oct 29, 2012 at 10:53:41AM -0000, Innes, Duncan wrote: > Hi folks, > > Hopefully this isn't an entirely stupid question. I'm trying to find out > where Puppet will start processing during the whole build phase in > Katello. > > Is there anything of Puppet running during the install kernel? It would > be neat if it does as that would enable machines to be fully configured > on first boot. But I can see the scope of Puppet being large enough to > avoid running it in the install kernel. What direction has Puppet > integration taken? > > If there's any good documentation on the process that I can read, I'm > happy to do that. > > Cheers > > Duncan > > > This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Authorised and regulated by the Financial Services Authority. > > The following companies also trade as Virgin Money and are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: > > Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482) are authorised and regulated by the Financial Services Authority. > > Virgin Money Cards Limited (Company no. 4232392) is introducer appointed representative only of Virgin Money Personal Financial Service Limited. > > For further details of Virgin Money group companies please visit our website at virginmoney.com > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From Duncan.Innes at virginmoney.com Mon Oct 29 16:05:54 2012 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Mon, 29 Oct 2012 16:05:54 -0000 Subject: [katello-devel] When does Puppet start In-Reply-To: <20121029135449.GM2137@lzapx.brq.redhat.com> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com><508AA5B4.1020106@redhat.com><20121026151416.GV3926@lzapx.brq.redhat.com><508AB75D.5050607@redhat.com><20121029103221.GF2137@lzapx.brq.redhat.com><56343345B145C043AE990701E3D19395B9E9C7@EXVS2.nrplc.localnet> <20121029135449.GM2137@lzapx.brq.redhat.com> Message-ID: <56343345B145C043AE990701E3D19395B9E9D1@EXVS2.nrplc.localnet> Thanks Lukas, I thought there was already some integration of Puppet beyond installing Katello itself. It's been a while since I've installed the package to test/play around. By "install kernel" I meant the ability to run any Puppet stuff during the install phase - much like post-installation scripts on the current Satellite platform. Gives us the ability to harden a server before it first boots, but I can see Puppet being too much a nightmare to have running before the first boot. D On Mon, Oct 29, 2012 at 13:53PM, Zapletal Lukas wrote: > Katello does not support Foreman yet, therefore our Puppet > codebase is currently only for installing Katello itself. > > What you mean by install kernel? > > We will use Puppet the way it is integrated in Foreman. Have > a look at www.theforeman.org to see how it works. > > Basically, puppet is usually integrated in the kickstart > file. During the first boot, it negotiates SSL certificates > with the puppet master and then makes initial configuration. > Then you run it either from cron or using a daemon to > re-apply the configuration over and over again. > > LZ > > On Mon, Oct 29, 2012 at 10:53:41AM -0000, Innes, Duncan wrote: > > Hi folks, > > > > Hopefully this isn't an entirely stupid question. I'm trying to find > > out where Puppet will start processing during the whole build phase in > > Katello. > > > > Is there anything of Puppet running during the install kernel? It > > would be neat if it does as that would enable machines to be fully > > configured on first boot. But I can see the scope of Puppet being > > large enough to avoid running it in the install kernel. What > > direction has Puppet integration taken? > > > > If there's any good documentation on the process that I can read, I'm > > happy to do that. > > > > Cheers > > > > Duncan > > > > _______________________________________________ > > 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 > This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Authorised and regulated by the Financial Services Authority. The following companies also trade as Virgin Money and are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482) are authorised and regulated by the Financial Services Authority. Virgin Money Cards Limited (Company no. 4232392) is introducer appointed representative only of Virgin Money Personal Financial Service Limited. For further details of Virgin Money group companies please visit our website at virginmoney.com From lzap at redhat.com Mon Oct 29 16:11:27 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 29 Oct 2012 17:11:27 +0100 Subject: [katello-devel] When does Puppet start In-Reply-To: <56343345B145C043AE990701E3D19395B9E9D1@EXVS2.nrplc.localnet> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> <508AA5B4.1020106@redhat.com> <20121026151416.GV3926@lzapx.brq.redhat.com> <508AB75D.5050607@redhat.com> <20121029103221.GF2137@lzapx.brq.redhat.com> <56343345B145C043AE990701E3D19395B9E9C7@EXVS2.nrplc.localnet> <20121029135449.GM2137@lzapx.brq.redhat.com> <56343345B145C043AE990701E3D19395B9E9D1@EXVS2.nrplc.localnet> Message-ID: <20121029161127.GO2137@lzapx.brq.redhat.com> I think this is doable with Puppet, Foreman defaults to run Puppet in the anaconda post-install section too. I recommend trying Foreman standalone, until we fully integrate it in Katello. LZ On Mon, Oct 29, 2012 at 04:05:54PM -0000, Innes, Duncan wrote: > Thanks Lukas, > > I thought there was already some integration of Puppet beyond installing > Katello itself. It's been a while since I've installed the package to > test/play around. > > By "install kernel" I meant the ability to run any Puppet stuff during > the install phase - much like post-installation scripts on the current > Satellite platform. > > Gives us the ability to harden a server before it first boots, but I can > see Puppet being too much a nightmare to have running before the first > boot. > > D > > On Mon, Oct 29, 2012 at 13:53PM, Zapletal Lukas wrote: > > Katello does not support Foreman yet, therefore our Puppet > > codebase is currently only for installing Katello itself. > > > > What you mean by install kernel? > > > > We will use Puppet the way it is integrated in Foreman. Have > > a look at www.theforeman.org to see how it works. > > > > Basically, puppet is usually integrated in the kickstart > > file. During the first boot, it negotiates SSL certificates > > with the puppet master and then makes initial configuration. > > Then you run it either from cron or using a daemon to > > re-apply the configuration over and over again. > > > > LZ > > > > On Mon, Oct 29, 2012 at 10:53:41AM -0000, Innes, Duncan wrote: > > > Hi folks, > > > > > > Hopefully this isn't an entirely stupid question. I'm trying to find > > > > out where Puppet will start processing during the whole build phase > in > > > Katello. > > > > > > Is there anything of Puppet running during the install kernel? It > > > would be neat if it does as that would enable machines to be fully > > > configured on first boot. But I can see the scope of Puppet being > > > large enough to avoid running it in the install kernel. What > > > direction has Puppet integration taken? > > > > > > If there's any good documentation on the process that I can read, > I'm > > > happy to do that. > > > > > > Cheers > > > > > > Duncan > > > > > > _______________________________________________ > > > 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 > > > > > This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Authorised and regulated by the Financial Services Authority. > > The following companies also trade as Virgin Money and are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: > > Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482) are authorised and regulated by the Financial Services Authority. > > Virgin Money Cards Limited (Company no. 4232392) is introducer appointed representative only of Virgin Money Personal Financial Service Limited. > > For further details of Virgin Money group companies please visit our website at virginmoney.com -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Mon Oct 29 16:26:33 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 29 Oct 2012 17:26:33 +0100 Subject: [katello-devel] Query regarding katello-reset-dbs script for headpin In-Reply-To: <702216376.7664537.1350915612799.JavaMail.root@redhat.com> References: <702216376.7664537.1350915612799.JavaMail.root@redhat.com> Message-ID: <508EAE39.3060405@redhat.com> On 10/22/2012 04:20 PM, Tazim Kolhar wrote: > Now, while executing this script a password prompt appears . > What should be the ideal password provided to proceed further. Which is fine, we need to protect db with password. su - postgres or provide the password (katellopw is the default for katello-configure) -- Miroslav Suchy Red Hat Systems Management Engineering From msuchy at redhat.com Mon Oct 29 16:30:41 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 29 Oct 2012 17:30:41 +0100 Subject: [katello-devel] Tried to install from https://fedorahosted.org/katello/wiki/DevelopmentSetup In-Reply-To: <5085A5F6.5030207@redhat.com> References: <50859CFA.1050901@redhat.com> <5085A247.4020009@redhat.com> <5085A5F6.5030207@redhat.com> Message-ID: <508EAF31.2000901@redhat.com> On 10/22/2012 10:00 PM, Bryan Kearney wrote: > I think the issue here is that I installed from 1.1, so there was no > foreman oauth done when running katello-configure. So, I am going to > switch to re-install from the nightlies and see what I get. http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-1.2.1-1.fc16.noarch.rpm -- Miroslav Suchy Red Hat Systems Management Engineering From bkearney at redhat.com Mon Oct 29 17:42:14 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 29 Oct 2012 13:42:14 -0400 Subject: [katello-devel] F16 nightly In-Reply-To: <20121029081429.GC2137@lzapx.brq.redhat.com> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> <508AA5B4.1020106@redhat.com> <20121026151416.GV3926@lzapx.brq.redhat.com> <508AB75D.5050607@redhat.com> <20121029081429.GC2137@lzapx.brq.redhat.com> Message-ID: <508EBFF6.5030501@redhat.com> Latest test. From a clean install of Fedora 16, I do the following: 1) rpm -Uvh http://fedorapeople.org/groups/katello/releases/yum/nightly/Fedora/16/x86_64/katello-repos-latest.rpm 2) yum install katello-all 3) katello-configure I get the following error in the db_seed.log file: ** Invoke seed_with_logging (first_time) ** Invoke db:seed (first_time) ** Invoke db:abort_if_pending_migrations (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:abort_if_pending_migrations ** Execute db:seed rake aborted! could not find foreman-admin-user /usr/share/katello/db/seeds.rb:45 /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in `load' /usr/lib/ruby/gems/1.8/gems/activesupport-3.0.10/lib/active_support/dependencies.rb:235:in `load' packageset: [root at ktdev ~]# rpm -qa | egrep '(foreman)|(katello)' katello-all-1.2.1-1.git.225.ab7e134.fc16.noarch katello-cli-common-1.2.1-1.git.95.b2e3af2.fc16.noarch foreman-postgresql-1.0.1-24.652b81b.fc16.noarch katello-glue-foreman-1.2.1-1.git.225.ab7e134.fc16.noarch rubygem-foreman_api-0.0.7-2.fc16.noarch katello-repos-1.2.1-1.git.34.5c113ae.fc16.noarch katello-candlepin-cert-key-pair-1.0-1.noarch katello-qpid-client-key-pair-1.0-1.noarch katello-cli-1.2.1-1.git.95.b2e3af2.fc16.noarch foreman-1.0.1-24.652b81b.fc16.noarch katello-certs-tools-1.1.9-1.fc16.noarch katello-common-1.2.1-1.git.225.ab7e134.fc16.noarch katello-selinux-1.1.2-1.fc16.noarch katello-glue-pulp-1.2.1-1.git.225.ab7e134.fc16.noarch katello-qpid-broker-key-pair-1.0-1.noarch katello-configure-1.2.0-1.git.267.08fa70c.fc16.noarch katello-glue-candlepin-1.2.1-1.git.225.ab7e134.fc16.noarch katello-1.2.1-1.git.225.ab7e134.fc16.noarch From lzap at redhat.com Mon Oct 29 17:51:26 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 29 Oct 2012 18:51:26 +0100 Subject: [katello-devel] Help with bundler issue Message-ID: <20121029175126.GB2889@lzapx.brq.redhat.com> Hey, with my change https://github.com/Katello/katello/pull/941 I have introduced new "foreman" group in the Gemfile: group :foreman do gem 'foreman_api', '>= 0.0.7' end Now, if I do bundle install --local --without foreman with the latest bundler, it works on my laptop. The very same for bundler bundler-1.0.15 which is on RHEL6. The issue is in the production mode, it does not work. If you try to run the above command, it prints: # bundle install --local --without foreman Could not find gem 'foreman_api (>= 0.0.7, runtime)' in any of the gem sources listed in your Gemfile. Meaning it is installing WITH foreman group. There must be a snag or something. HELP. ps - currently both katello and headping nighlies are NOW working I am working on that right now -- Later, Lukas "lzap" Zapletal #katello #systemengine From ehelms at redhat.com Mon Oct 29 18:21:11 2012 From: ehelms at redhat.com (Eric Helms) Date: Mon, 29 Oct 2012 14:21:11 -0400 Subject: [katello-devel] Travis is GREEN Message-ID: <508EC917.6010602@redhat.com> As of this email, Travis testing is GREEN for 1.8.7 and 1.9.3. There are a few pull requests opened prior to integration which may say failed, we don't need to re-open these but keep your eyes out for Travis failures that could get introduced after the fact. Since Travis also runs the tests whenever code is merged, if the test suite gets broken by a merged PR, Travis will notify. By and large from this point on, all pull requests should be Green before getting into the code base. There may be exceptions where Travis is having issues, or a fix is overly critical. However, care should be taken to right the ship as soon as possible. - Eric From lzap at redhat.com Mon Oct 29 19:06:35 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 29 Oct 2012 20:06:35 +0100 Subject: [katello-devel] Help with bundler issue In-Reply-To: <20121029175126.GB2889@lzapx.brq.redhat.com> References: <20121029175126.GB2889@lzapx.brq.redhat.com> Message-ID: <20121029190635.GF2889@lzapx.brq.redhat.com> Strange, it looks like the foreman_api gem needs to be installed. Than it works and bundler creates a profile without foreman group. But I don't get it - it does not make sense. I would expect --without option NOT to require it. At least this works on my laptop in the rbenv environment. Ok at least we have a workaround for headpin nightly: please install rubygem-foreman_api before running configure until I find solution. I think I am giving up for today. LZ On Mon, Oct 29, 2012 at 06:51:26PM +0100, Lukas Zapletal wrote: > Hey, > > with my change > > https://github.com/Katello/katello/pull/941 > > I have introduced new "foreman" group in the Gemfile: > > group :foreman do > gem 'foreman_api', '>= 0.0.7' > end > > Now, if I do > > bundle install --local --without foreman > > with the latest bundler, it works on my laptop. The very same for > bundler bundler-1.0.15 which is on RHEL6. > > The issue is in the production mode, it does not work. If you try to run > the above command, it prints: > > # bundle install --local --without foreman > Could not find gem 'foreman_api (>= 0.0.7, runtime)' in any of the gem > sources listed in your Gemfile. > > Meaning it is installing WITH foreman group. > > There must be a snag or something. HELP. > > ps - currently both katello and headping nighlies are NOW working I am > working on that right now > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > 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 Oct 29 19:39:36 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 29 Oct 2012 15:39:36 -0400 Subject: [katello-devel] When does Puppet start In-Reply-To: <56343345B145C043AE990701E3D19395B9E9D1@EXVS2.nrplc.localnet> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com><508AA5B4.1020106@redhat.com><20121026151416.GV3926@lzapx.brq.redhat.com><508AB75D.5050607@redhat.com><20121029103221.GF2137@lzapx.brq.redhat.com><56343345B145C043AE990701E3D19395B9E9C7@EXVS2.nrplc.localnet> <20121029135449.GM2137@lzapx.brq.redhat.com> <56343345B145C043AE990701E3D19395B9E9D1@EXVS2.nrplc.localnet> Message-ID: <508EDB78.3010903@redhat.com> On 10/29/2012 12:05 PM, Innes, Duncan wrote: > Thanks Lukas, > > I thought there was already some integration of Puppet beyond installing > Katello itself. It's been a while since I've installed the package to > test/play around. > > By "install kernel" I meant the ability to run any Puppet stuff during > the install phase - much like post-installation scripts on the current > Satellite platform. > > Gives us the ability to harden a server before it first boots, but I can > see Puppet being too much a nightmare to have running before the first > boot. > Our first plan is to integrate foreman and it's puppe capabilities, which are post boot configuration mostly. --- bk From jlabocki at redhat.com Tue Oct 30 00:23:06 2012 From: jlabocki at redhat.com (James Labocki) Date: Mon, 29 Oct 2012 20:23:06 -0400 (EDT) Subject: [katello-devel] When does Puppet start In-Reply-To: <508EDB78.3010903@redhat.com> References: <1836996497.12780102.1351263516079.JavaMail.root@redhat.com> <508AA5B4.1020106@redhat.com> <20121026151416.GV3926@lzapx.brq.redhat.com> <508AB75D.5050607@redhat.com> <20121029103221.GF2137@lzapx.brq.redhat.com> <56343345B145C043AE990701E3D19395B9E9C7@EXVS2.nrplc.localnet> <20121029135449.GM2137@lzapx.brq.redhat.com> <56343345B145C043AE990701E3D19395B9E9D1@EXVS2.nrplc.localnet> <508EDB78.3010903@redhat.com> Message-ID: <0B3930CF-3842-47C6-BE98-B20423F714C1@redhat.com> Hot off the presses, just for you http://allthingsopen.com/2012/10/29/puppet-enterprise-and-red-hat-cloudforms/ On Oct 29, 2012, at 3:38 PM, Bryan Kearney wrote: > On 10/29/2012 12:05 PM, Innes, Duncan wrote: >> Thanks Lukas, >> >> I thought there was already some integration of Puppet beyond installing >> Katello itself. It's been a while since I've installed the package to >> test/play around. >> >> By "install kernel" I meant the ability to run any Puppet stuff during >> the install phase - much like post-installation scripts on the current >> Satellite platform. >> >> Gives us the ability to harden a server before it first boots, but I can >> see Puppet being too much a nightmare to have running before the first >> boot. > > Our first plan is to integrate foreman and it's puppe capabilities, which are post boot configuration mostly. > > --- bk > > > _______________________________________________ > 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 lzap at redhat.com Tue Oct 30 13:02:03 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 30 Oct 2012 14:02:03 +0100 Subject: [katello-devel] Running katello-configure after katello-upgrade Message-ID: <20121030130203.GB2139@lzapx.brq.redhat.com> Hello, I already slightly touched this topic, but I want to bring it again. Our upgrade instructions are pretty simple: https://fedorahosted.org/katello/wiki/Upgrade In short: 1) yum upgrade 2) review rpmnew files (but do not rewrite current configuration) ** 3) katello-upgrade 4) optional step: do katello-configure --anser-file=... The topic I want to bring in are steps 2 and 4. We distribute new default versions of configuration files which are stored as rpmnew by yum. Traditional approach is to review the changes and incorporate them. But in our case, some files are substantially different and changes made by katello-configure are hard to incorporate. I recommend to make the step 4 required, so after successful upgrade, user is asked to run katello-configure to redeploy all the config files. Thank to this, step 2 can be safely skipped for katello configuration files deleting all the rpmnew files - this step will be only necessary for system files. The second approach could be just to ask user to do manual incorporation which can be really messy, lot of work and users tend to make mistakes here. And since we have the configuration recipes available in our katello-configure (in Puppet), I don't see the reason why would we ask to do this. Therefore I recommend to make step 4 required and still ask user to do his own review in step 2 (but asking not to overwrite katello-related files). I have modified our upgrade wiki in this way. I am also doing configuration files review between versions, I want to make this part of our standard Katello upgrade process, so we can discuss the changes before each release. Opinions? ** - there has been some confusion due to poorly documented step no. 2 but I rewrote this part of the upgrade guide on the wiki -- Later, Lukas "lzap" Zapletal #katello #systemengine From thomasmckay at redhat.com Tue Oct 30 13:54:34 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 30 Oct 2012 09:54:34 -0400 (EDT) Subject: [katello-devel] Running katello-configure after katello-upgrade In-Reply-To: <20121030130203.GB2139@lzapx.brq.redhat.com> Message-ID: <2010393131.13915731.1351605274347.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Tuesday, October 30, 2012 9:02:03 AM > Subject: [katello-devel] Running katello-configure after katello-upgrade > > Hello, > > I already slightly touched this topic, but I want to bring it again. > > Our upgrade instructions are pretty simple: > > https://fedorahosted.org/katello/wiki/Upgrade > > In short: > > 1) yum upgrade > 2) review rpmnew files (but do not rewrite current configuration) ** > 3) katello-upgrade > 4) optional step: do katello-configure --anser-file=... > > The topic I want to bring in are steps 2 and 4. We distribute new > default versions of configuration files which are stored as rpmnew by > yum. Traditional approach is to review the changes and incorporate > them. > But in our case, some files are substantially different and changes > made > by katello-configure are hard to incorporate. > > I recommend to make the step 4 required, so after successful upgrade, > user is asked to run katello-configure to redeploy all the config > files. > Thank to this, step 2 can be safely skipped for katello configuration > files deleting all the rpmnew files - this step will be only > necessary > for system files. > > The second approach could be just to ask user to do manual > incorporation > which can be really messy, lot of work and users tend to make > mistakes > here. And since we have the configuration recipes available in our > katello-configure (in Puppet), I don't see the reason why would we > ask > to do this. > > Therefore I recommend to make step 4 required and still ask user to > do > his own review in step 2 (but asking not to overwrite katello-related > files). I have modified our upgrade wiki in this way. > > I am also doing configuration files review between versions, I want > to > make this part of our standard Katello upgrade process, so we can > discuss the changes before each release. > > Opinions? > > ** - there has been some confusion due to poorly documented step no. > 2 > but I rewrote this part of the upgrade guide on the wiki > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > Can you confirm that running katello-configure after the upgrade will not require previously-registered systems to update any certs? (ie. they will continue working without needing any updates) From sghai at redhat.com Tue Oct 30 14:17:26 2012 From: sghai at redhat.com (Sachin Ghai) Date: Tue, 30 Oct 2012 19:47:26 +0530 Subject: [katello-devel] Change the default org of a user Message-ID: <508FE176.4000800@redhat.com> Hi, I was trying to change the default org of a user. I created a user and assigned a role with following permissions: - Administer Organization - Modify organization and administer Environments User can select other org from org selector but can't change the default org. I'm not sure if its working as designed or a bug. But still I logged a defect: https://bugzilla.redhat.com/show_bug.cgi?id=871368 Any thoughts ? Regards, -Sachin From omaciel at redhat.com Tue Oct 30 14:18:15 2012 From: omaciel at redhat.com (Og Maciel) Date: Tue, 30 Oct 2012 10:18:15 -0400 (EDT) Subject: [katello-devel] Running katello-configure after katello-upgrade In-Reply-To: <20121030130203.GB2139@lzapx.brq.redhat.com> Message-ID: <1211940485.48449526.1351606695612.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Tuesday, October 30, 2012 9:02:03 AM > Subject: [katello-devel] Running katello-configure after katello-upgrade > > In short: > > 1) yum upgrade > 2) review rpmnew files (but do not rewrite current configuration) ** > 3) katello-upgrade > 4) optional step: do katello-configure --anser-file=... > > The topic I want to bring in are steps 2 and 4. We distribute new > default versions of configuration files which are stored as rpmnew by > yum. Traditional approach is to review the changes and incorporate > them. > But in our case, some files are substantially different and changes > made > by katello-configure are hard to incorporate. > > I recommend to make the step 4 required, so after successful upgrade, > user is asked to run katello-configure to redeploy all the config > files. > Thank to this, step 2 can be safely skipped for katello configuration > files deleting all the rpmnew files - this step will be only > necessary > for system files. If I understood this correctly we would be asking the user to perform all those 4 steps (or 3: 1, 3 and 4?) for an upgrade AND the last one to run katello-configure again with the answer-file option? If this is the case, all I have to say is that this feels extremely flaky and not "enterpris-y" at all imnsho. I should have to yum update katello-* && katello-upgrade and walk away. When I come back, it should all be working (or point me to a log if something failed). -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.646.707.7723 irc: omaciel From jrist at redhat.com Tue Oct 30 14:25:37 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 30 Oct 2012 08:25:37 -0600 Subject: [katello-devel] Change the default org of a user In-Reply-To: <508FE176.4000800@redhat.com> References: <508FE176.4000800@redhat.com> Message-ID: <508FE361.1080608@redhat.com> On 10/30/2012 08:17 AM, Sachin Ghai wrote: > Hi, > > I was trying to change the default org of a user. I created a user and > assigned a role with following permissions: > > - Administer Organization > - Modify organization and administer Environments > > User can select other org from org selector but can't change the default > org. > > I'm not sure if its working as designed or a bug. But still I logged a > defect: https://bugzilla.redhat.com/show_bug.cgi?id=871368 > > Any thoughts ? > > Regards, > -Sachin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Were you trying to change the user's default org as admin? If they're only assigned/access to one org, that will be their default and they will automatically go directly to that org after logging in. Otherwise that feature doesn't exist yet. -Jason -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From omaciel at redhat.com Tue Oct 30 14:29:17 2012 From: omaciel at redhat.com (Og Maciel) Date: Tue, 30 Oct 2012 10:29:17 -0400 (EDT) Subject: [katello-devel] Change the default org of a user In-Reply-To: <508FE361.1080608@redhat.com> Message-ID: <978035097.48458870.1351607357879.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Jason Rist" > To: katello-devel at redhat.com > Sent: Tuesday, October 30, 2012 10:25:37 AM > Subject: Re: [katello-devel] Change the default org of a user > > Were you trying to change the user's default org as admin? If they're > only assigned/access to one org, that will be their default and they > will automatically go directly to that org after logging in. > Otherwise > that feature doesn't exist yet. I believe he was logged as the user and trying to change his own default org. -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.646.707.7723 irc: omaciel From lzap at redhat.com Tue Oct 30 14:41:56 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 30 Oct 2012 15:41:56 +0100 Subject: [katello-devel] Running katello-configure after katello-upgrade In-Reply-To: <1211940485.48449526.1351606695612.JavaMail.root@redhat.com> References: <20121030130203.GB2139@lzapx.brq.redhat.com> <1211940485.48449526.1351606695612.JavaMail.root@redhat.com> Message-ID: <20121030144156.GD2139@lzapx.brq.redhat.com> On Tue, Oct 30, 2012 at 10:18:15AM -0400, Og Maciel wrote: > If I understood this correctly we would be asking the user to perform all those 4 steps (or 3: 1, 3 and 4?) for an upgrade AND the last one to run katello-configure again with the answer-file option? If this is the case, all I have to say is that this feels extremely flaky and not "enterpris-y" at all imnsho. I should have to yum update katello-* && katello-upgrade and walk away. When I come back, it should all be working (or point me to a log if something failed). Please see my review to see what we need to implement manually using sed, bash and other various scripts. Or we can just run Puppet to do it for us. No matter how it looks like, it is fairly effective to use Puppet for that. By the way we can create a script in katello-upgrade that would call katello-configure automatically of course. That is the plan. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Oct 30 16:10:42 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 30 Oct 2012 17:10:42 +0100 Subject: [katello-devel] Katello nightly issue Message-ID: <20121030161042.GK2139@lzapx.brq.redhat.com> Hey, Petr tracked down the issue a bit. It looks like something (katello-configure perhaps) is mangling /var/lib/foreman directory which is then smylinked in the /usr/share/foreman/tmp dir. It's missing. I had dueties in regard to the upgrades today, please have a look on it if possible. Thanks. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From cperry at redhat.com Tue Oct 30 20:47:57 2012 From: cperry at redhat.com (Cliff Perry) Date: Tue, 30 Oct 2012 20:47:57 +0000 Subject: [katello-devel] Python books In-Reply-To: <5088F358.7050309@redhat.com> References: <1693365076.16743836.1351080692939.JavaMail.root@redhat.com> <1382882345.16743925.1351080721781.JavaMail.root@redhat.com> <20121024131508.GH13385@lzapx.brq.redhat.com> <5087EBB9.4040108@redhat.com> <5088F358.7050309@redhat.com> Message-ID: <50903CFD.6020407@redhat.com> On 10/25/2012 09:07 AM, Cliff Perry wrote: > On 10/24/2012 02:23 PM, Eric Helms wrote: >> No personal experience but http://learnpythonthehardway.org/ get's a lot >> of good reviews. The Python documentation itself is quite good and I > > I did not think the above was for experienced programmers, looking to > pick up another language. > - My 10 yr old is on Chapter 24 of the above url, and he is enjoying it. > I get to help him learn how to debug tracebacks ;) OK, he just finished chapter 44 with a combination of while, if and other loops for a simple text game giving you choices. Once I helped him figure out indentation, and other syntax, he fixed his logic issues to make it work as he intended. Still needs to learn to do more error checking for non-straight-line input. He is still enjoying it :) Cliff > > Cliff > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From sghai at redhat.com Wed Oct 31 08:31:50 2012 From: sghai at redhat.com (Sachin Ghai) Date: Wed, 31 Oct 2012 14:01:50 +0530 Subject: [katello-devel] Change the default org of a user In-Reply-To: <508FE361.1080608@redhat.com> References: <508FE176.4000800@redhat.com> <508FE361.1080608@redhat.com> Message-ID: <5090E1F6.300@redhat.com> On 10/30/2012 07:55 PM, Jason Rist wrote: > On 10/30/2012 08:17 AM, Sachin Ghai wrote: >> Hi, >> >> I was trying to change the default org of a user. I created a user and >> assigned a role with following permissions: >> >> - Administer Organization >> - Modify organization and administer Environments >> >> User can select other org from org selector but can't change the default >> org. >> >> I'm not sure if its working as designed or a bug. But still I logged a >> defect: https://bugzilla.redhat.com/show_bug.cgi?id=871368 >> >> Any thoughts ? >> >> Regards, >> -Sachin >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > > Were you trying to change the user's default org as admin? If they're > only assigned/access to one org, that will be their default and they > will automatically go directly to that org after logging in. Otherwise > that feature doesn't exist yet. > > -Jason > I created a user 'testuser' and assigned permissions to Administer/modify organization. Then I login with 'testuser' and tried to change his default org. But I think as Corey mentioned, that page is for setting default org for systems registered through this user. Thanks & Regards, -Sachin From msuchy at redhat.com Wed Oct 31 09:50:48 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 31 Oct 2012 10:50:48 +0100 Subject: [katello-devel] Running katello-configure after katello-upgrade In-Reply-To: <20121030130203.GB2139@lzapx.brq.redhat.com> References: <20121030130203.GB2139@lzapx.brq.redhat.com> Message-ID: <5090F478.9050802@redhat.com> On 10/30/2012 02:02 PM, Lukas Zapletal wrote: > 2) review rpmnew files (but do not rewrite current configuration) ** I would skip this step completely. a) RHEL does not tell admin to do the review neither. b) config are managed by katello-configure But we may put this step on very end as optional. E.g. if you modify log_level in katello.yml, katello-configure will overwrite it. So user may want to return such changes back. > 4) optional step: do katello-configure --anser-file=... Why the usage of --answer-file? If you run it without answer file, it will use values used from previous installation/upgrade. We may even put it as last step of katello-upgrade. -- Miroslav Suchy Red Hat Systems Management Engineering From lzap at redhat.com Wed Oct 31 10:53:22 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 31 Oct 2012 11:53:22 +0100 Subject: [katello-devel] Running katello-configure after katello-upgrade In-Reply-To: <5090F478.9050802@redhat.com> References: <20121030130203.GB2139@lzapx.brq.redhat.com> <5090F478.9050802@redhat.com> Message-ID: <20121031105322.GH2118@lzapx.brq.redhat.com> On Wed, Oct 31, 2012 at 10:50:48AM +0100, Miroslav Suchy wrote: > On 10/30/2012 02:02 PM, Lukas Zapletal wrote: > >2) review rpmnew files (but do not rewrite current configuration) ** > > I would skip this step completely. > a) RHEL does not tell admin to do the review neither. > b) config are managed by katello-configure > > But we may put this step on very end as optional. E.g. if you modify > log_level in katello.yml, katello-configure will overwrite it. So > user may want to return such changes back. Right, I have already edited the wiki page only making note IF user want to review configuration files he needs to be aware NOT to overwrite any of the katello ones: https://fedorahosted.org/katello/wiki/Upgrade#UpgradeRPMfiles > >4) optional step: do katello-configure --anser-file=... > > Why the usage of --answer-file? If you run it without answer file, > it will use values used from previous installation/upgrade. > We may even put it as last step of katello-upgrade. We currently do not load the answer file automatically. I am not sure what is the "correct" behavior. Maybe loading it and providing new option like --purge-options would be nice feature, yeah. -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Wed Oct 31 12:19:49 2012 From: msuchy at redhat.com (=?ISO-8859-2?Q?Miroslav_Such=FD?=) Date: Wed, 31 Oct 2012 13:19:49 +0100 Subject: [katello-devel] Dropping katello-reset-dbs Message-ID: <50911765.2010501@redhat.com> Looking at: https://bugzilla.redhat.com/show_bug.cgi?id=868872 I would suggest to drop katello-reset-dbs completly in favour of katello-configure --reset-data=YES Any objection? -- Miroslav Suchy Red Hat Systems Management Engineering From thomasmckay at redhat.com Wed Oct 31 12:58:18 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 31 Oct 2012 08:58:18 -0400 (EDT) Subject: [katello-devel] Dropping katello-reset-dbs In-Reply-To: <50911765.2010501@redhat.com> Message-ID: <748124990.14414281.1351688298666.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Miroslav Such?" > To: "katello-devel" > Sent: Wednesday, October 31, 2012 8:19:49 AM > Subject: [katello-devel] Dropping katello-reset-dbs > > Looking at: > https://bugzilla.redhat.com/show_bug.cgi?id=868872 > > I would suggest to drop katello-reset-dbs completly in favour of > katello-configure --reset-data=YES > > Any objection? > > -- > Miroslav Suchy > Red Hat Systems Management Engineering > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > No objections here. From jrist at redhat.com Wed Oct 31 13:32:48 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 31 Oct 2012 07:32:48 -0600 Subject: [katello-devel] Dropping katello-reset-dbs In-Reply-To: <50911765.2010501@redhat.com> References: <50911765.2010501@redhat.com> Message-ID: <50912880.8030508@redhat.com> On 10/31/2012 06:19 AM, Miroslav Such? wrote: > Looking at: > https://bugzilla.redhat.com/show_bug.cgi?id=868872 > > I would suggest to drop katello-reset-dbs completly in favour of > katello-configure --reset-data=YES > > Any objection? > No objection. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist github/identi.ca: knowncitizen From bbuckingham at redhat.com Wed Oct 31 14:54:58 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Wed, 31 Oct 2012 10:54:58 -0400 Subject: [katello-devel] Dropping katello-reset-dbs In-Reply-To: <50911765.2010501@redhat.com> References: <50911765.2010501@redhat.com> Message-ID: <50913BC2.4080809@redhat.com> On 10/31/2012 08:19 AM, Miroslav Such? wrote: > Looking at: > https://bugzilla.redhat.com/show_bug.cgi?id=868872 > > I would suggest to drop katello-reset-dbs completly in favour of > katello-configure --reset-data=YES > > Any objection? > Is the suggestion to drop it completely for all environments (i.e. dev & production) or just for production? If for both, need to ensure that it also works in the development environment. From bkearney at redhat.com Wed Oct 31 15:13:34 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 31 Oct 2012 11:13:34 -0400 Subject: [katello-devel] Dropping katello-reset-dbs In-Reply-To: <50913BC2.4080809@redhat.com> References: <50911765.2010501@redhat.com> <50913BC2.4080809@redhat.com> Message-ID: <5091401E.9060000@redhat.com> On 10/31/2012 10:54 AM, Brad Buckingham wrote: > On 10/31/2012 08:19 AM, Miroslav Such? wrote: >> Looking at: >> https://bugzilla.redhat.com/show_bug.cgi?id=868872 >> >> I would suggest to drop katello-reset-dbs completly in favour of >> katello-configure --reset-data=YES >> >> Any objection? >> > Is the suggestion to drop it completely for all environments (i.e. dev & > production) or just for production? > > If for both, need to ensure that it also works in the development > environment. > And ideally documented here: https://fedorahosted.org/katello/wiki/DevelopmentSetup -- bk From jsherril at redhat.com Wed Oct 31 17:14:44 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 31 Oct 2012 13:14:44 -0400 Subject: [katello-devel] Dropping katello-reset-dbs In-Reply-To: <50913BC2.4080809@redhat.com> References: <50911765.2010501@redhat.com> <50913BC2.4080809@redhat.com> Message-ID: <50915C84.9010303@redhat.com> On 10/31/2012 10:54 AM, Brad Buckingham wrote: > On 10/31/2012 08:19 AM, Miroslav Such? wrote: >> Looking at: >> https://bugzilla.redhat.com/show_bug.cgi?id=868872 >> >> I would suggest to drop katello-reset-dbs completly in favour of >> katello-configure --reset-data=YES >> >> Any objection? >> > Is the suggestion to drop it completely for all environments (i.e. dev > & production) or just for production? > > If for both, need to ensure that it also works in the development > environment. Absolutely, and to be clear katello-configure would need to know the directory that katello is checked out to. Woud also be nice if we could somehow run katello-configure --reset-data=YES from our git checkout. -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel