From tkolhar at redhat.com Wed Aug 1 05:18:40 2012 From: tkolhar at redhat.com (Tazim Kolhar) Date: Wed, 1 Aug 2012 01:18:40 -0400 (EDT) Subject: [katello-devel] headpin vs. katello In-Reply-To: <929922042.23021237.1343755464126.JavaMail.root@redhat.com> Message-ID: <579137913.2274176.1343798320158.JavaMail.root@redhat.com> Hi, As per our discussion yesterday on irc #systemengine-qe I was supposed to open a BZ for the same But, a similar bug is already filed : https://bugzilla.redhat.com/show_bug.cgi?id=840859 So, I did not go ahead since I was confused, Please let me in case you still think to file a seperate bug for this issue. Thanks & Regards, Tazim ----- Original Message ----- From: "Tom McKay" To: "Tazim Kolhar" Cc: katello-devel at redhat.com Sent: Tuesday, July 31, 2012 10:54:24 PM Subject: headpin vs. katello Tazim (and others interested in headpin only installs), While we figure out how best to provide a community headpin install in relation to katello, I will suggest that if you want to "check out" the latest greatest features in headpin, that you install katello and then katello-configure it to headpin. This will not be a fully functional headpin install (eg. the 'katello' executable is used for command line), but it will show you the latest code. Over the next couple weeks we (myself, Jordan, and Adam) will be working on making headpin fully available in nightly, weekly, and release builds. Thanks! Tom From hbrock at redhat.com Wed Aug 1 12:33:22 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 1 Aug 2012 08:33:22 -0400 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <20120730100257.GE5373@lzapx.brq.redhat.com> References: <50124DDD.9040009@redhat.com> <20120730100257.GE5373@lzapx.brq.redhat.com> Message-ID: <20120801123322.GF15724@redhat.com> On Mon, Jul 30, 2012 at 12:02:57PM +0200, Lukas Zapletal wrote: > By the way, what are the biggest concerns in regard to using foreign > keys and rails? What is the issue? > Heh... the issue is that Active Record is quite happy to define relationships that would traditionally have required proper referential constraints in a database, without defining any constraints. So there is absolutely nothing stopping me (or a bug in Active Record) from deleting rows in the DB that are referenced by other rows, which can break your whole app horribly. The solution is simply to add proper constraints in your migrations. However most folks in the modern web-scale world seem happy to live with this level of risk and don't bother with the constraints, despite the fact that it makes us dinosaurs uncomfortable... --Hugh > > On Fri, Jul 27, 2012 at 10:14:21AM +0200, Miroslav Suchy wrote: > > While working on APIDocumentationEfforts [1] I wanted some nice > > documentation of our schema. I find we have none, so I created one: > > http://miroslav.suchy.cz/katello/katelloschema.html > > It is created by PostgreSQL Autodoc [2]. > > > > To my surprise it does not contain foreign keys and very few indexes. > > First I thought it is bug in Autodoc. But then - to my horor - I > > find it is not bug. We do not have foreign keys and indexes on most > > tables! > > > > So we have two issues. > > > > 1) Indexes: > > E.g. table user_notices, which purpose is IMHO always to live > > between two JOINS and is school example where indexes should be > > used, do not have indexes. > > I can go through schema and suggest where we should create indexes. > > I do not expect that it would cause any problem. > > Objections here? > > > > 2) Foreign keys: > > I read about foreign keys and ruby and I learned that community > > around Rails think that application level is best/enough to keep > > data consistency. So I expect a lot of discussion here. > > Let me share my point of view here: > > IMO data consistency should be work of database engine. > > There are two examples: > > a) when our code is fatally interrupted. E.g. > > > > src/app/models/glue/pulp/repo.rb: > > def destroy_repo_orchestration > > pre_queue.create(:name => "remove product content : > > #{self.name}", :priority => 1, :action => [self, :del_content]) > > [.. FATAL CRASH HERE ...] > > pre_queue.create(:name => "delete pulp repo : #{self.name}", > > :priority => 2, :action => [self, :destroy_repo]) > > end > > > > You will end up with repository with product id, which does not exist. > > Foreign keys with ON DELETE CASCADE solve this. > > > > b) But even if we solve all issues in our code (e.g start using > > transactions), there is problems with humans. > > During my 5 years in RHN Satellite team I seen non trivial numbers > > of Customers issues, where either customer or even TAM(!) run > > directly SQL commands, which without foreign keys would result in > > inconsistent database. > > Using foreign keys seems doable: > > https://github.com/matthuhiggins/foreigner > > https://github.com/jenseng/immigrant > > So it should be basically two gems, few lines of code and some testing. > > > > Your opinions? > > > > > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > > [2] http://www.rbt.ca/autodoc/ (available in Fedora as package) > > > > Mirek > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From ehelms at redhat.com Wed Aug 1 13:37:08 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 01 Aug 2012 09:37:08 -0400 Subject: [katello-devel] Faster development environment In-Reply-To: <50130FC2.8000707@redhat.com> References: <501268C9.6080908@redhat.com> <50130FC2.8000707@redhat.com> Message-ID: <50193104.8080502@redhat.com> On 07/27/2012 06:01 PM, Mike McCune wrote: > On 07/27/2012 03:09 AM, Pavel Pokorny wrote: >> Hi Katello developers, >> if you experience problems with the speed of development environment, >> try gem called rails-dev-boost[1]. >> Just add one line [2] to your Gemfile and run bundle. Every request is >> handled noticeable faster with this gem. >> >> [1]https://github.com/thedarkone/rails-dev-boost/ >> [2] gem 'rails-dev-boost', :git => >> 'git://github.com/thedarkone/rails-dev-boost.git', :require => >> 'rails_development_boost' > > thanks Pavel, this is *awesome* > > made my dev mode run almost as fast as production yet I was able to > make code changes without a restart > > Mike Any reason to not throw this into our Gemfile under development set? - Eric From jrist at redhat.com Wed Aug 1 13:38:54 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 01 Aug 2012 07:38:54 -0600 Subject: [katello-devel] Faster development environment In-Reply-To: <50193104.8080502@redhat.com> References: <501268C9.6080908@redhat.com> <50130FC2.8000707@redhat.com> <50193104.8080502@redhat.com> Message-ID: <5019316E.5090801@redhat.com> On Wed 01 Aug 2012 07:37:08 AM MDT, Eric Helms wrote: > On 07/27/2012 06:01 PM, Mike McCune wrote: >> On 07/27/2012 03:09 AM, Pavel Pokorny wrote: >>> Hi Katello developers, >>> if you experience problems with the speed of development environment, >>> try gem called rails-dev-boost[1]. >>> Just add one line [2] to your Gemfile and run bundle. Every request is >>> handled noticeable faster with this gem. >>> >>> [1]https://github.com/thedarkone/rails-dev-boost/ >>> [2] gem 'rails-dev-boost', :git => >>> 'git://github.com/thedarkone/rails-dev-boost.git', :require => >>> 'rails_development_boost' >> >> thanks Pavel, this is *awesome* >> >> made my dev mode run almost as fast as production yet I was able to >> make code changes without a restart >> >> Mike > Any reason to not throw this into our Gemfile under development set? > > - Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Additionally it'd be nice if we built this gem so it's not a 'from source' gem... -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bbuckingham at redhat.com Wed Aug 1 14:22:38 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Wed, 01 Aug 2012 10:22:38 -0400 Subject: [katello-devel] Faster development environment In-Reply-To: <5019316E.5090801@redhat.com> References: <501268C9.6080908@redhat.com> <50130FC2.8000707@redhat.com> <50193104.8080502@redhat.com> <5019316E.5090801@redhat.com> Message-ID: <50193BAE.3040309@redhat.com> On 08/01/2012 09:38 AM, Jason Rist wrote: > On Wed 01 Aug 2012 07:37:08 AM MDT, Eric Helms wrote: >> On 07/27/2012 06:01 PM, Mike McCune wrote: >>> On 07/27/2012 03:09 AM, Pavel Pokorny wrote: >>>> Hi Katello developers, >>>> if you experience problems with the speed of development environment, >>>> try gem called rails-dev-boost[1]. >>>> Just add one line [2] to your Gemfile and run bundle. Every request is >>>> handled noticeable faster with this gem. >>>> >>>> [1]https://github.com/thedarkone/rails-dev-boost/ >>>> [2] gem 'rails-dev-boost', :git => >>>> 'git://github.com/thedarkone/rails-dev-boost.git', :require => >>>> 'rails_development_boost' >>> >>> thanks Pavel, this is *awesome* >>> >>> made my dev mode run almost as fast as production yet I was able to >>> make code changes without a restart >>> >>> Mike >> Any reason to not throw this into our Gemfile under development set? >> >> - Eric >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > Additionally it'd be nice if we built this gem so it's not a 'from > source' gem... > > -J > +1. I've been using the gem for a few days now and I haven't come across any issues with it. Pavel, thanks for the contribution! From mrao at redhat.com Wed Aug 1 14:26:03 2012 From: mrao at redhat.com (Malini Rao) Date: Wed, 1 Aug 2012 10:26:03 -0400 (EDT) Subject: [katello-devel] Content search shared/unique terminology In-Reply-To: <5016EB9D.9050602@redhat.com> Message-ID: <316495671.7519135.1343831163914.JavaMail.root@redhat.com> ----- Original Message ----- From: "Jason Rist" To: katello-devel at redhat.com Sent: Monday, July 30, 2012 4:16:29 PM Subject: Re: [katello-devel] Content search shared/unique terminology On 07/30/2012 02:02 PM, Justin Sherrill wrote: > In the demo today it was brought up how poor the unique/shared > terminology was within content search and how we needed a tipsy tooltip > to better explain it, only with better naming. > > Corey brought up using union and difference instead of unique and shared > which i like a lot. Thoughts? > > > I've added the following tipsy in the meantime (please ignore the haml): > > =_('All:') > = _("Show all results regardless of which columns they exist in.") > =_('Shared:') > = _("Show only results that exist in all selected columns.") > =_('Unique:') > = _("Show only results not existing in all selected columns.") [ Malini ]---> I suggest a slight modification to the tipsy text - Instead of the word 'columns', I think we should say 'environments' > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I tend to agree with Corey. Union and Intersection (or difference?) are "normal" or accepted means of understanding. [ Malini ]---> If this is indeed common parlance, then I would suggest a change in the field label - Instead of "View : All/ Union/ Intersection", use "Content: All/ Union/Intersection" Otherwise I was going to suggest - "Content Display: All/ Shared by all / Missing in some" -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From ehelms at redhat.com Wed Aug 1 14:27:58 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 01 Aug 2012 10:27:58 -0400 Subject: [katello-devel] Katello YouTube Channel and Screencasts Message-ID: <50193CEE.2080805@redhat.com> The Katello Prokect now has a centralized place to host Videos and Screencasts relating to the Katello Project on our project YouTube channel: http://www.youtube.com/user/KatelloProject A reminder if you would like to do a screencast and are looking for a place to start please check the following: https://fedorahosted.org/katello/wiki/Screencasts https://www.redhat.com/archives/katello-devel/2012-July/msg00155.html If you have a video or screencast you would like included on the channel or if you see any information that needs updating or would like to contribute in these efforts please let me know. Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsherril at redhat.com Wed Aug 1 14:33:33 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 01 Aug 2012 10:33:33 -0400 Subject: [katello-devel] Content search shared/unique terminology In-Reply-To: <316495671.7519135.1343831163914.JavaMail.root@redhat.com> References: <316495671.7519135.1343831163914.JavaMail.root@redhat.com> Message-ID: <50193E3D.8040606@redhat.com> On 08/01/2012 10:26 AM, Malini Rao wrote: > > ----- Original Message ----- > From: "Jason Rist" > To: katello-devel at redhat.com > Sent: Monday, July 30, 2012 4:16:29 PM > Subject: Re: [katello-devel] Content search shared/unique terminology > > On 07/30/2012 02:02 PM, Justin Sherrill wrote: >> In the demo today it was brought up how poor the unique/shared >> terminology was within content search and how we needed a tipsy tooltip >> to better explain it, only with better naming. >> >> Corey brought up using union and difference instead of unique and shared >> which i like a lot. Thoughts? >> >> >> I've added the following tipsy in the meantime (please ignore the haml): >> >> =_('All:') >> = _("Show all results regardless of which columns they exist in.") >> =_('Shared:') >> = _("Show only results that exist in all selected columns.") >> =_('Unique:') >> = _("Show only results not existing in all selected columns.") > [ Malini ]---> I suggest a slight modification to the tipsy text - Instead of the word 'columns', I think we should say 'environments' > I originally had environments, but there are instances where the columns are not environments (like repo comparison). We might could change the tipsy text depending on which view you're in, but that seemed like too much work for the payoff. Thoughts? >> -Justin >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > I tend to agree with Corey. Union and Intersection (or difference?) are > "normal" or accepted means of understanding. > > > [ Malini ]---> If this is indeed common parlance, then I would suggest a change in the field label - > > Instead of "View : All/ Union/ Intersection", use "Content: All/ Union/Intersection" > > Otherwise I was going to suggest - > > "Content Display: All/ Shared by all / Missing in some" > From kybaker at redhat.com Wed Aug 1 14:34:45 2012 From: kybaker at redhat.com (Kyle Baker) Date: Wed, 1 Aug 2012 10:34:45 -0400 (EDT) Subject: [katello-devel] Content search shared/unique terminology In-Reply-To: <316495671.7519135.1343831163914.JavaMail.root@redhat.com> Message-ID: <1207605188.3670270.1343831685509.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > From: "Jason Rist" > To: katello-devel at redhat.com > Sent: Monday, July 30, 2012 4:16:29 PM > Subject: Re: [katello-devel] Content search shared/unique terminology > > On 07/30/2012 02:02 PM, Justin Sherrill wrote: > > In the demo today it was brought up how poor the unique/shared > > terminology was within content search and how we needed a tipsy > > tooltip > > to better explain it, only with better naming. > > > > Corey brought up using union and difference instead of unique and > > shared > > which i like a lot. Thoughts? > > > > > > I've added the following tipsy in the meantime (please ignore the > > haml): > > > > =_('All:') > > = _("Show all results regardless of which columns they exist in.") > > =_('Shared:') > > = _("Show only results that exist in all selected columns.") > > =_('Unique:') > > = _("Show only results not existing in all selected columns.") > > [ Malini ]---> I suggest a slight modification to the tipsy text - > Instead of the word 'columns', I think we should say 'environments' Agreed > > > > -Justin > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > I tend to agree with Corey. Union and Intersection (or difference?) > are > "normal" or accepted means of understanding. > > > [ Malini ]---> If this is indeed common parlance, then I would > suggest a change in the field label - > > Instead of "View : All/ Union/ Intersection", use "Content: All/ > Union/Intersection" I like this one best though I still think a tipsy is important to clear up confusion. > > Otherwise I was going to suggest - > > "Content Display: All/ Shared by all / Missing in some" > > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From ppokorny at redhat.com Wed Aug 1 14:39:05 2012 From: ppokorny at redhat.com (Pavel Pokorny) Date: Wed, 01 Aug 2012 16:39:05 +0200 Subject: [katello-devel] Faster development environment In-Reply-To: <50193BAE.3040309@redhat.com> References: <501268C9.6080908@redhat.com> <50130FC2.8000707@redhat.com> <50193104.8080502@redhat.com> <5019316E.5090801@redhat.com> <50193BAE.3040309@redhat.com> Message-ID: <50193F89.6070205@redhat.com> On 08/01/2012 04:22 PM, Brad Buckingham wrote: > On 08/01/2012 09:38 AM, Jason Rist wrote: >> On Wed 01 Aug 2012 07:37:08 AM MDT, Eric Helms wrote: >>> On 07/27/2012 06:01 PM, Mike McCune wrote: >>>> On 07/27/2012 03:09 AM, Pavel Pokorny wrote: >>>>> Hi Katello developers, >>>>> if you experience problems with the speed of development environment, >>>>> try gem called rails-dev-boost[1]. >>>>> Just add one line [2] to your Gemfile and run bundle. Every >>>>> request is >>>>> handled noticeable faster with this gem. >>>>> >>>>> [1]https://github.com/thedarkone/rails-dev-boost/ >>>>> [2] gem 'rails-dev-boost', :git => >>>>> 'git://github.com/thedarkone/rails-dev-boost.git', :require => >>>>> 'rails_development_boost' >>>> >>>> thanks Pavel, this is *awesome* >>>> >>>> made my dev mode run almost as fast as production yet I was able to >>>> make code changes without a restart >>>> >>>> Mike >>> Any reason to not throw this into our Gemfile under development set? >>> >>> - Eric >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> >> Additionally it'd be nice if we built this gem so it's not a 'from >> source' gem... >> >> -J >> > +1. I've been using the gem for a few days now and I haven't come > across any issues with it. > > Pavel, thanks for the contribution! > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I thought that you will like it:). I asked on github about new version release, if it stays without answer, I will build the gem myself and add it in our katello repo. The readme contains quite exhausting description of what may go wrong but I haven't found any issues in Katello yet. Pavel From lzap at redhat.com Wed Aug 1 14:57:48 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 1 Aug 2012 16:57:48 +0200 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <20120801123322.GF15724@redhat.com> References: <50124DDD.9040009@redhat.com> <20120730100257.GE5373@lzapx.brq.redhat.com> <20120801123322.GF15724@redhat.com> Message-ID: <20120801145748.GA3856@lzapx.brq.redhat.com> Ok so it's doable. What is your approach in Cloud Engine by the way? LZ On Wed, Aug 01, 2012 at 08:33:22AM -0400, Hugh Brock wrote: > On Mon, Jul 30, 2012 at 12:02:57PM +0200, Lukas Zapletal wrote: > > By the way, what are the biggest concerns in regard to using foreign > > keys and rails? What is the issue? > > > Heh... the issue is that Active Record is quite happy to define > relationships that would traditionally have required proper > referential constraints in a database, without defining any > constraints. So there is absolutely nothing stopping me (or a bug in > Active Record) from deleting rows in the DB that are referenced by > other rows, which can break your whole app horribly. > > The solution is simply to add proper constraints in your > migrations. However most folks in the modern web-scale world seem > happy to live with this level of risk and don't bother with the > constraints, despite the fact that it makes us dinosaurs > uncomfortable... > > --Hugh > > > > > > On Fri, Jul 27, 2012 at 10:14:21AM +0200, Miroslav Suchy wrote: > > > While working on APIDocumentationEfforts [1] I wanted some nice > > > documentation of our schema. I find we have none, so I created one: > > > http://miroslav.suchy.cz/katello/katelloschema.html > > > It is created by PostgreSQL Autodoc [2]. > > > > > > To my surprise it does not contain foreign keys and very few indexes. > > > First I thought it is bug in Autodoc. But then - to my horor - I > > > find it is not bug. We do not have foreign keys and indexes on most > > > tables! > > > > > > So we have two issues. > > > > > > 1) Indexes: > > > E.g. table user_notices, which purpose is IMHO always to live > > > between two JOINS and is school example where indexes should be > > > used, do not have indexes. > > > I can go through schema and suggest where we should create indexes. > > > I do not expect that it would cause any problem. > > > Objections here? > > > > > > 2) Foreign keys: > > > I read about foreign keys and ruby and I learned that community > > > around Rails think that application level is best/enough to keep > > > data consistency. So I expect a lot of discussion here. > > > Let me share my point of view here: > > > IMO data consistency should be work of database engine. > > > There are two examples: > > > a) when our code is fatally interrupted. E.g. > > > > > > src/app/models/glue/pulp/repo.rb: > > > def destroy_repo_orchestration > > > pre_queue.create(:name => "remove product content : > > > #{self.name}", :priority => 1, :action => [self, :del_content]) > > > [.. FATAL CRASH HERE ...] > > > pre_queue.create(:name => "delete pulp repo : #{self.name}", > > > :priority => 2, :action => [self, :destroy_repo]) > > > end > > > > > > You will end up with repository with product id, which does not exist. > > > Foreign keys with ON DELETE CASCADE solve this. > > > > > > b) But even if we solve all issues in our code (e.g start using > > > transactions), there is problems with humans. > > > During my 5 years in RHN Satellite team I seen non trivial numbers > > > of Customers issues, where either customer or even TAM(!) run > > > directly SQL commands, which without foreign keys would result in > > > inconsistent database. > > > Using foreign keys seems doable: > > > https://github.com/matthuhiggins/foreigner > > > https://github.com/jenseng/immigrant > > > So it should be basically two gems, few lines of code and some testing. > > > > > > Your opinions? > > > > > > > > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > > > [2] http://www.rbt.ca/autodoc/ (available in Fedora as package) > > > > > > Mirek > > > > > > _______________________________________________ > > > katello-devel mailing list > > > katello-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > -- > > Later, > > > > Lukas "lzap" Zapletal > > #katello #systemengine > > > > _______________________________________________ > > 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 > > _______________________________________________ > 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 Aug 1 15:11:07 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 1 Aug 2012 17:11:07 +0200 Subject: [katello-devel] Faster development environment In-Reply-To: <50193F89.6070205@redhat.com> References: <501268C9.6080908@redhat.com> <50130FC2.8000707@redhat.com> <50193104.8080502@redhat.com> <5019316E.5090801@redhat.com> <50193BAE.3040309@redhat.com> <50193F89.6070205@redhat.com> Message-ID: <20120801151107.GB3856@lzapx.brq.redhat.com> On Wed, Aug 01, 2012 at 04:39:05PM +0200, Pavel Pokorny wrote: > I thought that you will like it:). I asked on github about new > version release, if it stays without answer, I will build the gem > myself and add it in our katello repo. The readme contains quite > exhausting description of what may go wrong but I haven't found any > issues in Katello yet. Please do not do that. Either wait for the next release if you need any features from it or use latest stable release version. Making our own upstream "releases" is highway to hell. How about putting it in the development section using that :git => hash method for a while? -- Later, Lukas "lzap" Zapletal #katello #systemengine From mrao at redhat.com Wed Aug 1 15:11:21 2012 From: mrao at redhat.com (Malini Rao) Date: Wed, 1 Aug 2012 11:11:21 -0400 (EDT) Subject: [katello-devel] Content search shared/unique terminology In-Reply-To: <50193E3D.8040606@redhat.com> Message-ID: <324352992.7592474.1343833881570.JavaMail.root@redhat.com> ----- Original Message ----- From: "Justin Sherrill" To: katello-devel at redhat.com Sent: Wednesday, August 1, 2012 10:33:33 AM Subject: Re: [katello-devel] Content search shared/unique terminology On 08/01/2012 10:26 AM, Malini Rao wrote: > > ----- Original Message ----- > From: "Jason Rist" > To: katello-devel at redhat.com > Sent: Monday, July 30, 2012 4:16:29 PM > Subject: Re: [katello-devel] Content search shared/unique terminology > > On 07/30/2012 02:02 PM, Justin Sherrill wrote: >> In the demo today it was brought up how poor the unique/shared >> terminology was within content search and how we needed a tipsy tooltip >> to better explain it, only with better naming. >> >> Corey brought up using union and difference instead of unique and shared >> which i like a lot. Thoughts? >> >> >> I've added the following tipsy in the meantime (please ignore the haml): >> >> =_('All:') >> = _("Show all results regardless of which columns they exist in.") >> =_('Shared:') >> = _("Show only results that exist in all selected columns.") >> =_('Unique:') >> = _("Show only results not existing in all selected columns.") > [ Malini ]---> I suggest a slight modification to the tipsy text - Instead of the word 'columns', I think we should say 'environments' > I originally had environments, but there are instances where the columns are not environments (like repo comparison). We might could change the tipsy text depending on which view you're in, but that seemed like too much work for the payoff. Thoughts? I think customizing for specific cases is a good investment from a usability point of view. "Columns" is just too vague to be useful IMO. Also, I want to make sure you didn't miss this other suggestion I had in the previous email with regard to the suggestion on changing it to Union/ intersection - [ Malini ]---> If this is indeed common parlance, then I would suggest a change in the field label - Instead of "View : All/ Union/ Intersection", use "Content: All/ Union/Intersection" Otherwise I was going to suggest - "Content Display: All/ Shared by all / Missing in some" >> -Justin >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > I tend to agree with Corey. Union and Intersection (or difference?) are > "normal" or accepted means of understanding. > > > [ Malini ]---> If this is indeed common parlance, then I would suggest a change in the field label - > > Instead of "View : All/ Union/ Intersection", use "Content: All/ Union/Intersection" > > Otherwise I was going to suggest - > > "Content Display: All/ Shared by all / Missing in some" > _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Wed Aug 1 15:12:35 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 1 Aug 2012 17:12:35 +0200 Subject: [katello-devel] Fedora 17 Stuff So Far In-Reply-To: <5017D908.6050407@redhat.com> References: <5016AE18.1060504@redhat.com> <5017877A.4060703@redhat.com> <5017D908.6050407@redhat.com> Message-ID: <20120801151235.GC3856@lzapx.brq.redhat.com> FYI I made some changes to the installer to support Fedora 17. It _nearly_ finishes now, the only issue are those Ruby 1.9 incompatibilities in our Rails initializers. LZ On Tue, Jul 31, 2012 at 07:09:28AM -0600, Jason Rist wrote: > On 07/31/2012 01:21 AM, Miroslav Such? wrote: > >On 07/30/2012 05:54 PM, Jason Rist wrote: > >>https://fedorahosted.org/katello/wiki/f17_research > >> > >>-J > > > >See comments inline: > > > >>The above requires you to add the two separate repos as deps: > >> > >>http://repos.fedorapeople.org/repos/pulp/pulp/v1/stable/fedora-17/x86_64/ > >> > >>http://repos.fedorapeople.org/repos/candlepin/candlepin/fedora-16/x86_64/ > > > > > > > >Any reason why you are not using: > >http://fedorapeople.org/groups/katello/releases/yum/katello-candlepin/Fedora/17/ > > > >http://fedorapeople.org/groups/katello/releases/yum/katello-pulp/Fedora/17/ > >? > > As I mentioned in the demo, going to switch to that, but haven't > updated the wiki to reflect it. > > > > > > >>if RUBY_VERSION < "1.9" > >>when nil: total_mem *= (1<<0) > >>when 'kB': total_mem *= (1<<10) > >>when 'MB': total_mem *= (1<<20) > >>when 'GB': total_mem *= (1<<30) > >>when 'TB': total_mem *= (1<<40) > >>else > >>when nil then total_mem *= (1<<0) > >>when 'kB' then total_mem *= (1<<10) > >>when 'MB' then total_mem *= (1<<20) > >>when 'GB' then total_mem *= (1<<30) > >>when 'TB' then total_mem *= (1<<40) > >>end > > > > > >Why this when: > >when nil then total_mem *= (1<<0) > >works in ruby-1.8 as well? > > Yeah, this was fixed in PR 395 by inecas > > > >>err: /Stage[main]/Apache2/Exec[reload-apache2]: Failed to call > >>refresh: Could not find command '/etc/init.d/httpd' > > > >We have even in code: > >modules/certs/templates/rhsm-katello-reconfigure.erb: /etc/init.d/goferd > >restart >/dev/null 2&>1 > > > >You should never call /etc/init.d/foo directly. Always > >service foo start/stop/restart > >Command service ensure you have correct environment and set cwd to /. > >And works with both systemV and systemD. > > > > > Agreed! This has also been fixed by one of lzap's pushes. > > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > > _______________________________________________ > 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 Aug 1 15:16:36 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 1 Aug 2012 17:16:36 +0200 Subject: [katello-devel] headpin vs. katello In-Reply-To: <929922042.23021237.1343755464126.JavaMail.root@redhat.com> References: <350052817.23018016.1343755260657.JavaMail.root@redhat.com> <929922042.23021237.1343755464126.JavaMail.root@redhat.com> Message-ID: <20120801151636.GD3856@lzapx.brq.redhat.com> So is this tested and working? And does it mean CR1 is without headpin? LZ On Tue, Jul 31, 2012 at 01:24:24PM -0400, Tom McKay wrote: > > Tazim (and others interested in headpin only installs), > > While we figure out how best to provide a community headpin install in relation to katello, I will suggest that if you want to "check out" the latest greatest features in headpin, that you install katello and then katello-configure it to headpin. This will not be a fully functional headpin install (eg. the 'katello' executable is used for command line), but it will show you the latest code. > > Over the next couple weeks we (myself, Jordan, and Adam) will be working on making headpin fully available in nightly, weekly, and release builds. > > Thanks! > Tom > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From hbrock at redhat.com Wed Aug 1 15:17:32 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 1 Aug 2012 11:17:32 -0400 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <20120801145748.GA3856@lzapx.brq.redhat.com> References: <50124DDD.9040009@redhat.com> <20120730100257.GE5373@lzapx.brq.redhat.com> <20120801123322.GF15724@redhat.com> <20120801145748.GA3856@lzapx.brq.redhat.com> Message-ID: <20120801151732.GT15724@redhat.com> On Wed, Aug 01, 2012 at 04:57:48PM +0200, Lukas Zapletal wrote: > Ok so it's doable. What is your approach in Cloud Engine by the way? > We're in the same boat you guys are. As in, "Hey, one of these days we really ought to go add a whole bunch of foreign keys and indexes to the database..." --H > > On Wed, Aug 01, 2012 at 08:33:22AM -0400, Hugh Brock wrote: > > On Mon, Jul 30, 2012 at 12:02:57PM +0200, Lukas Zapletal wrote: > > > By the way, what are the biggest concerns in regard to using foreign > > > keys and rails? What is the issue? > > > > > Heh... the issue is that Active Record is quite happy to define > > relationships that would traditionally have required proper > > referential constraints in a database, without defining any > > constraints. So there is absolutely nothing stopping me (or a bug in > > Active Record) from deleting rows in the DB that are referenced by > > other rows, which can break your whole app horribly. > > > > The solution is simply to add proper constraints in your > > migrations. However most folks in the modern web-scale world seem > > happy to live with this level of risk and don't bother with the > > constraints, despite the fact that it makes us dinosaurs > > uncomfortable... > > > > --Hugh > > > > > > > > > > On Fri, Jul 27, 2012 at 10:14:21AM +0200, Miroslav Suchy wrote: > > > > While working on APIDocumentationEfforts [1] I wanted some nice > > > > documentation of our schema. I find we have none, so I created one: > > > > http://miroslav.suchy.cz/katello/katelloschema.html > > > > It is created by PostgreSQL Autodoc [2]. > > > > > > > > To my surprise it does not contain foreign keys and very few indexes. > > > > First I thought it is bug in Autodoc. But then - to my horor - I > > > > find it is not bug. We do not have foreign keys and indexes on most > > > > tables! > > > > > > > > So we have two issues. > > > > > > > > 1) Indexes: > > > > E.g. table user_notices, which purpose is IMHO always to live > > > > between two JOINS and is school example where indexes should be > > > > used, do not have indexes. > > > > I can go through schema and suggest where we should create indexes. > > > > I do not expect that it would cause any problem. > > > > Objections here? > > > > > > > > 2) Foreign keys: > > > > I read about foreign keys and ruby and I learned that community > > > > around Rails think that application level is best/enough to keep > > > > data consistency. So I expect a lot of discussion here. > > > > Let me share my point of view here: > > > > IMO data consistency should be work of database engine. > > > > There are two examples: > > > > a) when our code is fatally interrupted. E.g. > > > > > > > > src/app/models/glue/pulp/repo.rb: > > > > def destroy_repo_orchestration > > > > pre_queue.create(:name => "remove product content : > > > > #{self.name}", :priority => 1, :action => [self, :del_content]) > > > > [.. FATAL CRASH HERE ...] > > > > pre_queue.create(:name => "delete pulp repo : #{self.name}", > > > > :priority => 2, :action => [self, :destroy_repo]) > > > > end > > > > > > > > You will end up with repository with product id, which does not exist. > > > > Foreign keys with ON DELETE CASCADE solve this. > > > > > > > > b) But even if we solve all issues in our code (e.g start using > > > > transactions), there is problems with humans. > > > > During my 5 years in RHN Satellite team I seen non trivial numbers > > > > of Customers issues, where either customer or even TAM(!) run > > > > directly SQL commands, which without foreign keys would result in > > > > inconsistent database. > > > > Using foreign keys seems doable: > > > > https://github.com/matthuhiggins/foreigner > > > > https://github.com/jenseng/immigrant > > > > So it should be basically two gems, few lines of code and some testing. > > > > > > > > Your opinions? > > > > > > > > > > > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > > > > [2] http://www.rbt.ca/autodoc/ (available in Fedora as package) > > > > > > > > Mirek > > > > > > > > _______________________________________________ > > > > katello-devel mailing list > > > > katello-devel at redhat.com > > > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > -- > > > Later, > > > > > > Lukas "lzap" Zapletal > > > #katello #systemengine > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > 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 msuchy at redhat.com Wed Aug 1 15:21:25 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 01 Aug 2012 17:21:25 +0200 Subject: [katello-devel] headpin vs. katello In-Reply-To: <20120801151636.GD3856@lzapx.brq.redhat.com> References: <350052817.23018016.1343755260657.JavaMail.root@redhat.com> <929922042.23021237.1343755464126.JavaMail.root@redhat.com> <20120801151636.GD3856@lzapx.brq.redhat.com> Message-ID: <50194975.1000703@redhat.com> On 08/01/2012 05:16 PM, Lukas Zapletal wrote: > So is this tested and working? > > And does it mean CR1 is without headpin? I'm working on the merge: https://github.com/Katello/katello/pull/412 Discussing it with jomara on IRC right now. -- Miroslav Suchy Red Hat Systems Management Engineering From jomara at redhat.com Wed Aug 1 15:22:52 2012 From: jomara at redhat.com (Jordan OMara) Date: Wed, 1 Aug 2012 11:22:52 -0400 Subject: [katello-devel] headpin vs. katello In-Reply-To: <20120801151636.GD3856@lzapx.brq.redhat.com> References: <350052817.23018016.1343755260657.JavaMail.root@redhat.com> <929922042.23021237.1343755464126.JavaMail.root@redhat.com> <20120801151636.GD3856@lzapx.brq.redhat.com> Message-ID: <20120801152252.GL41604@redhat.com> On 01/08/12 17:16 +0200, Lukas Zapletal wrote: >So is this tested and working? > >And does it mean CR1 is without headpin? > >LZ see mirek's latest pr: https://github.com/Katello/katello/pull/412 I think we can still have people download katello-headpin and the release cycle will be identical with katello. then we dont have to worry about any weird thumbslug post-install issues with running katello in headpin mode -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From bkearney at redhat.com Wed Aug 1 16:44:48 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 01 Aug 2012 12:44:48 -0400 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <20120801151732.GT15724@redhat.com> References: <50124DDD.9040009@redhat.com> <20120730100257.GE5373@lzapx.brq.redhat.com> <20120801123322.GF15724@redhat.com> <20120801145748.GA3856@lzapx.brq.redhat.com> <20120801151732.GT15724@redhat.com> Message-ID: <50195D00.1010200@redhat.com> On 08/01/2012 11:17 AM, Hugh Brock wrote: > On Wed, Aug 01, 2012 at 04:57:48PM +0200, Lukas Zapletal wrote: >> Ok so it's doable. What is your approach in Cloud Engine by the way? >> > We're in the same boat you guys are. As in, "Hey, one of these days we > really ought to go add a whole bunch of foreign keys and indexes to > the database..." > That is this sprint for us. Candlepin performance shows us that postgres falls over QUICKLY with no indexes. -- bk From hbrock at redhat.com Wed Aug 1 16:55:40 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 1 Aug 2012 12:55:40 -0400 Subject: [katello-devel] Katello schema - documentation and questions In-Reply-To: <50195D00.1010200@redhat.com> References: <50124DDD.9040009@redhat.com> <20120730100257.GE5373@lzapx.brq.redhat.com> <20120801123322.GF15724@redhat.com> <20120801145748.GA3856@lzapx.brq.redhat.com> <20120801151732.GT15724@redhat.com> <50195D00.1010200@redhat.com> Message-ID: <20120801165539.GW15724@redhat.com> On Wed, Aug 01, 2012 at 12:44:48PM -0400, Bryan Kearney wrote: > On 08/01/2012 11:17 AM, Hugh Brock wrote: > >On Wed, Aug 01, 2012 at 04:57:48PM +0200, Lukas Zapletal wrote: > >>Ok so it's doable. What is your approach in Cloud Engine by the way? > >> > >We're in the same boat you guys are. As in, "Hey, one of these days we > >really ought to go add a whole bunch of foreign keys and indexes to > >the database..." > > > That is this sprint for us. Candlepin performance shows us that > postgres falls over QUICKLY with no indexes. > Unsurprising. I'll check on the state of things for Aeolus... --Hugh -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From lzap at redhat.com Wed Aug 1 17:10:20 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 1 Aug 2012 19:10:20 +0200 Subject: [katello-devel] headpin vs. katello In-Reply-To: <50194975.1000703@redhat.com> References: <350052817.23018016.1343755260657.JavaMail.root@redhat.com> <929922042.23021237.1343755464126.JavaMail.root@redhat.com> <20120801151636.GD3856@lzapx.brq.redhat.com> <50194975.1000703@redhat.com> Message-ID: <20120801171020.GO3856@lzapx.brq.redhat.com> Wow, does it mean we are getting rid of the extra branch now? That easy? Good work guys (I know some background - lot of work to get Headpin into this state). LZ On Wed, Aug 01, 2012 at 05:21:25PM +0200, Miroslav Suchy wrote: > On 08/01/2012 05:16 PM, Lukas Zapletal wrote: > >So is this tested and working? > > > >And does it mean CR1 is without headpin? > > I'm working on the merge: > https://github.com/Katello/katello/pull/412 > > Discussing it with jomara on IRC right now. > > -- > Miroslav Suchy > Red Hat Systems Management 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 mmccune at redhat.com Wed Aug 1 20:51:55 2012 From: mmccune at redhat.com (Mike McCune) Date: Wed, 01 Aug 2012 13:51:55 -0700 Subject: [katello-devel] Katello 1.0 checklist and install notes Message-ID: <501996EB.5000507@redhat.com> Threw up this etherpad to track things we want todo for the 1.0 release and current issues with the install: http://pad-katello.rhcloud.com/p/v1-todo Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From jsherril at redhat.com Wed Aug 1 21:20:53 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 01 Aug 2012 17:20:53 -0400 Subject: [katello-devel] default user page size Message-ID: <50199DB5.7090504@redhat.com> Currently our user page size is set at 25, and I believe this might be a little too low. We had talked about increasing it, but I wanted to get some discussion. Thoughts on increasing the default to 50? -Justin From jrist at redhat.com Wed Aug 1 21:24:04 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 01 Aug 2012 15:24:04 -0600 Subject: [katello-devel] default user page size In-Reply-To: <50199DB5.7090504@redhat.com> References: <50199DB5.7090504@redhat.com> Message-ID: <50199E74.1040902@redhat.com> On Wed 01 Aug 2012 03:20:53 PM MDT, Justin Sherrill wrote: > Currently our user page size is set at 25, and I believe this might be > a little too low. We had talked about increasing it, but I wanted to > get some discussion. Thoughts on increasing the default to 50? > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel +1. Might also be worth loading more a few seconds after the page is loaded? -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jsherril at redhat.com Wed Aug 1 21:25:47 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 01 Aug 2012 17:25:47 -0400 Subject: [katello-devel] default user page size In-Reply-To: <50199E74.1040902@redhat.com> References: <50199DB5.7090504@redhat.com> <50199E74.1040902@redhat.com> Message-ID: <50199EDB.8020003@redhat.com> On 08/01/2012 05:24 PM, Jason Rist wrote: > On Wed 01 Aug 2012 03:20:53 PM MDT, Justin Sherrill wrote: >> Currently our user page size is set at 25, and I believe this might >> be a little too low. We had talked about increasing it, but I wanted >> to get some discussion. Thoughts on increasing the default to 50? >> >> -Justin >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > +1. Might also be worth loading more a few seconds after the page is > loaded? > That would be a good idea for tupane, but i don't know that it is feasible for content search. -Justin From jrist at redhat.com Wed Aug 1 21:27:02 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 01 Aug 2012 15:27:02 -0600 Subject: [katello-devel] default user page size In-Reply-To: <50199EDB.8020003@redhat.com> References: <50199DB5.7090504@redhat.com> <50199E74.1040902@redhat.com> <50199EDB.8020003@redhat.com> Message-ID: <50199F26.4020602@redhat.com> On Wed 01 Aug 2012 03:25:47 PM MDT, Justin Sherrill wrote: > On 08/01/2012 05:24 PM, Jason Rist wrote: >> On Wed 01 Aug 2012 03:20:53 PM MDT, Justin Sherrill wrote: >>> Currently our user page size is set at 25, and I believe this might >>> be a little too low. We had talked about increasing it, but I wanted >>> to get some discussion. Thoughts on increasing the default to 50? >>> >>> -Justin >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> >> +1. Might also be worth loading more a few seconds after the page is >> loaded? >> > That would be a good idea for tupane, but i don't know that it is > feasible for content search. > > -Justin Ah, didn't know it applied to content search as well. Good point. Maybe a post-(page-load)-pre-load setting for pages like content search? -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From thomasmckay at redhat.com Wed Aug 1 21:47:09 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 1 Aug 2012 17:47:09 -0400 (EDT) Subject: [katello-devel] default user page size In-Reply-To: <50199DB5.7090504@redhat.com> Message-ID: <1649458319.26539363.1343857629251.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Justin Sherrill" > To: katello-devel at redhat.com > Sent: Wednesday, August 1, 2012 5:20:53 PM > Subject: [katello-devel] default user page size > > Currently our user page size is set at 25, and I believe this might > be a > little too low. We had talked about increasing it, but I wanted to > get > some discussion. Thoughts on increasing the default to 50? > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > I'm not against it, but I'd like to see the current settings validated a bit more on large "real" data sets before I'm enthusiastic. Are there any two-pane views where the left list triggers a backend-call-per-entry currently? From jsherril at redhat.com Wed Aug 1 22:10:26 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 01 Aug 2012 18:10:26 -0400 Subject: [katello-devel] default user page size In-Reply-To: <1649458319.26539363.1343857629251.JavaMail.root@redhat.com> References: <1649458319.26539363.1343857629251.JavaMail.root@redhat.com> Message-ID: <5019A952.8020704@redhat.com> On 08/01/2012 05:47 PM, Tom McKay wrote: > > ----- Original Message ----- >> From: "Justin Sherrill" >> To: katello-devel at redhat.com >> Sent: Wednesday, August 1, 2012 5:20:53 PM >> Subject: [katello-devel] default user page size >> >> Currently our user page size is set at 25, and I believe this might >> be a >> little too low. We had talked about increasing it, but I wanted to >> get >> some discussion. Thoughts on increasing the default to 50? >> >> -Justin >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > I'm not against it, but I'd like to see the current settings validated a bit more on large "real" data sets before I'm enthusiastic. Are there any two-pane views where the left list triggers a backend-call-per-entry currently? The only one I know of is the Systems page, although your subscriptions tupane page might, you'd know the answer to that. I think 25 is too few for most places such as content search and promotions. We could ignore the page size for those places (since they are very different than tupane) and just use a larger fixed number if we wanted too. -Justin From bbuckingham at redhat.com Wed Aug 1 22:34:02 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Wed, 01 Aug 2012 18:34:02 -0400 Subject: [katello-devel] default user page size In-Reply-To: <5019A952.8020704@redhat.com> References: <1649458319.26539363.1343857629251.JavaMail.root@redhat.com> <5019A952.8020704@redhat.com> Message-ID: <5019AEDA.6070409@redhat.com> On 08/01/2012 06:10 PM, Justin Sherrill wrote: > On 08/01/2012 05:47 PM, Tom McKay wrote: >> >> ----- Original Message ----- >>> From: "Justin Sherrill" >>> To: katello-devel at redhat.com >>> Sent: Wednesday, August 1, 2012 5:20:53 PM >>> Subject: [katello-devel] default user page size >>> >>> Currently our user page size is set at 25, and I believe this might >>> be a >>> little too low. We had talked about increasing it, but I wanted to >>> get >>> some discussion. Thoughts on increasing the default to 50? >>> >>> -Justin >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> I'm not against it, but I'd like to see the current settings >> validated a bit more on large "real" data sets before I'm >> enthusiastic. Are there any two-pane views where the left list >> triggers a backend-call-per-entry currently? > > The only one I know of is the Systems page, although your > subscriptions tupane page might, you'd know the answer to that. > > I think 25 is too few for most places such as content search and > promotions. We could ignore the page size for those places (since > they are very different than tupane) and just use a larger fixed > number if we wanted too. > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel While we are at it, should we make it configurable (but provide an upper and lower bound)? Right now we have a page-size, but is hard-coded for every user and no way to change it in UI/API/CLI From jrist at redhat.com Wed Aug 1 22:35:35 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 01 Aug 2012 16:35:35 -0600 Subject: [katello-devel] default user page size In-Reply-To: <5019AEDA.6070409@redhat.com> References: <1649458319.26539363.1343857629251.JavaMail.root@redhat.com> <5019A952.8020704@redhat.com> <5019AEDA.6070409@redhat.com> Message-ID: <5019AF37.8040501@redhat.com> On Wed 01 Aug 2012 04:34:02 PM MDT, Brad Buckingham wrote: > On 08/01/2012 06:10 PM, Justin Sherrill wrote: >> On 08/01/2012 05:47 PM, Tom McKay wrote: >>> >>> ----- Original Message ----- >>>> From: "Justin Sherrill" >>>> To: katello-devel at redhat.com >>>> Sent: Wednesday, August 1, 2012 5:20:53 PM >>>> Subject: [katello-devel] default user page size >>>> >>>> Currently our user page size is set at 25, and I believe this might >>>> be a >>>> little too low. We had talked about increasing it, but I wanted to >>>> get >>>> some discussion. Thoughts on increasing the default to 50? >>>> >>>> -Justin >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> >>> I'm not against it, but I'd like to see the current settings >>> validated a bit more on large "real" data sets before I'm >>> enthusiastic. Are there any two-pane views where the left list >>> triggers a backend-call-per-entry currently? >> >> The only one I know of is the Systems page, although your >> subscriptions tupane page might, you'd know the answer to that. >> >> I think 25 is too few for most places such as content search and >> promotions. We could ignore the page size for those places (since >> they are very different than tupane) and just use a larger fixed >> number if we wanted too. >> >> -Justin >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > While we are at it, should we make it configurable (but provide an > upper and lower bound)? > Right now we have a page-size, but is hard-coded for every user and no > way to change it in UI/API/CLI > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel +1 to configurable - I think that was always the plan. I'm thinking we have a page size and an opt-out option. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From omaciel at redhat.com Thu Aug 2 02:24:38 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 1 Aug 2012 22:24:38 -0400 (EDT) Subject: [katello-devel] default user page size In-Reply-To: <50199DB5.7090504@redhat.com> Message-ID: <1626712874.6590955.1343874278179.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Justin Sherrill" > > Currently our user page size is set at 25, and I believe this might > be a > little too low. We had talked about increasing it, but I wanted to > get > some discussion. Thoughts on increasing the default to 50? Right now, if you have both errata and system groups for an organization, the Dashboard takes a sweet time to completely load completely. How would increasing the page size, if at all, affect this situation? -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From omaciel at redhat.com Thu Aug 2 03:04:56 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 1 Aug 2012 23:04:56 -0400 (EDT) Subject: [katello-devel] Setting a user's preferred locale via cli Message-ID: <1275200984.6617543.1343876696232.JavaMail.root@redhat.com> Is there a way to set a user's preferred locale via cli? If not, how hard would it be to implement something like: katello user create --username=french_guy --password=frenchpwd --email=french_guy at frenchcompany.com --default_environment=QA --locale=fr Cheers, -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From jrist at redhat.com Thu Aug 2 04:04:20 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 01 Aug 2012 22:04:20 -0600 Subject: [katello-devel] default user page size In-Reply-To: <1626712874.6590955.1343874278179.JavaMail.root@redhat.com> References: <50199DB5.7090504@redhat.com> <1626712874.6590955.1343874278179.JavaMail.root@redhat.com> Message-ID: <5019FC44.9020101@redhat.com> On Wed 01 Aug 2012 08:24:38 PM MDT, Og Maciel wrote: > ----- Original Message ----- >> From: "Justin Sherrill" >> >> Currently our user page size is set at 25, and I believe this might >> be a >> little too low. We had talked about increasing it, but I wanted to >> get >> some discussion. Thoughts on increasing the default to 50? > > Right now, if you have both errata and system groups for an organization, the Dashboard takes a sweet time to completely load completely. How would increasing the page size, if at all, affect this situation? None. That is based on the preference set in the little gear widget per dash item. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From omaciel at redhat.com Thu Aug 2 04:11:50 2012 From: omaciel at redhat.com (Og Maciel) Date: Thu, 2 Aug 2012 00:11:50 -0400 (EDT) Subject: [katello-devel] default user page size In-Reply-To: <5019FC44.9020101@redhat.com> Message-ID: <1044894552.6628258.1343880710790.JavaMail.root@redhat.com> > None. That is based on the preference set in the little gear widget > per > dash item. For every system group that gets displayed in the new System Group Overview portlet in the Dashboard, several calls need to be made to pull information as to how many system are in a group and what their status are... this plus doing the same type of thing for errata takes a sweet time. Increasing the number of items getting returned won't slow things down? -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From jrist at redhat.com Thu Aug 2 04:13:00 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 01 Aug 2012 22:13:00 -0600 Subject: [katello-devel] default user page size In-Reply-To: <1044894552.6628258.1343880710790.JavaMail.root@redhat.com> References: <5019FC44.9020101@redhat.com> <1044894552.6628258.1343880710790.JavaMail.root@redhat.com> Message-ID: <5019FE4C.8020207@redhat.com> On Wed 01 Aug 2012 10:11:50 PM MDT, Og Maciel wrote: >> None. That is based on the preference set in the little gear widget >> per >> dash item. > > For every system group that gets displayed in the new System Group Overview portlet in the Dashboard, several calls need to be made to pull information as to how many system are in a group and what their status are... this plus doing the same type of thing for errata takes a sweet time. Increasing the number of items getting returned won't slow things down? Nothing in the dashboard is set using page size. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From omaciel at redhat.com Thu Aug 2 04:18:10 2012 From: omaciel at redhat.com (Og Maciel) Date: Thu, 2 Aug 2012 00:18:10 -0400 (EDT) Subject: [katello-devel] default user page size In-Reply-To: <5019FE4C.8020207@redhat.com> Message-ID: <1777416717.6628826.1343881090878.JavaMail.root@redhat.com> > Nothing in the dashboard is set using page size. Cool, in that case, crank it up :) -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From mmccune at redhat.com Thu Aug 2 06:19:47 2012 From: mmccune at redhat.com (Mike McCune) Date: Wed, 01 Aug 2012 23:19:47 -0700 Subject: [katello-devel] Setting a user's preferred locale via cli In-Reply-To: <1275200984.6617543.1343876696232.JavaMail.root@redhat.com> References: <1275200984.6617543.1343876696232.JavaMail.root@redhat.com> Message-ID: <501A1C03.8040005@redhat.com> On 08/01/2012 08:04 PM, Og Maciel wrote: > Is there a way to set a user's preferred locale via cli? If not, how hard would it be to implement something like: > > katello user create --username=french_guy --password=frenchpwd --email=french_guy at frenchcompany.com --default_environment=QA --locale=fr > > Cheers, no way todo it now but it wouldn't be that hard to add. Just file an RFE and we can triage it appropriately. patches happily accepted :) Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From lzap at redhat.com Thu Aug 2 08:16:33 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 2 Aug 2012 10:16:33 +0200 Subject: [katello-devel] default user page size In-Reply-To: <50199E74.1040902@redhat.com> References: <50199DB5.7090504@redhat.com> <50199E74.1040902@redhat.com> Message-ID: <20120802081633.GA2524@lzapx.brq.redhat.com> On Wed, Aug 01, 2012 at 03:24:04PM -0600, Jason Rist wrote: > +1. Might also be worth loading more a few seconds after the page > is loaded? > I am fine with 50, but please DO NOT optimize at this point. As Donald Knuth said "premature optimization is the root of all evil". ;-) LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Thu Aug 2 08:30:23 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 2 Aug 2012 10:30:23 +0200 Subject: [katello-devel] Setting a user's preferred locale via cli In-Reply-To: <501A1C03.8040005@redhat.com> References: <1275200984.6617543.1343876696232.JavaMail.root@redhat.com> <501A1C03.8040005@redhat.com> Message-ID: <20120802083023.GB2524@lzapx.brq.redhat.com> On Wed, Aug 01, 2012 at 11:19:47PM -0700, Michael McCune wrote: > no way todo it now but it wouldn't be that hard to add. Just file > an RFE and we can triage it appropriately. patches happily accepted > :) > Well, why to introduce new option when you can do this in UNIX: LC_ALL=fr katello environment list What CLI does it sends this locale to the server so the Katello server returns all data in French (well not data but all constants there). It should also switch over to French in this case (for all messages and column names for example - CLI is localized of course). You have discovered a bug, Og. While it should work, what we do in our source code base is we always get system's default locale (in my case English). So we do not take user's setting into effect. So I filed new bug: https://bugzilla.redhat.com/show_bug.cgi?id=845198 We will not introduce new option you recommend (if you filed a RFE please close it), but we will rather fix this one. Then it should work the usual way (e.g. if I as Czech ssh into a box with English system locale, ssh in the default configuration will switch my environment to Czech, so Katello CLI will work in Czech for me). Nice find, especially when your default one is English (I guess :-) LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Thu Aug 2 09:37:32 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 02 Aug 2012 10:37:32 +0100 Subject: [katello-devel] A couple of community-related questions Message-ID: <501A4A5C.6040208@redhat.com> Hey guys, Should we use travis-ci? I think so, for a couple of reasons: - it'd be helpful for community to know the current status of codebase - it would force us to maintain a subset of fast developer-tests (as in TDD) Aeolus project has an extension for Bundler that allows for simple switching between bundler- and rpm-based application deployments. It relies on an environment variable to switch between the two behaviours. In rpm-mode the extension takes over dependency loading: it relaxes version restrictions for gems, and then loads the dependencies. See https://github.com/aeolus-incubator/bundler_ext for details and https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb for example of real-world use. I think it makes sense to adopt that extension in katello. Thoughts/opinions? -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuchy at redhat.com Thu Aug 2 10:27:26 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Thu, 02 Aug 2012 12:27:26 +0200 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <501A4A5C.6040208@redhat.com> References: <501A4A5C.6040208@redhat.com> Message-ID: <501A560E.2020906@redhat.com> On 08/02/2012 11:37 AM, Dmitri Dolguikh wrote: > Should we use travis-ci? I think so, for a couple of reasons: /me reading through http://about.travis-ci.org ... > - it'd be helpful for community to know the current status of codebase > - it would force us to maintain a subset of fast developer-tests (as > in TDD) I'm against it. Or more precisely I'm not going to cooperate on this. This will install project directly from GitHub. But we are not delivering this. We deliver rpm and installation using rpm using: https://fedorahosted.org/katello/wiki/Install Installation from github is completely different scenario and I think we should not support it. I feel it is better to have one better installation scenario, rather then two worse (maintained) scenarios. -- Miroslav Suchy Red Hat Systems Management Engineering From dmitri at redhat.com Thu Aug 2 10:39:06 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 02 Aug 2012 11:39:06 +0100 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <501A560E.2020906@redhat.com> References: <501A4A5C.6040208@redhat.com> <501A560E.2020906@redhat.com> Message-ID: <501A58CA.1000406@redhat.com> On 02/08/12 11:27 AM, Miroslav Such? wrote: > On 08/02/2012 11:37 AM, Dmitri Dolguikh wrote: >> Should we use travis-ci? I think so, for a couple of reasons: > > /me reading through http://about.travis-ci.org ... > >> - it'd be helpful for community to know the current status of codebase >> - it would force us to maintain a subset of fast developer-tests (as >> in TDD) > > I'm against it. Or more precisely I'm not going to cooperate on this. > > This will install project directly from GitHub. But we are not > delivering this. We deliver rpm and installation using rpm using: > https://fedorahosted.org/katello/wiki/Install > Installation from github is completely different scenario and I think > we should not support it. > I feel it is better to have one better installation scenario, rather > then two worse (maintained) scenarios. > > Katello community is not homogeneous - it consists of sys-/network-admins, developers, and people wearing both hats. I think for the latter two types of people it would be useful to have an insight into current state of the project. -d From lzap at redhat.com Thu Aug 2 11:36:13 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 2 Aug 2012 13:36:13 +0200 Subject: [katello-devel] Starting "What is new" page Message-ID: <20120802113613.GD2524@lzapx.brq.redhat.com> Hey, created this page: http://pad-katello.rhcloud.com/p/katello-whats-new-next Put your changes what is new for the next community release. We will move this test to the documentation later on and start over on the same location. When you finish a feature or important bug, please put it here. Our community documents should be good starting point for CFSE release documentation as well. -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Thu Aug 2 11:38:48 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Thu, 02 Aug 2012 13:38:48 +0200 Subject: [katello-devel] Starting "What is new" page In-Reply-To: <20120802113613.GD2524@lzapx.brq.redhat.com> References: <20120802113613.GD2524@lzapx.brq.redhat.com> Message-ID: <501A66C8.6090301@redhat.com> On 08/02/2012 01:36 PM, Lukas Zapletal wrote: > Hey, > > created this page: > > http://pad-katello.rhcloud.com/p/katello-whats-new-next > > Put your changes what is new for the next community release. We will > move this test to the documentation later on and start over on the same > location. > > When you finish a feature or important bug, please put it here. Our > community documents should be good starting point for CFSE release > documentation as well. > May I suggest to use: https://fedorahosted.org/katello/roadmap -- Miroslav Suchy Red Hat Systems Management Engineering From lzap at redhat.com Thu Aug 2 11:57:43 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 2 Aug 2012 13:57:43 +0200 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <501A4A5C.6040208@redhat.com> References: <501A4A5C.6040208@redhat.com> Message-ID: <20120802115743.GE2524@lzapx.brq.redhat.com> On Thu, Aug 02, 2012 at 10:37:32AM +0100, Dmitri Dolguikh wrote: > Aeolus project has an extension for Bundler that allows for simple > switching between bundler- and rpm-based application deployments. It > relies on an environment variable to switch between the two > behaviours. In rpm-mode the extension takes over dependency loading: > it relaxes version restrictions for gems, and then loads the > dependencies. See https://github.com/aeolus-incubator/bundler_ext > for details and https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb > for example of real-world use. > There has been several approaches discussed this year on the fedora ruby sig mailing list. Katello took the simplest approach - to delete Gemfile.lock every start, bundler just creates new from existing (local) system gems. Foreman uses approach to run bundler install --local in the post RPM transaction. It's quick and nice, but it does not work when you update dependencies (then it actually breaks). Aeolus uses this, which I like the most at first sight. It basically turns off bundler Ruby Fedora packagers (Vit Ondruch) are currently communicating with bundler upstream to add some (non-default) option to force usage of system gems. But upsteam seems to resist. I guess that aeolus-incubator piece is result of this discussion. I'd rather wait how Fedora packagers will solve this issues. They are under heavy pressure from various Red Hat and Fedora Ruby teams. All have the same issue with Bundler. It really seems the Aeolus approach is the best IMHO. So how about to re-raise this again in two months? Btw Bundler is Linux-unfriendly in terms of serious deployment. It's a weird approach Rails community fallen in love with IMHO. Very "cool" for initial development, but that's all. -- Later, Lukas "lzap" Zapletal #katello #systemengine From thomasmckay at redhat.com Thu Aug 2 12:06:10 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 2 Aug 2012 08:06:10 -0400 (EDT) Subject: [katello-devel] Setting a user's preferred locale via cli In-Reply-To: <20120802083023.GB2524@lzapx.brq.redhat.com> Message-ID: <801000414.27887560.1343909170496.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Thursday, August 2, 2012 4:30:23 AM > Subject: Re: [katello-devel] Setting a user's preferred locale via cli > > On Wed, Aug 01, 2012 at 11:19:47PM -0700, Michael McCune wrote: > > no way todo it now but it wouldn't be that hard to add. Just file > > an RFE and we can triage it appropriately. patches happily > > accepted > > :) > > > > Well, why to introduce new option when you can do this in UNIX: > > LC_ALL=fr katello environment list > > What CLI does it sends this locale to the server so the Katello > server > returns all data in French (well not data but all constants there). > It should also switch over to French in this case (for all messages > and > column names for example - CLI is localized of course). > > You have discovered a bug, Og. While it should work, what we do in > our > source code base is we always get system's default locale (in my case > English). So we do not take user's setting into effect. > > So I filed new bug: > https://bugzilla.redhat.com/show_bug.cgi?id=845198 > > We will not introduce new option you recommend (if you filed a RFE > please close it), but we will rather fix this one. Then it should > work > the usual way (e.g. if I as Czech ssh into a box with English system > locale, ssh in the default configuration will switch my environment > to > Czech, so Katello CLI will work in Czech for me). > > Nice find, especially when your default one is English (I guess :-) > > LZ > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > Disagree that this is not worth a RFE. Just like in the UI, where the user may override the default browser locale, a --locale option would allow the user to override the systems default locale. I am voting for the RFE. From thomasmckay at redhat.com Thu Aug 2 12:07:24 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 2 Aug 2012 08:07:24 -0400 (EDT) Subject: [katello-devel] Setting a user's preferred locale via cli In-Reply-To: <801000414.27887560.1343909170496.JavaMail.root@redhat.com> Message-ID: <1875976161.27888267.1343909244090.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tom McKay" > To: "Lukas Zapletal" > Cc: katello-devel at redhat.com > Sent: Thursday, August 2, 2012 8:06:10 AM > Subject: Re: [katello-devel] Setting a user's preferred locale via cli > > > > ----- Original Message ----- > > From: "Lukas Zapletal" > > To: katello-devel at redhat.com > > Sent: Thursday, August 2, 2012 4:30:23 AM > > Subject: Re: [katello-devel] Setting a user's preferred locale via > > cli > > > > On Wed, Aug 01, 2012 at 11:19:47PM -0700, Michael McCune wrote: > > > no way todo it now but it wouldn't be that hard to add. Just > > > file > > > an RFE and we can triage it appropriately. patches happily > > > accepted > > > :) > > > > > > > Well, why to introduce new option when you can do this in UNIX: > > > > LC_ALL=fr katello environment list > > > > What CLI does it sends this locale to the server so the Katello > > server > > returns all data in French (well not data but all constants there). > > It should also switch over to French in this case (for all messages > > and > > column names for example - CLI is localized of course). > > > > You have discovered a bug, Og. While it should work, what we do in > > our > > source code base is we always get system's default locale (in my > > case > > English). So we do not take user's setting into effect. > > > > So I filed new bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=845198 > > > > We will not introduce new option you recommend (if you filed a RFE > > please close it), but we will rather fix this one. Then it should > > work > > the usual way (e.g. if I as Czech ssh into a box with English > > system > > locale, ssh in the default configuration will switch my environment > > to > > Czech, so Katello CLI will work in Czech for me). > > > > Nice find, especially when your default one is English (I guess :-) > > > > LZ > > > > -- > > Later, > > > > Lukas "lzap" Zapletal > > #katello #systemengine > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > Disagree that this is not worth a RFE. Just like in the UI, where the > user may override the default browser locale, a --locale option > would allow the user to override the systems default locale. I am > voting for the RFE. Let's also not forget that this --locale setting will change the user's preference. Thus an admin setting up a users via a script could set that value. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Thu Aug 2 12:12:45 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 2 Aug 2012 14:12:45 +0200 Subject: [katello-devel] Starting "What is new" page In-Reply-To: <501A66C8.6090301@redhat.com> References: <20120802113613.GD2524@lzapx.brq.redhat.com> <501A66C8.6090301@redhat.com> Message-ID: <20120802121245.GG2524@lzapx.brq.redhat.com> On Thu, Aug 02, 2012 at 01:38:48PM +0200, Miroslav Suchy wrote: > May I suggest to use: > https://fedorahosted.org/katello/roadmap I have no problem with that, but we do not use Trac tickets, so the planning is slightly degraded there. But it has iCalc output, that is nice. Updated link. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Thu Aug 2 12:14:42 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 2 Aug 2012 14:14:42 +0200 Subject: [katello-devel] Starting "What is new" page In-Reply-To: <501A66C8.6090301@redhat.com> References: <20120802113613.GD2524@lzapx.brq.redhat.com> <501A66C8.6090301@redhat.com> Message-ID: <20120802121442.GH2524@lzapx.brq.redhat.com> On Thu, Aug 02, 2012 at 01:38:48PM +0200, Miroslav Suchy wrote: > May I suggest to use: > https://fedorahosted.org/katello/roadmap Hey, I can't edit that. Would you mind adding: New option --noheading which disables table headers. and giving me permissions or tutorial how to get them? Thanks -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Thu Aug 2 12:16:33 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 02 Aug 2012 13:16:33 +0100 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <20120802115743.GE2524@lzapx.brq.redhat.com> References: <501A4A5C.6040208@redhat.com> <20120802115743.GE2524@lzapx.brq.redhat.com> Message-ID: <501A6FA1.6090206@redhat.com> On 02/08/12 12:57 PM, Lukas Zapletal wrote: > On Thu, Aug 02, 2012 at 10:37:32AM +0100, Dmitri Dolguikh wrote: >> Aeolus project has an extension for Bundler that allows for simple >> switching between bundler- and rpm-based application deployments. It >> relies on an environment variable to switch between the two >> behaviours. In rpm-mode the extension takes over dependency loading: >> it relaxes version restrictions for gems, and then loads the >> dependencies. See https://github.com/aeolus-incubator/bundler_ext >> for details and https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb >> for example of real-world use. >> > There has been several approaches discussed this year on the fedora ruby > sig mailing list. > > Katello took the simplest approach - to delete Gemfile.lock every start, > bundler just creates new from existing (local) system gems. That's not a great approach. You just removed specific versions of gems for deployment. Not everybody deploys using rpms (I, for one, don't). > > Foreman uses approach to run bundler install --local in the post RPM > transaction. It's quick and nice, but it does not work when you update > dependencies (then it actually breaks). > > Aeolus uses this, which I like the most at first sight. It basically > turns off bundler > > Ruby Fedora packagers (Vit Ondruch) are currently communicating with > bundler upstream to add some (non-default) option to force usage of > system gems. But upsteam seems to resist. I guess that aeolus-incubator > piece is result of this discussion. I don't have high hopes for this one - I tried having this conversation with Bundler folks, but I don't think they a lot of interest in supporting rpm- (or any other package-manager) based setups. > I'd rather wait how Fedora packagers will solve this issues. They are > under heavy pressure from various Red Hat and Fedora Ruby teams. All > have the same issue with Bundler. It really seems the Aeolus approach is > the best IMHO. Since the outcome of Vit's negotiations is far from certain, and should things turn out favourably for us the solution would be similar to Aeolus (if not theirs altogether), I'd rather do it sooner than later - the amount of work is not that big. > > So how about to re-raise this again in two months? > > Btw Bundler is Linux-unfriendly in terms of serious deployment. It's > a weird approach Rails community fallen in love with IMHO. Very "cool" > for initial development, but that's all. Bundler has it's uses. I happen to think it's perfect for development, especially if you are working on multiple applications - you can easily have per-application dependencies. Bundler is also great for traditional web-application deployments, as it guarantees that you will end up with exact dependencies you need. Let's face it - rpms and bundler-based deployments are two very different use cases, and we *have to* support both. -d PS> Perhaps we need to have a broader discussion about the idea of Katello community. How do we see it? What kind of developers we expect to attract? Users of which linux/unix distros do we expect to attract? From msuchy at redhat.com Thu Aug 2 12:45:17 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Thu, 02 Aug 2012 14:45:17 +0200 Subject: [katello-devel] Starting "What is new" page In-Reply-To: <20120802121442.GH2524@lzapx.brq.redhat.com> References: <20120802113613.GD2524@lzapx.brq.redhat.com> <501A66C8.6090301@redhat.com> <20120802121442.GH2524@lzapx.brq.redhat.com> Message-ID: <501A765D.5000602@redhat.com> On 08/02/2012 02:14 PM, Lukas Zapletal wrote: > Hey, I can't edit that. You can now. -- Miroslav Suchy Red Hat Systems Management Engineering From msuchy at redhat.com Thu Aug 2 12:49:45 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Thu, 02 Aug 2012 14:49:45 +0200 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <501A6FA1.6090206@redhat.com> References: <501A4A5C.6040208@redhat.com> <20120802115743.GE2524@lzapx.brq.redhat.com> <501A6FA1.6090206@redhat.com> Message-ID: <501A7769.1000704@redhat.com> On 08/02/2012 02:16 PM, Dmitri Dolguikh wrote: > How do we see it? Just my personal view. > What kind of developers we expect to attract? Users of > which linux/unix distros do we expect to attract? We have Katello on RHEL and Fedora. So it would be nice to start with developers on RHEL and Fedora. -- Miroslav Suchy Red Hat Systems Management Engineering From lzap at redhat.com Thu Aug 2 12:50:45 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 2 Aug 2012 14:50:45 +0200 Subject: [katello-devel] Setting a user's preferred locale via cli In-Reply-To: <801000414.27887560.1343909170496.JavaMail.root@redhat.com> References: <20120802083023.GB2524@lzapx.brq.redhat.com> <801000414.27887560.1343909170496.JavaMail.root@redhat.com> Message-ID: <20120802125045.GJ2524@lzapx.brq.redhat.com> On Thu, Aug 02, 2012 at 08:06:10AM -0400, Tom McKay wrote: > Disagree that this is not worth a RFE. Just like in the UI, where the > user may override the default browser locale, a --locale option would > allow the user to override the systems default locale. I am voting for > the RFE. Browser's not UNIX. -- Later, Lukas "lzap" Zapletal #katello #systemengine From kybaker at redhat.com Thu Aug 2 13:04:41 2012 From: kybaker at redhat.com (Kyle Baker) Date: Thu, 2 Aug 2012 09:04:41 -0400 (EDT) Subject: [katello-devel] default user page size In-Reply-To: <20120802081633.GA2524@lzapx.brq.redhat.com> Message-ID: <485459670.4506205.1343912681995.JavaMail.root@redhat.com> ----- Original Message ----- > On Wed, Aug 01, 2012 at 03:24:04PM -0600, Jason Rist wrote: > > +1. Might also be worth loading more a few seconds after the page > > is loaded? > > > > I am fine with 50, but please DO NOT optimize at this point. As > Donald > Knuth said "premature optimization is the root of all evil". ;-) I'm curious how much extra time will it take for 50 items to load vs. 25. Does anyone know? I'm sure it depends on resources available. > > 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 tstrachota at redhat.com Thu Aug 2 13:06:02 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Thu, 02 Aug 2012 15:06:02 +0200 Subject: [katello-devel] Setting a user's preferred locale via cli In-Reply-To: <801000414.27887560.1343909170496.JavaMail.root@redhat.com> References: <801000414.27887560.1343909170496.JavaMail.root@redhat.com> Message-ID: <501A7B3A.2040300@redhat.com> On 08/02/2012 02:06 PM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Lukas Zapletal" >> To: katello-devel at redhat.com >> Sent: Thursday, August 2, 2012 4:30:23 AM >> Subject: Re: [katello-devel] Setting a user's preferred locale via cli >> >> On Wed, Aug 01, 2012 at 11:19:47PM -0700, Michael McCune wrote: >>> no way todo it now but it wouldn't be that hard to add. Just file >>> an RFE and we can triage it appropriately. patches happily >>> accepted >>> :) >>> >> >> Well, why to introduce new option when you can do this in UNIX: >> >> LC_ALL=fr katello environment list >> >> What CLI does it sends this locale to the server so the Katello >> server >> returns all data in French (well not data but all constants there). >> It should also switch over to French in this case (for all messages >> and >> column names for example - CLI is localized of course). >> >> You have discovered a bug, Og. While it should work, what we do in >> our >> source code base is we always get system's default locale (in my case >> English). So we do not take user's setting into effect. >> >> So I filed new bug: >> https://bugzilla.redhat.com/show_bug.cgi?id=845198 >> >> We will not introduce new option you recommend (if you filed a RFE >> please close it), but we will rather fix this one. Then it should >> work >> the usual way (e.g. if I as Czech ssh into a box with English system >> locale, ssh in the default configuration will switch my environment >> to >> Czech, so Katello CLI will work in Czech for me). >> >> Nice find, especially when your default one is English (I guess :-) >> >> LZ >> >> -- >> Later, >> >> Lukas "lzap" Zapletal >> #katello #systemengine >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > > Disagree that this is not worth a RFE. Just like in the UI, where the user may override the default browser locale, a --locale option would allow the user to override the systems default locale. I am voting for the RFE. > I vote for using LC_ALL. The functionality is in fact the same so I'd prefer to be unix-consistent. T. From jsherril at redhat.com Thu Aug 2 13:10:33 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 02 Aug 2012 09:10:33 -0400 Subject: [katello-devel] default user page size In-Reply-To: <485459670.4506205.1343912681995.JavaMail.root@redhat.com> References: <485459670.4506205.1343912681995.JavaMail.root@redhat.com> Message-ID: <501A7C49.2080707@redhat.com> On 08/02/2012 09:04 AM, Kyle Baker wrote: > > ----- Original Message ----- >> On Wed, Aug 01, 2012 at 03:24:04PM -0600, Jason Rist wrote: >>> +1. Might also be worth loading more a few seconds after the page >>> is loaded? >>> >> I am fine with 50, but please DO NOT optimize at this point. As >> Donald >> Knuth said "premature optimization is the root of all evil". ;-) > I'm curious how much extra time will it take for 50 items to load vs. 25. Does anyone know? I'm sure it depends on resources available. It depends greatly on a lot of factors. Not sure that you can say a single answer for all pages in the app. -Justin >> LZ >> >> -- >> 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 Thu Aug 2 13:24:39 2012 From: ehelms at redhat.com (Eric Helms) Date: Thu, 02 Aug 2012 09:24:39 -0400 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <501A4A5C.6040208@redhat.com> References: <501A4A5C.6040208@redhat.com> Message-ID: <501A7F97.7060100@redhat.com> On 08/02/2012 05:37 AM, Dmitri Dolguikh wrote: > Hey guys, > > Should we use travis-ci? I think so, for a couple of reasons: > - it'd be helpful for community to know the current status of codebase > - it would force us to maintain a subset of fast developer-tests (as > in TDD) Do you have an idea for the last bullet? I ask since our current "unit" test suite of spec tests runs quite slowly and at times aggravatingly. > > Aeolus project has an extension for Bundler that allows for simple > switching between bundler- and rpm-based application deployments. It > relies on an environment variable to switch between the two > behaviours. In rpm-mode the extension takes over dependency loading: > it relaxes version restrictions for gems, and then loads the > dependencies. See https://github.com/aeolus-incubator/bundler_ext for > details and > https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb > for example of real-world use. > > I think it makes sense to adopt that extension in katello. > > > Thoughts/opinions? > -d > > > > _______________________________________________ > 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 jomara at redhat.com Thu Aug 2 13:32:20 2012 From: jomara at redhat.com (Jordan OMara) Date: Thu, 2 Aug 2012 09:32:20 -0400 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <501A7F97.7060100@redhat.com> References: <501A4A5C.6040208@redhat.com> <501A7F97.7060100@redhat.com> Message-ID: <20120802133220.GC61308@redhat.com> On 02/08/12 09:24 -0400, Eric Helms wrote: >On 08/02/2012 05:37 AM, Dmitri Dolguikh wrote: >>Hey guys, >> >>Should we use travis-ci? I think so, for a couple of reasons: >> - it'd be helpful for community to know the current status of codebase >> - it would force us to maintain a subset of fast developer-tests >>(as in TDD) >Do you have an idea for the last bullet? I ask since our current >"unit" test suite of spec tests runs quite slowly and at times >aggravatingly. >> There's nothing stopping us (other than effort) from creating a minitest unit suite alongside the rspec tests. However I am not sure that is a good idea emotionally -- 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 hbrock at redhat.com Thu Aug 2 14:09:46 2012 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 2 Aug 2012 10:09:46 -0400 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <501A6FA1.6090206@redhat.com> References: <501A4A5C.6040208@redhat.com> <20120802115743.GE2524@lzapx.brq.redhat.com> <501A6FA1.6090206@redhat.com> Message-ID: <20120802140945.GH6864@redhat.com> On Thu, Aug 02, 2012 at 01:16:33PM +0100, Dmitri Dolguikh wrote: > On 02/08/12 12:57 PM, Lukas Zapletal wrote: > >On Thu, Aug 02, 2012 at 10:37:32AM +0100, Dmitri Dolguikh wrote: > >>Aeolus project has an extension for Bundler that allows for simple > >>switching between bundler- and rpm-based application deployments. It > >>relies on an environment variable to switch between the two > >>behaviours. In rpm-mode the extension takes over dependency loading: > >>it relaxes version restrictions for gems, and then loads the > >>dependencies. See https://github.com/aeolus-incubator/bundler_ext > >>for details and https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb > >>for example of real-world use. > >> > >There has been several approaches discussed this year on the fedora ruby > >sig mailing list. > > > >Katello took the simplest approach - to delete Gemfile.lock every start, > >bundler just creates new from existing (local) system gems. > That's not a great approach. You just removed specific versions of > gems for deployment. Not everybody deploys using rpms (I, for one, > don't). We had several motivations for going down the Bundler path and it seems worthwhile explaining them -- and thanks for your interest, BTW! First: While we recognize that our product will be delivered as RPMs, we also recognize that the set of Real Ruby Developers who deliver their projects as RPMs ~= {}. We are very, very focused on upstream growth and involvement right now, and I am absolutely committed to knocking down any barriers in the way of external contributors. Yum and RPM and a Fedora dependency are, unfortunately, barriers. Rather high ones, as it turns out. Second: It has been really quite easy to patch Bundler to allow developers to work in whatever way they want. Want to use system gems installed as RPMs? mv Gemfile Gemfile.in and set the appropriate environment variable. Want to use rvm + userspace gems? Do nothing -- it just works. There's really no inconvenience either way. Third: I can't even begin to count the man-months we have expended on packaging gems as RPMs, tracking down their dependencies and packaging them, for no one's benefit but our own. *No one* uses the fedora-packaged rubygems that we spend so much effort on except us. We then have to redo most of that work to make things work on RHEL. It's a total time-sink that our competitors simply do not have to deal with. For this reason, I'm pushing our upstream to ignore RPM packaging altogether and work "the ruby way." We'll package for RHEL as part of gearing up for product releases, and hopefully the advent of DSCs will make that a bit easier. Anyway, this was the motivation behind the bundler patches. I hope they turn out to be helpful for you guys! Take care, --Hugh > > > > >Foreman uses approach to run bundler install --local in the post RPM > >transaction. It's quick and nice, but it does not work when you update > >dependencies (then it actually breaks). > > > >Aeolus uses this, which I like the most at first sight. It basically > >turns off bundler > > > >Ruby Fedora packagers (Vit Ondruch) are currently communicating with > >bundler upstream to add some (non-default) option to force usage of > >system gems. But upsteam seems to resist. I guess that aeolus-incubator > >piece is result of this discussion. > I don't have high hopes for this one - I tried having this > conversation with Bundler folks, but I don't think they a lot of > interest in supporting rpm- (or any other package-manager) based > setups. > > >I'd rather wait how Fedora packagers will solve this issues. They are > >under heavy pressure from various Red Hat and Fedora Ruby teams. All > >have the same issue with Bundler. It really seems the Aeolus approach is > >the best IMHO. > Since the outcome of Vit's negotiations is far from certain, and > should things turn out favourably for us the solution would be > similar to Aeolus (if not theirs altogether), I'd rather do it > sooner than later - the amount of work is not that big. > > > > >So how about to re-raise this again in two months? > > > >Btw Bundler is Linux-unfriendly in terms of serious deployment. It's > >a weird approach Rails community fallen in love with IMHO. Very "cool" > >for initial development, but that's all. > Bundler has it's uses. I happen to think it's perfect for > development, especially if you are working on multiple applications > - you can easily have per-application dependencies. Bundler is also > great for traditional web-application deployments, as it guarantees > that you will end up with exact dependencies you need. > > Let's face it - rpms and bundler-based deployments are two very > different use cases, and we *have to* support both. > > -d > PS> Perhaps we need to have a broader discussion about the idea of > Katello community. How do we see it? What kind of developers we > expect to attract? Users of which linux/unix distros do we expect to > attract? > > > > _______________________________________________ > 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 dmitri at redhat.com Thu Aug 2 14:20:00 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 02 Aug 2012 15:20:00 +0100 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <20120802133220.GC61308@redhat.com> References: <501A4A5C.6040208@redhat.com> <501A7F97.7060100@redhat.com> <20120802133220.GC61308@redhat.com> Message-ID: <501A8C90.70905@redhat.com> On 02/08/12 02:32 PM, Jordan OMara wrote: > On 02/08/12 09:24 -0400, Eric Helms wrote: >> On 08/02/2012 05:37 AM, Dmitri Dolguikh wrote: >>> Hey guys, >>> >>> Should we use travis-ci? I think so, for a couple of reasons: >>> - it'd be helpful for community to know the current status of codebase >>> - it would force us to maintain a subset of fast developer-tests (as >>> in TDD) >> Do you have an idea for the last bullet? I ask since our current >> "unit" test suite of spec tests runs quite slowly and at times >> aggravatingly. >>> > > There's nothing stopping us (other than effort) from creating a > minitest unit suite alongside the rspec tests. > > However I am not sure that is a good idea emotionally I've no idea what you mean by this. -d > > > > _______________________________________________ > 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 mrao at redhat.com Thu Aug 2 14:24:23 2012 From: mrao at redhat.com (Malini Rao) Date: Thu, 2 Aug 2012 10:24:23 -0400 (EDT) Subject: [katello-devel] default user page size In-Reply-To: <5019AF37.8040501@redhat.com> Message-ID: <1491110535.8792411.1343917463992.JavaMail.root@redhat.com> ----- Original Message ----- From: "Jason Rist" To: "Brad Buckingham" Cc: katello-devel at redhat.com Sent: Wednesday, August 1, 2012 6:35:35 PM Subject: Re: [katello-devel] default user page size On Wed 01 Aug 2012 04:34:02 PM MDT, Brad Buckingham wrote: > On 08/01/2012 06:10 PM, Justin Sherrill wrote: >> On 08/01/2012 05:47 PM, Tom McKay wrote: >>> >>> ----- Original Message ----- >>>> From: "Justin Sherrill" >>>> To: katello-devel at redhat.com >>>> Sent: Wednesday, August 1, 2012 5:20:53 PM >>>> Subject: [katello-devel] default user page size >>>> >>>> Currently our user page size is set at 25, and I believe this might >>>> be a >>>> little too low. We had talked about increasing it, but I wanted to >>>> get >>>> some discussion. Thoughts on increasing the default to 50? >>>> >>>> -Justin >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> >>> I'm not against it, but I'd like to see the current settings >>> validated a bit more on large "real" data sets before I'm >>> enthusiastic. Are there any two-pane views where the left list >>> triggers a backend-call-per-entry currently? >> >> The only one I know of is the Systems page, although your >> subscriptions tupane page might, you'd know the answer to that. >> >> I think 25 is too few for most places such as content search and >> promotions. We could ignore the page size for those places (since >> they are very different than tupane) and just use a larger fixed >> number if we wanted too. >> >> -Justin >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > While we are at it, should we make it configurable (but provide an > upper and lower bound)? > Right now we have a page-size, but is hard-coded for every user and no > way to change it in UI/API/CLI > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel +1 to configurable - I think that was always the plan. I'm thinking we have a page size and an opt-out option. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist So, I decided to ask some of the consultants in the training session that I am right now attending what they thought about the page size and they told me they are usually managing 100s of systems in the real world and they are usually managed in groups that allows them to handle fewer at a time. However, they love what Satellite lets them do which is the ability to set the size ( 50, 100, 200 all the way upto 400 (!!!) per page). So, I think cranking up to 50 for the starting default size is a great idea and any additional configuration will be a big bonus. If we allow them to change the default size, then they expect the system to remember this when they log back in. One consultant also highlighted the perils of a 'select all' on a list ( don't know if we have that ability in Katello) that only selects all on a page and not the whole result set. Hope this helps. I like the idea of having a different default size for content search and promotions. -Malini _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From jpazdziora at redhat.com Thu Aug 2 14:48:17 2012 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 2 Aug 2012 16:48:17 +0200 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <20120802140945.GH6864@redhat.com> References: <501A4A5C.6040208@redhat.com> <20120802115743.GE2524@lzapx.brq.redhat.com> <501A6FA1.6090206@redhat.com> <20120802140945.GH6864@redhat.com> Message-ID: <20120802144817.GO3029@redhat.com> On Thu, Aug 02, 2012 at 10:09:46AM -0400, Hugh Brock wrote: > > Third: I can't even begin to count the man-months we have expended on > packaging gems as RPMs, tracking down their dependencies and packaging > them, for no one's benefit but our own. *No one* uses the > fedora-packaged rubygems that we spend so much effort on except us. We Not even the users who want to install and use your software on Fedora or on RHEL, rather than develop it? Users of the software shouldn't even know that the thing is written in Ruby, or Python, or Perl. Software on Fedora gets installed via rpm / yum, and that's what the *users* should install on their rpm-based distribution. Not to be forced to deal with packaging system specific to the programming language used to develop the project. It's been years since I had to run "perl -MCPAN ..." or "perl Makefile.PL && make ..." for things I don't develop -- lately I just do "yum install 'perl(The::Module')'", or even better, let the rpm dependencies of the software's rpm handle it. > then have to redo most of that work to make things work on RHEL. It's > a total time-sink that our competitors simply do not have to deal > with. For this reason, I'm pushing our upstream to ignore RPM > packaging altogether and work "the ruby way." We'll package for RHEL > as part of gearing up for product releases, and hopefully the advent > of DSCs will make that a bit easier. The early user adoption of new projects for RHEL should be in Fedora, and those should be via rpm. Properly packaging the software in rpm forces the maintainers to also think about things like SELinux, things that competitors don't have to think about, but that are essential for smooth integration in Fedora and RHEL. For developers, The Ruby way makes sense. For users, they shouldn't even know that there's some Ruby underneath. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat From calfonso at redhat.com Thu Aug 2 16:50:17 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Thu, 2 Aug 2012 12:50:17 -0400 Subject: [katello-devel] (no subject) Message-ID: <1343926218-4023-1-git-send-email-calfonso@redhat.com> This is for the restapi branch of katello. From calfonso at redhat.com Thu Aug 2 16:50:18 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Thu, 2 Aug 2012 12:50:18 -0400 Subject: [katello-devel] [PATCH katello] Switching oauth warden strategy to use request.headers In-Reply-To: <1343926218-4023-1-git-send-email-calfonso@redhat.com> References: <1343926218-4023-1-git-send-email-calfonso@redhat.com> Message-ID: <1343926218-4023-2-git-send-email-calfonso@redhat.com> request.env doesn't have the HTTP_KATELLO_USER set as header from the client. Since request is from ActionDispatch, the header names are converted from '-' to '_'. --- src/config/initializers/warden.rb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/config/initializers/warden.rb b/src/config/initializers/warden.rb index 6924f7c..3508cca 100644 --- a/src/config/initializers/warden.rb +++ b/src/config/initializers/warden.rb @@ -141,7 +141,7 @@ Warden::Strategies.add(:oauth) do end def authenticate! - return fail("no 'katello-user' header") if request.env['HTTP_KATELLO_USER'].blank? + return fail("no 'katello-user' header") if request.headers['HTTP_KATELLO_USER'].blank? consumer_key = OAuth::RequestProxy.proxy(request).oauth_consumer_key signature=OAuth::Signature.build(request) do @@ -150,7 +150,7 @@ Warden::Strategies.add(:oauth) do return fail!("Invalid oauth signature") unless signature.verify - u = User.where(:username => request.env['HTTP_KATELLO_USER']).first + u = User.where(:username => request.headers['HTTP_KATELLO_USER']).first u ? success!(u, "OAuth") : fail!("Username is not correct - could not log in") rescue OAuth::Signature::UnknownSignatureMethod => e Rails.logger.error "Unknown oauth signature method"+ e.to_s -- 1.7.11.2 From bkearney at redhat.com Thu Aug 2 20:27:26 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 02 Aug 2012 16:27:26 -0400 Subject: [katello-devel] Katello 1.0 checklist and install notes In-Reply-To: <501996EB.5000507@redhat.com> References: <501996EB.5000507@redhat.com> Message-ID: <501AE2AE.9080301@redhat.com> On 08/01/2012 04:51 PM, Mike McCune wrote: > Threw up this etherpad to track things we want todo for the 1.0 release > and current issues with the install: > > http://pad-katello.rhcloud.com/p/v1-todo > > Mike Added one check: - Can do one remote package install Lets exercise AMQP. -- bk From dmitri at redhat.com Fri Aug 3 08:35:50 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 03 Aug 2012 09:35:50 +0100 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <20120802144817.GO3029@redhat.com> References: <501A4A5C.6040208@redhat.com> <20120802115743.GE2524@lzapx.brq.redhat.com> <501A6FA1.6090206@redhat.com> <20120802140945.GH6864@redhat.com> <20120802144817.GO3029@redhat.com> Message-ID: <501B8D66.5050707@redhat.com> I think the rpm/yum vs. gems (or eggs, or CPAN) discussion is not very useful. We have two rather distinct groups of people in our community - those who only use software, and those who also [help to] develop it. It is my *very* strong opinion that we need to support both. On 02/08/12 03:48 PM, Jan Pazdziora wrote: > On Thu, Aug 02, 2012 at 10:09:46AM -0400, Hugh Brock wrote: >> Third: I can't even begin to count the man-months we have expended on >> packaging gems as RPMs, tracking down their dependencies and packaging >> them, for no one's benefit but our own. *No one* uses the >> fedora-packaged rubygems that we spend so much effort on except us. We > Not even the users who want to install and use your software on > Fedora or on RHEL, rather than develop it? Users of the software > shouldn't even know that the thing is written in Ruby, or Python, > or Perl. Software on Fedora gets installed via rpm / yum, and that's > what the *users* should install on their rpm-based distribution. > Not to be forced to deal with packaging system specific to the > programming language used to develop the project. > > It's been years since I had to run "perl -MCPAN ..." or "perl > Makefile.PL && make ..." for things I don't develop -- lately I just > do "yum install 'perl(The::Module')'", or even better, let the rpm > dependencies of the software's rpm handle it. > >> then have to redo most of that work to make things work on RHEL. It's >> a total time-sink that our competitors simply do not have to deal >> with. For this reason, I'm pushing our upstream to ignore RPM >> packaging altogether and work "the ruby way." We'll package for RHEL >> as part of gearing up for product releases, and hopefully the advent >> of DSCs will make that a bit easier. > The early user adoption of new projects for RHEL should be in Fedora, > and those should be via rpm. Properly packaging the software in rpm > forces the maintainers to also think about things like SELinux, > things that competitors don't have to think about, but that are > essential for smooth integration in Fedora and RHEL. I'm afraid you can't mandate the platform[s] of your choice to the community, at least in the oss world, period (incidentally, that's one of the reasons for recent conversations about packaging for debian's apt-get). You could, however, say something like: "We do our development on Fedora and RHEL. You'll find that at the moment it is easier to run katello on these platforms, and you'll be able to try new features sooner." > For developers, The Ruby way makes sense. For users, they shouldn't > even know that there's some Ruby underneath. > -d From lzap at redhat.com Fri Aug 3 08:39:55 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 3 Aug 2012 10:39:55 +0200 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <501A6FA1.6090206@redhat.com> References: <501A4A5C.6040208@redhat.com> <20120802115743.GE2524@lzapx.brq.redhat.com> <501A6FA1.6090206@redhat.com> Message-ID: <20120803083955.GA3583@lzapx.brq.redhat.com> On Thu, Aug 02, 2012 at 01:16:33PM +0100, Dmitri Dolguikh wrote: > >There has been several approaches discussed this year on the fedora ruby > >sig mailing list. > > > >Katello took the simplest approach - to delete Gemfile.lock every start, > >bundler just creates new from existing (local) system gems. > That's not a great approach. You just removed specific versions of > gems for deployment. Not everybody deploys using rpms (I, for one, > don't). I think I did not elaborate this much. We do delete the lock file, but on the installer system (Fedora, RHEL). Not in the git. We do not "remove specific versions of gems", simply because they are all already installed by RPM. > Let's face it - rpms and bundler-based deployments are two very > different use cases, and we *have to* support both. And I am not saying let's throw away bundler. We need to deal with it. Right now we have our own "simple" solution. If you want to go and try to turn this over to Aeolus approach, why not. Different solution to the same problem, but it worths making that Aeolus library a gem or dependency (RPM as well of course :-) Third piece in the party is Foreman. What are the plans in this case Ohad? -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Aug 3 08:41:38 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 3 Aug 2012 10:41:38 +0200 Subject: [katello-devel] A couple of community-related questions In-Reply-To: <501B8D66.5050707@redhat.com> References: <501A4A5C.6040208@redhat.com> <20120802115743.GE2524@lzapx.brq.redhat.com> <501A6FA1.6090206@redhat.com> <20120802140945.GH6864@redhat.com> <20120802144817.GO3029@redhat.com> <501B8D66.5050707@redhat.com> Message-ID: <20120803084138.GB3583@lzapx.brq.redhat.com> On Fri, Aug 03, 2012 at 09:35:50AM +0100, Dmitri Dolguikh wrote: > I think the rpm/yum vs. gems (or eggs, or CPAN) discussion is not > very useful. We have two rather distinct groups of people in our > community - those who only use software, and those who also [help > to] develop it. It is my *very* strong opinion that we need to > support both. Well, gem and cpan are *exact* same things. It's just a matter of maturity. If Fedora packagers would add all our deps, we wouldn't have such a discussion now. Ruby is just too young. ;-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From tstrachota at redhat.com Fri Aug 3 10:25:42 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Fri, 03 Aug 2012 12:25:42 +0200 Subject: [katello-devel] CLI docs Message-ID: <501BA726.4080103@redhat.com> Hi team, I created basic sphinx documentation for our python cli codebase. It is available here: http://tstrachota.fedorapeople.org/katello_cli_docs/ Big portion of the docs is autogenerated from docstrings. It is much easier to update a docstring when you modify something in the code then keep on mind that you have to change also the wiki. Feel free to add mroe stuff there. Tomas From mmccune at redhat.com Fri Aug 3 17:00:05 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 03 Aug 2012 10:00:05 -0700 Subject: [katello-devel] Can we get a review? Message-ID: <501C0395.50607@redhat.com> This PR has been open for quite some time: https://github.com/Katello/katello/pull/176 Thanks, Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From msuchy at redhat.com Fri Aug 3 17:33:58 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Fri, 03 Aug 2012 19:33:58 +0200 Subject: [katello-devel] Fedora package review Message-ID: <501C0B86.9020605@redhat.com> If somebody (who is fedora packager) is willing to do the review: https://bugzilla.redhat.com/show_bug.cgi?id=845643 Mirek From ehelms at redhat.com Sat Aug 4 01:58:46 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 3 Aug 2012 21:58:46 -0400 (EDT) Subject: [katello-devel] Proposal: Breaking up Codebase In-Reply-To: <939291157.20377.1344043871149.JavaMail.root@redhat.com> Message-ID: <16990899.70983.1344045526288.JavaMail.root@redhat.com> Prior to using Github for source control management, the project had one logical repository available that made sense for keeping the various components of Katello contained within. As the project has grown, and as our community efforts increase I propose we break out code base elements from our mainline repository for the following reasons: 1) Reduces the overall size of the project repository. 2) Provides smaller, logical components that users and developers can work from and on. This makes it easier for the community to contribute as they can work on components that are important to them, that they are more comfortable working on and are smaller (a.k.a less imposing due to size). 3) Decreases "tag-mania" on the mainline repository and lets the tags and the packages they are associated with live on their own. Provides direct connection between package and repository (e.g. katello-cli.rpm is derived from katello-cli git repository) 4) Some components just have no logical reason to be contained within the same repository. (e.g. I don't need the CLI code to run and work on Katello) 5) The Github Organization concept with multiple repositories makes it easy to manage multiple applications and pull requests associated with each. Components I currently see that could be stand-alone repositories: cli/ agent/ certs-tools/ puppet/ repos/ src/ (a.k.a Katello) To quote Jordan: DISCUSS Thanks, Eric From msuchy at redhat.com Sat Aug 4 06:57:22 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Sat, 04 Aug 2012 08:57:22 +0200 Subject: [katello-devel] Proposal: Breaking up Codebase In-Reply-To: <16990899.70983.1344045526288.JavaMail.root@redhat.com> References: <16990899.70983.1344045526288.JavaMail.root@redhat.com> Message-ID: <501CC7D2.3010608@redhat.com> On 4.8.2012 03:58, Eric Helms wrote: > Prior to using Github for source control management, the project had one logical repository available that made sense for keeping the various components of Katello contained within. As the project has grown, and as our community efforts increase I propose we break out code base elements from our mainline repository for the following reasons: > > 1) Reduces the overall size of the project repository. > 2) Provides smaller, logical components that users and developers can work from and on. This makes it easier for the community to contribute as they can work on components that are important to them, that they are more comfortable working on and are smaller (a.k.a less imposing due to size). > 3) Decreases "tag-mania" on the mainline repository and lets the tags and the packages they are associated with live on their own. Provides direct connection between package and repository (e.g. katello-cli.rpm is derived from katello-cli git repository) > 4) Some components just have no logical reason to be contained within the same repository. (e.g. I don't need the CLI code to run and work on Katello) > 5) The Github Organization concept with multiple repositories makes it easy to manage multiple applications and pull requests associated with each. I do no like it. ad 1) I will have to have checkout of all repositories anyway, so the total size will be same anyway. Our project is in fact not so big. When I switch branch, I never waited more then faction of one second. ad 2) I do not see how it make easier to contribute. Those packages are tightly related to each other. You could not work on katello-configure without knowledge of katello itself and vice versa. ad 3) I do not understand what you mean by "tag-mania"? In fact having one package per one git repositories means more maintenance, because you have to manage more /rel-eng/ directories and keep them in sync. ad 4) When we are delivering Katello, we deliver all components. If you do not need for your work CLI, that does not mean that you have to be aware of its presence. You should not make change in CLI, which breaks katello and vice versa. Having these package in one repo, is IMO good thing because it keeps you thinking about all other components. Mirek From msuchy at redhat.com Sat Aug 4 08:40:23 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Sat, 04 Aug 2012 10:40:23 +0200 Subject: [katello-devel] Description of Katello project In-Reply-To: <501c7bdb4bdb1_719ec0a7434135@dxgxhf1.ch3.sourceforge.com.tmail> References: <501c7bdb4bdb1_719ec0a7434135@dxgxhf1.ch3.sourceforge.com.tmail> Message-ID: <501CDFF7.3010309@redhat.com> This is what I got from freecode.com, when I submited Katello project with this description (stolen from katello.org): Katello is here to help you take control of your software and your systems in an easy-to-use and scalable manner. It offers a modern web user interface that scales from a small setup with 10 systems to a large installation of thousands of systems across various geographies. Katello can pull in content from remote repositories, local directories and ISOs. You can then organize that content into repositories that are easily searchable, filtered, manipulated and controlled in a locked-down container called an Environment. Katello integrates the open-source projects Pulp, Candlepin, and Foreman with a modern Rails front end and a Python CLI to make it easier than ever to manage your systems and content the way you do business. And I understand that, because that is very vague. Therefore I declare competition for one or two sentence description of our project. Winner will get forever lasting glory. Mirek -------- Original Message -------- Subject: Katello [021454de337] Date: Sat, 4 Aug 2012 01:33:15 +0000 From: Freecode ticketing To: undisclosed-recipients:; // Add your reply above here ================================================================================ jeffcovey created this ticket on 2012-08-04 01:33:15 UTC From the description you gave, I can't make out what this software actually does. Can you reply with a one-paragraph description of this project? Thanks, Jeff ================================================================================ State: Open Assigned to: jeffcovey Due: 2012-08-11 View this ticket online: http://freecode.com/projects/katello/tickets/021454de337 View the associated project: http://freecode.com/projects/katello From ohadlevy at redhat.com Sat Aug 4 18:29:46 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Sat, 04 Aug 2012 21:29:46 +0300 Subject: [katello-devel] Proposal: Breaking up Codebase In-Reply-To: <16990899.70983.1344045526288.JavaMail.root@redhat.com> References: <16990899.70983.1344045526288.JavaMail.root@redhat.com> Message-ID: <501D6A1A.1080108@redhat.com> On 08/04/2012 04:58 AM, Eric Helms wrote: > Prior to using Github for source control management, the project had one logical repository available that made sense for keeping the various components of Katello contained within. As the project has grown, and as our community efforts increase I propose we break out code base elements from our mainline repository for the following reasons: > > 1) Reduces the overall size of the project repository. > 2) Provides smaller, logical components that users and developers can work from and on. This makes it easier for the community to contribute as they can work on components that are important to them, that they are more comfortable working on and are smaller (a.k.a less imposing due to size). > 3) Decreases "tag-mania" on the mainline repository and lets the tags and the packages they are associated with live on their own. Provides direct connection between package and repository (e.g. katello-cli.rpm is derived from katello-cli git repository) > 4) Some components just have no logical reason to be contained within the same repository. (e.g. I don't need the CLI code to run and work on Katello) > 5) The Github Organization concept with multiple repositories makes it easy to manage multiple applications and pull requests associated with each. > > > Components I currently see that could be stand-alone repositories: > > cli/ > agent/ > certs-tools/ > puppet/ > repos/ > src/ (a.k.a Katello) > > > To quote Jordan: DISCUSS +1 I think its easier (at least in github) to offer different repo permissions, makes it easier to browse and see progress of each compontent. thanks exactly how we work in foreman community [1] and it seems like it made it easier for people to contribute (e.g. for the installer etc). Ohad [1] - https://github.com/theforeman > > Thanks, > Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From msuchy at redhat.com Sun Aug 5 06:32:42 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Sun, 05 Aug 2012 08:32:42 +0200 Subject: [katello-devel] Why "gem 'tire' '< 0.4'"? Message-ID: <501E138A.8090205@redhat.com> Can someone (and I'm looking at Petr) enlighten me why we have in requires: gem 'tire' , '>= 0.3.0', '< 0.4' Commit 4c71c2f195ab351cc175599dd69fd95ed041f29d mention, that fix some issue when installing also from rubygems.org, but that is all. Why we could not have latest 0.4.2? Mirek From pchalupa at redhat.com Mon Aug 6 07:11:13 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Mon, 06 Aug 2012 09:11:13 +0200 Subject: [katello-devel] Why "gem 'tire' '< 0.4'"? In-Reply-To: <501E138A.8090205@redhat.com> References: <501E138A.8090205@redhat.com> Message-ID: <501F6E11.4070909@redhat.com> 0.4 is not backward compatible with 0.3, katello supports only tire 0.3. It has to be fixed. On 05.08.12 8:32, Miroslav Suchy wrote: > Can someone (and I'm looking at Petr) enlighten me why we have in requires: > gem 'tire' , '>= 0.3.0', '< 0.4' > > Commit > 4c71c2f195ab351cc175599dd69fd95ed041f29d > mention, that fix some issue when installing also from rubygems.org, but > that is all. > Why we could not have latest 0.4.2? > > Mirek From calfonso at redhat.com Mon Aug 6 12:01:03 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Mon, 6 Aug 2012 08:01:03 -0400 Subject: [katello-devel] Proposal: Breaking up Codebase In-Reply-To: <16990899.70983.1344045526288.JavaMail.root@redhat.com> References: <939291157.20377.1344043871149.JavaMail.root@redhat.com> <16990899.70983.1344045526288.JavaMail.root@redhat.com> Message-ID: <20120806120103.GA12368@dhcp-230-220.rdu.redhat.com> On 03/08/12 21:58 -0400, Eric Helms wrote: >Prior to using Github for source control management, the project had one logical repository available that made sense for keeping the various components of Katello contained within. As the project has grown, and as our community efforts increase I propose we break out code base elements from our mainline repository for the following reasons: > >1) Reduces the overall size of the project repository. >2) Provides smaller, logical components that users and developers can work from and on. This makes it easier for the community to contribute as they can work on components that are important to them, that they are more comfortable working on and are smaller (a.k.a less imposing due to size). >3) Decreases "tag-mania" on the mainline repository and lets the tags and the packages they are associated with live on their own. Provides direct connection between package and repository (e.g. katello-cli.rpm is derived from katello-cli git repository) >4) Some components just have no logical reason to be contained within the same repository. (e.g. I don't need the CLI code to run and work on Katello) >5) The Github Organization concept with multiple repositories makes it easy to manage multiple applications and pull requests associated with each. > > >Components I currently see that could be stand-alone repositories: > >cli/ >agent/ >certs-tools/ >puppet/ >repos/ >src/ (a.k.a Katello) > > >To quote Jordan: DISCUSS > >Thanks, >Eric > >_______________________________________________ >katello-devel mailing list >katello-devel at redhat.com >https://www.redhat.com/mailman/listinfo/katello-devel FWIW, the openstack project takes a similar approach for reason #2 above. Seems to be working out well for them. -Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From msuchy at redhat.com Mon Aug 6 12:41:26 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 06 Aug 2012 14:41:26 +0200 Subject: [katello-devel] Proposal: Breaking up Codebase In-Reply-To: <501D6A1A.1080108@redhat.com> References: <16990899.70983.1344045526288.JavaMail.root@redhat.com> <501D6A1A.1080108@redhat.com> Message-ID: <501FBB76.40809@redhat.com> On 08/04/2012 08:29 PM, Ohad Levy wrote: > thanks exactly how we work in foreman community [1] and it seems like it > made it easier for people to contribute (e.g. for the installer etc). I'm curious how do you know that is is easy compared to all files in one directory? :) Even if you convince me that contribution is easier... I just want to start building Foreman for Katello in Koji. Well it will be very hard task. :( Current layout of Foreman.git will make it unable to do builds with Tito: spec files are in separate git, each version (el6, f16...) in separate branch and only crafted for last released version. Unable to build nightly snapshots. Are you willing to accept rel-eng/* files .spec file in root of each git repo? Otherwise the nightly could not be done, and we will have to do manual builds, which is doable only for officially released versions. -- Miroslav Suchy Red Hat Systems Management Engineering From bkearney at redhat.com Mon Aug 6 12:45:34 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 06 Aug 2012 08:45:34 -0400 Subject: [katello-devel] Proposal: Breaking up Codebase In-Reply-To: <20120806120103.GA12368@dhcp-230-220.rdu.redhat.com> References: <939291157.20377.1344043871149.JavaMail.root@redhat.com> <16990899.70983.1344045526288.JavaMail.root@redhat.com> <20120806120103.GA12368@dhcp-230-220.rdu.redhat.com> Message-ID: <501FBC6E.2060601@redhat.com> On 08/06/2012 08:01 AM, Chris Alfonso wrote: > On 03/08/12 21:58 -0400, Eric Helms wrote: >> Prior to using Github for source control management, the project had >> one logical repository available that made sense for keeping the >> various components of Katello contained within. As the project has >> grown, and as our community efforts increase I propose we break out >> code base elements from our mainline repository for the following >> reasons: >> >> 1) Reduces the overall size of the project repository. >> 2) Provides smaller, logical components that users and developers can >> work from and on. This makes it easier for the community to >> contribute as they can work on components that are important to them, >> that they are more comfortable working on and are smaller (a.k.a less >> imposing due to size). >> 3) Decreases "tag-mania" on the mainline repository and lets the tags >> and the packages they are associated with live on their own. Provides >> direct connection between package and repository (e.g. katello-cli.rpm >> is derived from katello-cli git repository) >> 4) Some components just have no logical reason to be contained within >> the same repository. (e.g. I don't need the CLI code to run and work >> on Katello) >> 5) The Github Organization concept with multiple repositories makes it >> easy to manage multiple applications and pull requests associated with >> each. >> >> >> Components I currently see that could be stand-alone repositories: >> >> cli/ >> agent/ >> certs-tools/ >> puppet/ >> repos/ >> src/ (a.k.a Katello) >> >> >> To quote Jordan: DISCUSS >> If we decide to break up, I would suggest delaying until after 1.1. First, it will not add any nutty risk tot he release and second, it will allow us to stabilize the community builds before we switch things up again. -- bk From esammons at redhat.com Mon Aug 6 13:12:10 2012 From: esammons at redhat.com (Eric Sammons) Date: Mon, 6 Aug 2012 09:12:10 -0400 (EDT) Subject: [katello-devel] Setting a user's preferred locale via cli In-Reply-To: <501A7B3A.2040300@redhat.com> Message-ID: <13030032.425454.1344258730967.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/02/2012 02:06 PM, Tom McKay wrote: > > > > > > ----- Original Message ----- > >> From: "Lukas Zapletal" > >> To: katello-devel at redhat.com > >> Sent: Thursday, August 2, 2012 4:30:23 AM > >> Subject: Re: [katello-devel] Setting a user's preferred locale via > >> cli > >> > >> On Wed, Aug 01, 2012 at 11:19:47PM -0700, Michael McCune wrote: > >>> no way todo it now but it wouldn't be that hard to add. Just > >>> file > >>> an RFE and we can triage it appropriately. patches happily > >>> accepted > >>> :) > >>> > >> > >> Well, why to introduce new option when you can do this in UNIX: > >> > >> LC_ALL=fr katello environment list > >> > >> What CLI does it sends this locale to the server so the Katello > >> server > >> returns all data in French (well not data but all constants > >> there). > >> It should also switch over to French in this case (for all > >> messages > >> and > >> column names for example - CLI is localized of course). > >> > >> You have discovered a bug, Og. While it should work, what we do in > >> our > >> source code base is we always get system's default locale (in my > >> case > >> English). So we do not take user's setting into effect. > >> > >> So I filed new bug: > >> https://bugzilla.redhat.com/show_bug.cgi?id=845198 > >> > >> We will not introduce new option you recommend (if you filed a RFE > >> please close it), but we will rather fix this one. Then it should > >> work > >> the usual way (e.g. if I as Czech ssh into a box with English > >> system > >> locale, ssh in the default configuration will switch my > >> environment > >> to > >> Czech, so Katello CLI will work in Czech for me). > >> > >> Nice find, especially when your default one is English (I guess > >> :-) > >> > >> LZ > >> > >> -- > >> Later, > >> > >> Lukas "lzap" Zapletal > >> #katello #systemengine > >> > >> _______________________________________________ > >> katello-devel mailing list > >> katello-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/katello-devel > >> > > > > Disagree that this is not worth a RFE. Just like in the UI, where > > the user may override the default browser locale, a --locale > > option would allow the user to override the systems default > > locale. I am voting for the RFE. > > > > I vote for using LC_ALL. The functionality is in fact the same so I'd > prefer to be unix-consistent. > > T. > Now I thought default locale as set in the browser was strictly for the browser. When you are talking about the cli then you are talking about using the system's locale. If the katello / headpin cli are not honoring the systems locale then there is a bug here. Remember the system has a default locale and a user can override that locale in their login properties (as set in .bashrc or other). I had always assumed that the "default locale" setting was only available in the browser because it was only applicable to the browser. --Eric From bkearney at redhat.com Mon Aug 6 13:31:43 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 06 Aug 2012 09:31:43 -0400 Subject: [katello-devel] Description of Katello project In-Reply-To: <501CDFF7.3010309@redhat.com> References: <501c7bdb4bdb1_719ec0a7434135@dxgxhf1.ch3.sourceforge.com.tmail> <501CDFF7.3010309@redhat.com> Message-ID: <501FC73F.6060808@redhat.com> Katello is a systems management engine providing worklfows for configuration management, subscription management, provisioning, and content management. -- bk On 08/04/2012 04:40 AM, Miroslav Suchy wrote: > This is what I got from freecode.com, when I submited Katello project > with this description (stolen from katello.org): > > Katello is here to help you take control of your software and your > systems in an easy-to-use and scalable manner. It offers a modern web > user interface that scales from a small setup with 10 systems to a large > installation of thousands of systems across various geographies. Katello > can pull in content from remote repositories, local directories and > ISOs. You can then organize that content into repositories that are > easily searchable, filtered, manipulated and controlled in a locked-down > container called an Environment. > Katello integrates the open-source projects Pulp, Candlepin, and Foreman > with a modern Rails front end and a Python CLI to make it easier than > ever to manage your systems and content the way you do business. > > And I understand that, because that is very vague. > Therefore I declare competition for one or two sentence description of > our project. Winner will get forever lasting glory. > > Mirek > > -------- Original Message -------- > Subject: Katello [021454de337] > Date: Sat, 4 Aug 2012 01:33:15 +0000 > From: Freecode ticketing > To: undisclosed-recipients:; > > // Add your reply above here > > ================================================================================ > > > jeffcovey created this ticket on 2012-08-04 01:33:15 UTC > > From the description you gave, I can't make out what this software > actually > does. Can you reply with a one-paragraph description of this project? > > Thanks, > Jeff > > ================================================================================ > > > State: Open > Assigned to: jeffcovey > Due: 2012-08-11 > View this ticket online: > http://freecode.com/projects/katello/tickets/021454de337 > View the associated project: > http://freecode.com/projects/katello > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From esammons at redhat.com Mon Aug 6 13:35:14 2012 From: esammons at redhat.com (Eric Sammons) Date: Mon, 6 Aug 2012 09:35:14 -0400 (EDT) Subject: [katello-devel] deleting an imported manifest In-Reply-To: <395167807.22856808.1343751362095.JavaMail.root@redhat.com> Message-ID: <1299816834.441067.1344260114672.JavaMail.root@redhat.com> ----- Original Message ----- > > Candlepin is supports the deletion of an imported manifest from an > org. This, I believe, is an important feature to support in katello > as well. Does it make sense to include this ability as part of the > "content deletion" work? > > I don't know the implications surrounding this as it relates to pulp > and content. I believe this is an important feature. As a sysadmin I would like to move or re-use a manifest. Scenario 1. M1 loaded to O1, needs to be deleted as it no longer applies to O1. Scenario 2. M1 loaded to O1, needs to be deleted and re-imported to O2. --Eric > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jrist at redhat.com Mon Aug 6 13:37:42 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 06 Aug 2012 07:37:42 -0600 Subject: [katello-devel] Description of Katello project In-Reply-To: <501CDFF7.3010309@redhat.com> References: <501c7bdb4bdb1_719ec0a7434135@dxgxhf1.ch3.sourceforge.com.tmail> <501CDFF7.3010309@redhat.com> Message-ID: <501FC8A6.2010806@redhat.com> On 08/04/2012 02:40 AM, Miroslav Suchy wrote: > This is what I got from freecode.com, when I submited Katello project > with this description (stolen from katello.org): > > Katello is here to help you take control of your software and your > systems in an easy-to-use and scalable manner. It offers a modern web > user interface that scales from a small setup with 10 systems to a large > installation of thousands of systems across various geographies. Katello > can pull in content from remote repositories, local directories and > ISOs. You can then organize that content into repositories that are > easily searchable, filtered, manipulated and controlled in a locked-down > container called an Environment. > Katello integrates the open-source projects Pulp, Candlepin, and Foreman > with a modern Rails front end and a Python CLI to make it easier than > ever to manage your systems and content the way you do business. > > And I understand that, because that is very vague. > Therefore I declare competition for one or two sentence description of > our project. Winner will get forever lasting glory. > > Mirek > > -------- Original Message -------- > Subject: Katello [021454de337] > Date: Sat, 4 Aug 2012 01:33:15 +0000 > From: Freecode ticketing > To: undisclosed-recipients:; > > // Add your reply above here > > ================================================================================ > > > jeffcovey created this ticket on 2012-08-04 01:33:15 UTC > > From the description you gave, I can't make out what this software actually > does. Can you reply with a one-paragraph description of this project? > > Thanks, > Jeff > > ================================================================================ > > > State: Open > Assigned to: jeffcovey > Due: 2012-08-11 > View this ticket online: > http://freecode.com/projects/katello/tickets/021454de337 > View the associated project: > http://freecode.com/projects/katello > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I think that last chunk probably sums it up best: Katello integrates the open-source projects Pulp, Candlepin, and Foreman with a modern Rails front end and a Python CLI to make it easier than ever to manage your systems and content the way you do business. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From ohadlevy at redhat.com Mon Aug 6 13:59:16 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Mon, 06 Aug 2012 16:59:16 +0300 Subject: [katello-devel] Description of Katello project In-Reply-To: <501FC8A6.2010806@redhat.com> References: <501c7bdb4bdb1_719ec0a7434135@dxgxhf1.ch3.sourceforge.com.tmail> <501CDFF7.3010309@redhat.com> <501FC8A6.2010806@redhat.com> Message-ID: <501FCDB4.8060402@redhat.com> On 08/06/2012 04:37 PM, Jason Rist wrote: > I think that last chunk probably sums it up best: Katello integrates the > open-source projects Pulp, Candlepin, and Foreman with a modern Rails > front end and a Python CLI to make it easier than ever to manage your > systems and content the way you do business. Why would users care that much about the UI/CLI technologies used? From jrist at redhat.com Mon Aug 6 14:00:20 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 06 Aug 2012 08:00:20 -0600 Subject: [katello-devel] Description of Katello project In-Reply-To: <501FCDB4.8060402@redhat.com> References: <501c7bdb4bdb1_719ec0a7434135@dxgxhf1.ch3.sourceforge.com.tmail> <501CDFF7.3010309@redhat.com> <501FC8A6.2010806@redhat.com> <501FCDB4.8060402@redhat.com> Message-ID: <501FCDF4.2080200@redhat.com> On 08/06/2012 07:59 AM, Ohad Levy wrote: > On 08/06/2012 04:37 PM, Jason Rist wrote: >> I think that last chunk probably sums it up best: Katello integrates the >> open-source projects Pulp, Candlepin, and Foreman with a modern Rails >> front end and a Python CLI to make it easier than ever to manage your >> systems and content the way you do business. > > Why would users care that much about the UI/CLI technologies used? > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I highly suspect that katello 'users' are also 'admins' so they care what software they're using. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From mmccune at redhat.com Mon Aug 6 22:44:33 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 06 Aug 2012 15:44:33 -0700 Subject: [katello-devel] Proposal: Breaking up Codebase In-Reply-To: <16990899.70983.1344045526288.JavaMail.root@redhat.com> References: <16990899.70983.1344045526288.JavaMail.root@redhat.com> Message-ID: <502048D1.2040809@redhat.com> On 08/03/2012 06:58 PM, Eric Helms wrote: > Prior to using Github for source control management, the project had one logical repository available that made sense for keeping the various components of Katello contained within. As the project has grown, and as our community efforts increase I propose we break out code base elements from our mainline repository for the following reasons: > > 1) Reduces the overall size of the project repository. > 2) Provides smaller, logical components that users and developers can work from and on. This makes it easier for the community to contribute as they can work on components that are important to them, that they are more comfortable working on and are smaller (a.k.a less imposing due to size). > 3) Decreases "tag-mania" on the mainline repository and lets the tags and the packages they are associated with live on their own. Provides direct connection between package and repository (e.g. katello-cli.rpm is derived from katello-cli git repository) > 4) Some components just have no logical reason to be contained within the same repository. (e.g. I don't need the CLI code to run and work on Katello) > 5) The Github Organization concept with multiple repositories makes it easy to manage multiple applications and pull requests associated with each. > > > Components I currently see that could be stand-alone repositories: > > cli/ > agent/ > certs-tools/ > puppet/ > repos/ > src/ (a.k.a Katello) > > > To quote Jordan: DISCUSS > +1 from me for all the reasons stated previously on this thread. Lets do this as part of Katello 1.1. Mike From jesusr at redhat.com Tue Aug 7 02:34:17 2012 From: jesusr at redhat.com (Jesus Rodriguez) Date: Mon, 6 Aug 2012 22:34:17 -0400 (EDT) Subject: [katello-devel] Proposal: Breaking up Codebase In-Reply-To: <502048D1.2040809@redhat.com> Message-ID: <2102651289.983490.1344306857601.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Mike McCune" > To: "Eric Helms" > Cc: katello-devel at redhat.com > Sent: Monday, August 6, 2012 6:44:33 PM > Subject: Re: [katello-devel] Proposal: Breaking up Codebase > > On 08/03/2012 06:58 PM, Eric Helms wrote: > > Prior to using Github for source control management, the project > > had one logical repository available that made sense for keeping > > the various components of Katello contained within. As the > > project has grown, and as our community efforts increase I propose > > we break out code base elements from our mainline repository for > > the following reasons: > > > > 1) Reduces the overall size of the project repository. > > 2) Provides smaller, logical components that users and developers > > can work from and on. This makes it easier for the community to > > contribute as they can work on components that are important to > > them, that they are more comfortable working on and are smaller > > (a.k.a less imposing due to size). > > 3) Decreases "tag-mania" on the mainline repository and lets the > > tags and the packages they are associated with live on their own. > > Provides direct connection between package and repository (e.g. > > katello-cli.rpm is derived from katello-cli git repository) > > 4) Some components just have no logical reason to be contained > > within the same repository. (e.g. I don't need the CLI code to > > run and work on Katello) > > 5) The Github Organization concept with multiple repositories makes > > it easy to manage multiple applications and pull requests > > associated with each. > > > > > > Components I currently see that could be stand-alone repositories: > > > > cli/ > > agent/ > > certs-tools/ > > puppet/ > > repos/ > > src/ (a.k.a Katello) > > > > > > To quote Jordan: DISCUSS > > > > +1 from me for all the reasons stated previously on this thread. > Lets > do this as part of Katello 1.1. At first I was against this, but after looking at your source tree and how you guys package and use these. +1 to making separate repos. Honestly I'd make them separate and give them cool names :) cli / agent are boring :D jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ From pchalupa at redhat.com Tue Aug 7 11:45:37 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 07 Aug 2012 13:45:37 +0200 Subject: [katello-devel] Can we get a review? In-Reply-To: <501C0395.50607@redhat.com> References: <501C0395.50607@redhat.com> Message-ID: <5020FFE1.8060100@redhat.com> I am going to address it this week. On 03.08.12 19:00, Mike McCune wrote: > This PR has been open for quite some time: > > https://github.com/Katello/katello/pull/176 > > Thanks, > Mike From bkearney at redhat.com Tue Aug 7 14:58:33 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 07 Aug 2012 10:58:33 -0400 Subject: [katello-devel] Custom Values as more of a plugin model Message-ID: <50212D19.3090101@redhat.com> Adam: Ohad was commenting that he is interested in a re-usable bit of ruby functionality (gem, engine, dunno) which would allow folks to to extend a rails app on site. It sounded like custom values may be in line with that idea. Perhaps you could hook up and see if it makes sense to combine the ideas? For everyone else, for Headpin we are interested in getting custom values which can be added to certain objects (e.g A PO # to a subscription, or an asset tag to a system). We know we will get requests to brand katello and add custom pages, so perhaps we can combine them into one effort. -a- bk From adprice at redhat.com Tue Aug 7 15:43:01 2012 From: adprice at redhat.com (Adam Price) Date: Tue, 7 Aug 2012 11:43:01 -0400 (EDT) Subject: [katello-devel] Custom Values as more of a plugin model In-Reply-To: <50212D19.3090101@redhat.com> Message-ID: <2066170030.4243619.1344354181967.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Bryan Kearney" > To: katello-devel at redhat.com, "Adam Price" > Sent: Tuesday, August 7, 2012 10:58:33 AM > Subject: Custom Values as more of a plugin model > > Adam: > > Ohad was commenting that he is interested in a re-usable bit of ruby > functionality (gem, engine, dunno) which would allow folks to to > extend > a rails app on site. It sounded like custom values may be in line > with > that idea. Perhaps you could hook up and see if it makes sense to > combine the ideas? Ohad, what functionality are wanting to be re-usable? it sounds like you're wanting to make something that is modular enough to be detachable from any part of katello and then attached onto something else. That does sound in-line with custom value attaching to subscriptions, systems, or what ever else. I'm trying to think of how this would be done. With the custom values for a system, we were first thinking of having candlepin store the values, but if we'd like to do something more modular, then perhaps katello should retain the custom information and then inject it whenever an object with custom information is requested. Something along the lines of a decorator when we're grabbing data. thoughts? katello-devel, what say you? > > For everyone else, for Headpin we are interested in getting custom > values which can be added to certain objects (e.g A PO # to a > subscription, or an asset tag to a system). We know we will get > requests > to brand katello and add custom pages, so perhaps we can combine them > into one effort. > > -a- bk > -- Adam Price adprice at redhat dot com From msuchy at redhat.com Tue Aug 7 16:02:44 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Tue, 07 Aug 2012 18:02:44 +0200 Subject: [katello-devel] Custom Values as more of a plugin model In-Reply-To: <50212D19.3090101@redhat.com> References: <50212D19.3090101@redhat.com> Message-ID: <50213C24.5010406@redhat.com> On 7.8.2012 16:58, Bryan Kearney wrote: > re-usable bit of ruby functionality (gem, engine, dunno) which would > allow folks to to extend a rails app on site. I do not understand this sentence. Syntax is correct, but I do not get the semantic. Can you please elaborate it more? Mirek From msuchy at redhat.com Tue Aug 7 19:52:18 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Tue, 07 Aug 2012 21:52:18 +0200 Subject: [katello-devel] Katello 1.0 released Message-ID: <502171F2.2080407@redhat.com> Hello, we are happy to announce the first release of Katello, a systems management solution. The download locations are ? http://fedorapeople.org/groups/katello/releases/yum/1.0/RHEL/$releasever/x86_64 ? http://fedorapeople.org/groups/katello/releases/yum/1.0/Fedora/$releasever/x86_64 with client repositories under: ? http://fedorapeople.org/groups/katello/releases/yum/1.0-client/RHEL/$releasever/x86_64 ? http://fedorapeople.org/groups/katello/releases/yum/1.0-client/Fedora/$releasever/x86_64 For fresh installations, please use steps from ?https://fedorahosted.org/katello/wiki/Install Features & Enhancements in Katello 1.0 * Patch Management * Mirror content from external repositories into local Definitive Software Library. * Schedule recurring syncs of content. * Manage the content through multiple environments. * Use subscription model to associate content with machines which are registered to environments. * System Management * Inventory of systems which are registered, including installed software and system facts. * Assign subscriptions provided by Red Hat, and customer products. * Registration Macros with Activation Keys * Remote installation of packages over AMQP. * System Grouping for Batch Processing * General * LDAP integration. * Python based CLI. * REST APIacewalk.redhat.com/documentation/api/ Contributors Our thanks go to the community members who contributed to this release: * Brad P. Crochet * Jakub Steiner * Pep Turro Mauri * https://fedorahosted.org/katello/wiki/ContributorList You can view the history of Katello from its start to 1.0 at * http://www.youtube.com/watch?v=ubBI-38qVqI Some statistics: In Katello 1.0, we've seen * 624 bugs fixed * 6011 changesets committed * 6596 commits done Known issues: * registration with activation keys does not work: https://bugzilla.redhat.com/show_bug.cgi?id=844678 Thank you for using Katello. P.S. I sent this email yesterday, but for some reason it got lost. -- Miroslav Suchy Red Hat Systems Management Engineering From ehelms at redhat.com Tue Aug 7 20:23:12 2012 From: ehelms at redhat.com (Eric Helms) Date: Tue, 07 Aug 2012 16:23:12 -0400 Subject: [katello-devel] Blog and Site Accounts Message-ID: <50217930.1020603@redhat.com> Since the launch of the newer site is delayed due to DNS changes (should be occurring this Friday which means hopefully rolled over by Monday), I figure I can establish accounts ahead of time for those interested. If you would like to be an Author on the blog (able to create and write posts under your own name) please let me know on IRC or via an email and I will set up and email you credentials. If you would like to contribute by helping manage the site in other ways please email me as well. If you have a blog of your own that you would like to linked to either directly or to a feed that is related to Katello only posts, please let me know as well and I will add to the community blog aggregator. Again, full community update planning can be seen here: http://pad-katello.rhcloud.com/p/community-planning Don't forget if you make screencasts, please let us know so we can upload to our project YouTube channel that will be visible both on YouTube and our Website. Thanks, Eric From ohadlevy at redhat.com Wed Aug 8 09:45:09 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 08 Aug 2012 12:45:09 +0300 Subject: [katello-devel] Custom Values as more of a plugin model In-Reply-To: <2066170030.4243619.1344354181967.JavaMail.root@redhat.com> References: <2066170030.4243619.1344354181967.JavaMail.root@redhat.com> Message-ID: <50223525.30500@redhat.com> On 08/07/2012 06:43 PM, Adam Price wrote: > ----- Original Message ----- >> From: "Bryan Kearney" >> To: katello-devel at redhat.com, "Adam Price" >> Sent: Tuesday, August 7, 2012 10:58:33 AM >> Subject: Custom Values as more of a plugin model >> >> Adam: >> >> Ohad was commenting that he is interested in a re-usable bit of ruby >> functionality (gem, engine, dunno) which would allow folks to to >> extend >> a rails app on site. It sounded like custom values may be in line >> with >> that idea. Perhaps you could hook up and see if it makes sense to >> combine the ideas? > > Ohad, what functionality are wanting to be re-usable? it sounds like you're wanting to make something that is modular enough to be detachable from any part of katello and then attached onto something else. That does sound in-line with custom value attaching to subscriptions, systems, or what ever else. I'm trying to think of how this would be done. > > With the custom values for a system, we were first thinking of having candlepin store the values, but if we'd like to do something more modular, then perhaps katello should retain the custom information and then inject it whenever an object with custom information is requested. Something along the lines of a decorator when we're grabbing data. > > thoughts? katello-devel, what say you? Ideally, it should be a collection of the following elements: 1. be able to add new MCV's 2. be able to extend attributes of existing MVC 3. be able to add more routes, db migrations, etc. all of the above is supported afaik using rails engine (might be better supported under rails 3.1, but thats another discussion), excluding option #2 for view. In order to allow users to extend the existing view, we would need to come up with UI hooks, where people could inject stuff (e.g. like additional tab, additional dropdown etc). I think that redmine has such a system and its worth exploring how they implemented that. Ohad > > >> >> For everyone else, for Headpin we are interested in getting custom >> values which can be added to certain objects (e.g A PO # to a >> subscription, or an asset tag to a system). We know we will get >> requests >> to brand katello and add custom pages, so perhaps we can combine them >> into one effort. >> >> -a- bk >> > From ehelms at redhat.com Wed Aug 8 13:29:54 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 8 Aug 2012 09:29:54 -0400 (EDT) Subject: [katello-devel] Blog and Site Accounts In-Reply-To: <50217930.1020603@redhat.com> Message-ID: <488816924.7169272.1344432594862.JavaMail.root@redhat.com> I know I don't need to say this, but as a reminder when you get an email with your account information, please change the password ASAP and verify the profile details. Thanks, Eric ----- Original Message ----- From: "Eric Helms" To: katello-devel at redhat.com Sent: Tuesday, August 7, 2012 4:23:12 PM Subject: [katello-devel] Blog and Site Accounts Since the launch of the newer site is delayed due to DNS changes (should be occurring this Friday which means hopefully rolled over by Monday), I figure I can establish accounts ahead of time for those interested. If you would like to be an Author on the blog (able to create and write posts under your own name) please let me know on IRC or via an email and I will set up and email you credentials. If you would like to contribute by helping manage the site in other ways please email me as well. If you have a blog of your own that you would like to linked to either directly or to a feed that is related to Katello only posts, please let me know as well and I will add to the community blog aggregator. Again, full community update planning can be seen here: http://pad-katello.rhcloud.com/p/community-planning Don't forget if you make screencasts, please let us know so we can upload to our project YouTube channel that will be visible both on YouTube and our Website. Thanks, Eric _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From jesusr at redhat.com Wed Aug 8 14:26:12 2012 From: jesusr at redhat.com (jesus m. rodriguez) Date: Wed, 08 Aug 2012 10:26:12 -0400 Subject: [katello-devel] Custom Values as more of a plugin model In-Reply-To: <50223525.30500@redhat.com> References: <2066170030.4243619.1344354181967.JavaMail.root@redhat.com> <50223525.30500@redhat.com> Message-ID: <50227704.3050304@redhat.com> On 08/08/2012 05:45 AM, Ohad Levy wrote: > On 08/07/2012 06:43 PM, Adam Price wrote: >> ----- Original Message ----- >>> From: "Bryan Kearney" >>> To: katello-devel at redhat.com, "Adam Price" >>> Sent: Tuesday, August 7, 2012 10:58:33 AM >>> Subject: Custom Values as more of a plugin model >>> >>> Adam: >>> >>> Ohad was commenting that he is interested in a re-usable bit of ruby >>> functionality (gem, engine, dunno) which would allow folks to to >>> extend >>> a rails app on site. It sounded like custom values may be in line >>> with >>> that idea. Perhaps you could hook up and see if it makes sense to >>> combine the ideas? >> >> Ohad, what functionality are wanting to be re-usable? it sounds like you're wanting to make something that is modular enough to be detachable from any part of katello and then attached onto something else. That does sound in-line with custom value attaching to subscriptions, systems, or what ever else. I'm trying to think of how this would be done. >> >> With the custom values for a system, we were first thinking of having candlepin store the values, but if we'd like to do something more modular, then perhaps katello should retain the custom information and then inject it whenever an object with custom information is requested. Something along the lines of a decorator when we're grabbing data. >> >> thoughts? katello-devel, what say you? > > Ideally, it should be a collection of the following elements: > > 1. be able to add new MCV's > 2. be able to extend attributes of existing MVC > 3. be able to add more routes, db migrations, etc. > > all of the above is supported afaik using rails engine (might be better > supported under rails 3.1, but thats another discussion), excluding > option #2 for view. > > In order to allow users to extend the existing view, we would need to > come up with UI hooks, where people could inject stuff (e.g. like > additional tab, additional dropdown etc). > > I think that redmine has such a system and its worth exploring how they > implemented that. > > Ohad > [snip] In my past life (previous job) our web application had modules that we sold separately. When they were installed they would supply their own tabs to the main UI. While it wasn't a rails application, maybe the concepts can be reused. Effectively, we had the notion of a ScenarioContainer (each module was called a scenario), this container had an api that could be called by the different modules to 'register' themselves. The Container knew what tabs to turn on when the app started. The modules themselves had their own ui (same look and feel, just different pages), own schema bits, and model objects. They used events to communicate from one to another where integration was needed or used formvars to pass information from one page to another. Most of the applications had clearly defined points where you could extend the code. The UI was a bit murkier since it came with the source so consultants did the customization. In Spacewalk, I think we tried to let users customize the css and replace portions of the UI i.e. footer, header, leftnav, legends, and advertisements. http://git.fedorahosted.org/cgit/spacewalk.git/tree/java/code/webapp/WEB-INF/includes Also the layouts of the pages: http://git.fedorahosted.org/cgit/spacewalk.git/tree/java/code/webapp/WEB-INF/decorators I agree with Ohad that we "need to come up with UI hooks, where people could inject stuff (e.g. like additional tab, additional dropdown etc)." I think the key to creating a customizable application is to include hooks in key locations that folks could fill in. Very similar to how servlet filters allow you to modify the requests and response in a Java application, or interceptors in guice and resteasy work. Again these are Java things but I'm sure ruby can do similar things. Sincerely, jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ From ehelms at redhat.com Wed Aug 8 18:32:43 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 08 Aug 2012 14:32:43 -0400 Subject: [katello-devel] Remote Branch Cleanup Message-ID: <5022B0CB.8020506@redhat.com> A reminder to everyone to take a look at and clean-up any old branches that you may have left hanging around from previous development work. I currently show the following branches as not being updated within the past month: remotes/katello/1.174 remotes/katello/froyo remotes/katello/headpin remotes/katello/ldap_rebase remotes/katello/ldaproles remotes/katello/org-subs remotes/katello/pup remotes/katello/system-groups Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From kybaker at redhat.com Wed Aug 8 19:05:34 2012 From: kybaker at redhat.com (Kyle Baker) Date: Wed, 8 Aug 2012 15:05:34 -0400 (EDT) Subject: [katello-devel] Updated Content Deletion Screens Message-ID: <329660908.2284035.1344452734084.JavaMail.root@redhat.com> I have the updated wireframes and added a high fidelity mockup to the Katello wiki here - https://fedorahosted.org/katello/wiki/ContentDeletionDesign Updated items include - ? Added 'Promotable' as a view in the content dropdown ? Added a screen for 'New Changeset' showing a dialog opening downward ? Removed 'Changeset' from 'Remove Changeset' in the changeset control area ? Show expanded tipsy content on the Remove changeset control ? Added Undo control to the Added state in content list, with an expanded tool tip ? Did high fidelity mock-up Kyle Baker Visual Designer Desk (978) 392 3116 UX Team IRC kylebaker From ehelms at redhat.com Wed Aug 8 19:22:11 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 08 Aug 2012 15:22:11 -0400 Subject: [katello-devel] Updated Content Deletion Screens In-Reply-To: <329660908.2284035.1344452734084.JavaMail.root@redhat.com> References: <329660908.2284035.1344452734084.JavaMail.root@redhat.com> Message-ID: <5022BC63.2070906@redhat.com> On 08/08/2012 03:05 PM, Kyle Baker wrote: > I have the updated wireframes and added a high fidelity mockup to the Katello wiki here - https://fedorahosted.org/katello/wiki/ContentDeletionDesign > > Updated items include - > ? Added 'Promotable' as a view in the content dropdown > ? Added a screen for 'New Changeset' showing a dialog opening downward > ? Removed 'Changeset' from 'Remove Changeset' in the changeset control area > ? Show expanded tipsy content on the Remove changeset control > ? Added Undo control to the Added state in content list, with an expanded tool tip > ? Did high fidelity mock-up > > > Kyle Baker > Visual Designer Desk (978) 392 3116 > UX Team IRC kylebaker > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Two minor things, but has bugged me every time I see it. 1) On the item list when you can go down a level in content, swapping the three-dots and the add button. 2) Adding an intermediary state where "+Add" changes to "Adding..." to "Added (undo)". 3) In the wireframe, the "Added (undo)" has the three dots to indicate going deeper into the product removed. Is this a designed behavior change or missing piece? - Eric From jrist at redhat.com Wed Aug 8 19:40:52 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 08 Aug 2012 13:40:52 -0600 Subject: [katello-devel] Remote Branch Cleanup In-Reply-To: <5022B0CB.8020506@redhat.com> References: <5022B0CB.8020506@redhat.com> Message-ID: <5022C0C4.7000100@redhat.com> On Wed 08 Aug 2012 12:32:43 PM MDT, Eric Helms wrote: > A reminder to everyone to take a look at and clean-up any old branches > that you may have left hanging around from previous development work. > I currently show the following branches as not being updated within > the past month: > > remotes/katello/1.174 > remotes/katello/froyo > remotes/katello/headpin > remotes/katello/ldap_rebase > remotes/katello/ldaproles > remotes/katello/org-subs > remotes/katello/pup > remotes/katello/system-groups > > > Thanks, > Eric > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Kill 'em with fire! -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From kybaker at redhat.com Wed Aug 8 20:10:08 2012 From: kybaker at redhat.com (Kyle Baker) Date: Wed, 8 Aug 2012 16:10:08 -0400 (EDT) Subject: [katello-devel] Updated Content Deletion Screens In-Reply-To: <5022BC63.2070906@redhat.com> Message-ID: <1402802737.2310925.1344456608396.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/08/2012 03:05 PM, Kyle Baker wrote: > > I have the updated wireframes and added a high fidelity mockup to > > the Katello wiki here - > > https://fedorahosted.org/katello/wiki/ContentDeletionDesign > > > > Updated items include - > > ? Added 'Promotable' as a view in the content dropdown > > ? Added a screen for 'New Changeset' showing a dialog opening > > downward > > ? Removed 'Changeset' from 'Remove Changeset' in the changeset > > control area > > ? Show expanded tipsy content on the Remove changeset control > > ? Added Undo control to the Added state in content list, with an > > expanded tool tip > > ? Did high fidelity mock-up > > > > > > Kyle Baker > > Visual Designer Desk (978) 392 3116 > > UX Team IRC kylebaker > > > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > Two minor things, but has bugged me every time I see it. > > 1) On the item list when you can go down a level in content, swapping > the three-dots and the add button. Not sure what you are asking here. > > 2) Adding an intermediary state where "+Add" changes to "Adding..." > to > "Added (undo)". The only difference here between what exists now and the mock-up is the instead of saying "Remove" it now says "Added (Undo)". Should be no new functionality here. > > 3) In the wireframe, the "Added (undo)" has the three dots to > indicate > going deeper into the product removed. Is this a designed behavior > change or missing piece? This still functions the same only the text has changes. In the tool currently you can go deeper then the lvel that has the "Remove" text. This has not changed. Our goal here was just to edit the text to make for clearer choices though functionality should remain the same. We can certainly talk about redesigning the Sliding Tree as a separate project. > > - Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From dmitri at redhat.com Thu Aug 9 11:34:57 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 12:34:57 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) Message-ID: <5023A061.40507@redhat.com> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for description of an issue with environment renaming. The immediate problems around environments: using of environment names and environment ids for identification of environments interchangeably. Using db ids for environment identification when not using environment names. To resolve these: - introduce environment uuids - update katello/katello cli to use uuids for environment identification - update repository naming to use environment uuids - update candlepin (this will include updates to schema, and resource controller) The larger problem: Katello and Candlepin modelling of products/product content/environments lost coherency. Candlepin's view of the above trifecta (use of a monospaced font is encouraged for the content below): +-------------+ +--------------------+ | Environment | 1 <--- * | EnvironmentContent | +-------------+ +--------------------+ ^ | * | 1 +---------+ +----------------+ | Product | 1 ---> * | ProductContent | +---------+ +----------------+ same thing in Katello (with added pulp repositories): +-------------+ | Pulp::Repos |<-----------------------+ +-------------+ | ^ | | uses | +----------------------------------+ | +-------------+ | Candlepin::Product | | | Environment | | (uses Candlepin::ProductContent) | | +-------------+ +----------------------------------+ | ^ | ^ | | 1 |uses | uses | | | | | | * +---------+ +--------------------+ | Product | 1 ---------------> * | EnvironmentProduct | +---------+ +--------------------+ | |1 | |* | V | uses +------------+ +------| Repository | +------------+ I propose: - Rename EnvironmentProduct to ProductContent - make it use Candlepin::ProductContent - remove use of Pulp::Repos from Product - delegate responsibility of generation of environment uuids to Candlepin (should cp folks agree on this) resulting in: +-------------+ | Environment | +-------------+ ^ | 1 | * +---------+ +----------------+ | Product | 1 ---> * | ProductContent | +---------+ +----------------+ |1 | uses | | +---------------------------+ |1 +-> | Candlepin::ProductContent | V +---------------------------+ +-------------+ uses +------------+ | Pulp::Repos |<-----| Repository | +-------------+ +------------+ I don't think many-1 relation is required on Repository-ProductContent, it's 1-1? Thoughts, concerns, opinions? -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbowes at redhat.com Thu Aug 9 12:20:55 2012 From: jbowes at redhat.com (James Bowes) Date: Thu, 9 Aug 2012 09:20:55 -0300 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023A061.40507@redhat.com> References: <5023A061.40507@redhat.com> Message-ID: <20120809122055.GH46364@pipboy.redhat.com> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: > Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for > description of an issue with environment renaming. > > The immediate problems around environments: using of environment > names and environment ids for identification of environments > interchangeably. Using db ids for environment identification when > not using environment names. > > To resolve these: > - introduce environment uuids > - update katello/katello cli to use uuids for environment identification > - update repository naming to use environment uuids > - update candlepin (this will include updates to schema, and > resource controller) > -1 to UUIDs, for the same reason as has been discussed wrt pulp repo labels. a url like: https://my-cdn.local/content/dev/rhel-server/i386/ is way more useful than: https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ not to mention, far more handsome! I'd rather see either immutable labels, or supporting renaming labels, too. To clarify, UUIDs are fine imo as an internal canonical id for envs within katello as a whole, but once the env is exposed on the cli or in a url, label should be used. > > The larger problem: Katello and Candlepin modelling of > products/product content/environments lost coherency. > > Candlepin's view of the above trifecta (use of a monospaced font is > encouraged for the content below): > +-------------+ +--------------------+ > | Environment | 1 <--- * | EnvironmentContent | > +-------------+ +--------------------+ > ^ > | * > | 1 > +---------+ +----------------+ > | Product | 1 ---> * | ProductContent | > +---------+ +----------------+ > > > same thing in Katello (with added pulp repositories): > > +-------------+ > | Pulp::Repos |<-----------------------+ > +-------------+ | > ^ | > | uses | > +----------------------------------+ | +-------------+ > | Candlepin::Product | | | Environment | > | (uses Candlepin::ProductContent) | | +-------------+ > +----------------------------------+ | ^ > | ^ | | 1 > |uses | uses | | > | | | | * > +---------+ +--------------------+ > | Product | 1 ---------------> * | EnvironmentProduct | > +---------+ +--------------------+ > | |1 > | |* > | V > | uses +------------+ > +------| Repository | > +------------+ > > > I propose: > - Rename EnvironmentProduct to ProductContent > - make it use Candlepin::ProductContent > - remove use of Pulp::Repos from Product > - delegate responsibility of generation of environment uuids to > Candlepin (should cp folks agree on this) > > resulting in: > > +-------------+ > | Environment | > +-------------+ > ^ > | 1 > | * > +---------+ +----------------+ > | Product | 1 ---> * | ProductContent | > +---------+ +----------------+ > |1 | uses > | | +---------------------------+ > |1 +-> | Candlepin::ProductContent | > V +---------------------------+ > +-------------+ uses +------------+ > | Pulp::Repos |<-----| Repository | > +-------------+ +------------+ > > I don't think many-1 relation is required on > Repository-ProductContent, it's 1-1? > > > Thoughts, concerns, opinions? > -d > > > > > _______________________________________________ > 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 dmitri at redhat.com Thu Aug 9 12:39:56 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 13:39:56 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <20120809122055.GH46364@pipboy.redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> Message-ID: <5023AF9C.3030400@redhat.com> On 09/08/12 01:20 PM, James Bowes wrote: > On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >> description of an issue with environment renaming. >> >> The immediate problems around environments: using of environment >> names and environment ids for identification of environments >> interchangeably. Using db ids for environment identification when >> not using environment names. >> >> To resolve these: >> - introduce environment uuids >> - update katello/katello cli to use uuids for environment identification >> - update repository naming to use environment uuids >> - update candlepin (this will include updates to schema, and >> resource controller) >> > -1 to UUIDs, for the same reason as has been discussed wrt pulp > repo labels. a url like: > > https://my-cdn.local/content/dev/rhel-server/i386/ > > is way more useful than: > > https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ > > not to mention, far more handsome! > > I'd rather see either immutable labels, or supporting renaming labels, > too. The issue boils down to renaming of environments. If we are to use environment names for environment identification, we have to provide resolution for urls that are no longer valid (via 301). Doable, but additional work. The idea of labels is interesting, but I don't think it would work out in the long-term: it would become stale after a rename or two With uuid's we won't need to support url redirection, they won't go stale. For user-friendliness we should provide querying by name with environment resource, smt. like: GET http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper Less convenient, but easier to implement and maintain (from both user and developer perspective). -d > > To clarify, UUIDs are fine imo as an internal canonical id for envs > within katello as a whole, but once the env is exposed on the cli or in > a url, label should be used. > >> The larger problem: Katello and Candlepin modelling of >> products/product content/environments lost coherency. >> >> Candlepin's view of the above trifecta (use of a monospaced font is >> encouraged for the content below): >> +-------------+ +--------------------+ >> | Environment | 1 <--- * | EnvironmentContent | >> +-------------+ +--------------------+ >> ^ >> | * >> | 1 >> +---------+ +----------------+ >> | Product | 1 ---> * | ProductContent | >> +---------+ +----------------+ >> >> >> same thing in Katello (with added pulp repositories): >> >> +-------------+ >> | Pulp::Repos |<-----------------------+ >> +-------------+ | >> ^ | >> | uses | >> +----------------------------------+ | +-------------+ >> | Candlepin::Product | | | Environment | >> | (uses Candlepin::ProductContent) | | +-------------+ >> +----------------------------------+ | ^ >> | ^ | | 1 >> |uses | uses | | >> | | | | * >> +---------+ +--------------------+ >> | Product | 1 ---------------> * | EnvironmentProduct | >> +---------+ +--------------------+ >> | |1 >> | |* >> | V >> | uses +------------+ >> +------| Repository | >> +------------+ >> >> >> I propose: >> - Rename EnvironmentProduct to ProductContent >> - make it use Candlepin::ProductContent >> - remove use of Pulp::Repos from Product >> - delegate responsibility of generation of environment uuids to >> Candlepin (should cp folks agree on this) >> >> resulting in: >> >> +-------------+ >> | Environment | >> +-------------+ >> ^ >> | 1 >> | * >> +---------+ +----------------+ >> | Product | 1 ---> * | ProductContent | >> +---------+ +----------------+ >> |1 | uses >> | | +---------------------------+ >> |1 +-> | Candlepin::ProductContent | >> V +---------------------------+ >> +-------------+ uses +------------+ >> | Pulp::Repos |<-----| Repository | >> +-------------+ +------------+ >> >> I don't think many-1 relation is required on >> Repository-ProductContent, it's 1-1? >> >> >> Thoughts, concerns, opinions? >> -d >> >> >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > -James From jsherril at redhat.com Thu Aug 9 12:41:14 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 09 Aug 2012 08:41:14 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <20120809122055.GH46364@pipboy.redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> Message-ID: <5023AFEA.80300@redhat.com> On 08/09/2012 08:20 AM, James Bowes wrote: > On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >> description of an issue with environment renaming. >> >> The immediate problems around environments: using of environment >> names and environment ids for identification of environments >> interchangeably. Using db ids for environment identification when >> not using environment names. >> >> To resolve these: >> - introduce environment uuids >> - update katello/katello cli to use uuids for environment identification >> - update repository naming to use environment uuids >> - update candlepin (this will include updates to schema, and >> resource controller) >> > -1 to UUIDs, for the same reason as has been discussed wrt pulp > repo labels. a url like: -1 for me too. Much prefer labels. > > https://my-cdn.local/content/dev/rhel-server/i386/ > > is way more useful than: > > https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ > > not to mention, far more handsome! > > I'd rather see either immutable labels, or supporting renaming labels, > too. > > To clarify, UUIDs are fine imo as an internal canonical id for envs > within katello as a whole, but once the env is exposed on the cli or in > a url, label should be used. > >> The larger problem: Katello and Candlepin modelling of >> products/product content/environments lost coherency. >> >> Candlepin's view of the above trifecta (use of a monospaced font is >> encouraged for the content below): >> +-------------+ +--------------------+ >> | Environment | 1<--- * | EnvironmentContent | >> +-------------+ +--------------------+ >> ^ >> | * >> | 1 >> +---------+ +----------------+ >> | Product | 1 ---> * | ProductContent | >> +---------+ +----------------+ >> >> >> same thing in Katello (with added pulp repositories): >> >> +-------------+ >> | Pulp::Repos |<-----------------------+ >> +-------------+ | >> ^ | >> | uses | >> +----------------------------------+ | +-------------+ >> | Candlepin::Product | | | Environment | >> | (uses Candlepin::ProductContent) | | +-------------+ >> +----------------------------------+ | ^ >> | ^ | | 1 >> |uses | uses | | >> | | | | * >> +---------+ +--------------------+ >> | Product | 1 ---------------> * | EnvironmentProduct | >> +---------+ +--------------------+ >> | |1 >> | |* >> | V >> | uses +------------+ >> +------| Repository | >> +------------+ >> >> >> I propose: >> - Rename EnvironmentProduct to ProductContent >> - make it use Candlepin::ProductContent >> - remove use of Pulp::Repos from Product >> - delegate responsibility of generation of environment uuids to >> Candlepin (should cp folks agree on this) >> >> resulting in: >> >> +-------------+ >> | Environment | >> +-------------+ >> ^ >> | 1 >> | * >> +---------+ +----------------+ >> | Product | 1 ---> * | ProductContent | >> +---------+ +----------------+ >> |1 | uses >> | | +---------------------------+ >> |1 +-> | Candlepin::ProductContent | >> V +---------------------------+ >> +-------------+ uses +------------+ >> | Pulp::Repos |<-----| Repository | >> +-------------+ +------------+ >> >> I don't think many-1 relation is required on >> Repository-ProductContent, it's 1-1? Repository-ProductContent is not 1-1. For example there is a singe content object for RHEL 6.1 i386 RPMs as for RHEL 6.2 x86_64 RPMS. WIthin the RHEL product its many-to-one for sure. For custom repositories currently its 1-1. -Justin >> >> Thoughts, concerns, opinions? >> -d >> >> >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitri at redhat.com Thu Aug 9 12:42:44 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 13:42:44 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023AF9C.3030400@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> Message-ID: <5023B044.4010600@redhat.com> On 09/08/12 01:39 PM, Dmitri Dolguikh wrote: > On 09/08/12 01:20 PM, James Bowes wrote: >> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>> description of an issue with environment renaming. >>> >>> The immediate problems around environments: using of environment >>> names and environment ids for identification of environments >>> interchangeably. Using db ids for environment identification when >>> not using environment names. >>> >>> To resolve these: >>> - introduce environment uuids >>> - update katello/katello cli to use uuids for environment >>> identification >>> - update repository naming to use environment uuids >>> - update candlepin (this will include updates to schema, and >>> resource controller) >>> >> -1 to UUIDs, for the same reason as has been discussed wrt pulp >> repo labels. a url like: >> >> https://my-cdn.local/content/dev/rhel-server/i386/ >> >> is way more useful than: >> >> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >> >> not to mention, far more handsome! >> >> I'd rather see either immutable labels, or supporting renaming labels, >> too. > The issue boils down to renaming of environments. If we are to use > environment names for environment identification, we have to provide > resolution for urls that are no longer valid (via 301). Doable, but > additional work. Additional work would include support for 301 responses on clients too. -d > > The idea of labels is interesting, but I don't think it would work out > in the long-term: it would become stale after a rename or two > > With uuid's we won't need to support url redirection, they won't go > stale. For user-friendliness we should provide querying by name with > environment resource, smt. like: > > GET > http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper > > Less convenient, but easier to implement and maintain (from both user > and developer perspective). > > -d > >> >> To clarify, UUIDs are fine imo as an internal canonical id for envs >> within katello as a whole, but once the env is exposed on the cli or in >> a url, label should be used. >> >>> The larger problem: Katello and Candlepin modelling of >>> products/product content/environments lost coherency. >>> >>> Candlepin's view of the above trifecta (use of a monospaced font is >>> encouraged for the content below): >>> +-------------+ +--------------------+ >>> | Environment | 1 <--- * | EnvironmentContent | >>> +-------------+ +--------------------+ >>> ^ >>> | * >>> | 1 >>> +---------+ +----------------+ >>> | Product | 1 ---> * | ProductContent | >>> +---------+ +----------------+ >>> >>> >>> same thing in Katello (with added pulp repositories): >>> >>> +-------------+ >>> | Pulp::Repos |<-----------------------+ >>> +-------------+ | >>> ^ | >>> | uses | >>> +----------------------------------+ | +-------------+ >>> | Candlepin::Product | | | Environment | >>> | (uses Candlepin::ProductContent) | | +-------------+ >>> +----------------------------------+ | ^ >>> | ^ | | 1 >>> |uses | uses | | >>> | | | | * >>> +---------+ +--------------------+ >>> | Product | 1 ---------------> * | EnvironmentProduct | >>> +---------+ +--------------------+ >>> | |1 >>> | |* >>> | V >>> | uses +------------+ >>> +------| Repository | >>> +------------+ >>> >>> >>> I propose: >>> - Rename EnvironmentProduct to ProductContent >>> - make it use Candlepin::ProductContent >>> - remove use of Pulp::Repos from Product >>> - delegate responsibility of generation of environment uuids to >>> Candlepin (should cp folks agree on this) >>> >>> resulting in: >>> >>> +-------------+ >>> | Environment | >>> +-------------+ >>> ^ >>> | 1 >>> | * >>> +---------+ +----------------+ >>> | Product | 1 ---> * | ProductContent | >>> +---------+ +----------------+ >>> |1 | uses >>> | | +---------------------------+ >>> |1 +-> | Candlepin::ProductContent | >>> V +---------------------------+ >>> +-------------+ uses +------------+ >>> | Pulp::Repos |<-----| Repository | >>> +-------------+ +------------+ >>> >>> I don't think many-1 relation is required on >>> Repository-ProductContent, it's 1-1? >>> >>> >>> Thoughts, concerns, opinions? >>> -d >>> >>> >>> >>> >>> _______________________________________________ >>> 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 From jsherril at redhat.com Thu Aug 9 12:49:22 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 09 Aug 2012 08:49:22 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023AF9C.3030400@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> Message-ID: <5023B1D2.1010105@redhat.com> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: > On 09/08/12 01:20 PM, James Bowes wrote: >> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>> description of an issue with environment renaming. >>> >>> The immediate problems around environments: using of environment >>> names and environment ids for identification of environments >>> interchangeably. Using db ids for environment identification when >>> not using environment names. >>> >>> To resolve these: >>> - introduce environment uuids >>> - update katello/katello cli to use uuids for environment >>> identification >>> - update repository naming to use environment uuids >>> - update candlepin (this will include updates to schema, and >>> resource controller) >>> >> -1 to UUIDs, for the same reason as has been discussed wrt pulp >> repo labels. a url like: >> >> https://my-cdn.local/content/dev/rhel-server/i386/ >> >> is way more useful than: >> >> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >> >> not to mention, far more handsome! >> >> I'd rather see either immutable labels, or supporting renaming labels, >> too. > The issue boils down to renaming of environments. If we are to use > environment names for environment identification, we have to provide > resolution for urls that are no longer valid (via 301). Doable, but > additional work. > > The idea of labels is interesting, but I don't think it would work out > in the long-term: it would become stale after a rename or two > I would agree with you, except for the fact that in Satellite many different objects used the idea of a mutable name and an immutable label (especially for repos). I don't know that I once heard a complaint from a customer that they couldn't rename a label or that it was stale. Do you have any thoughts cliff? -Justin > With uuid's we won't need to support url redirection, they won't go > stale. For user-friendliness we should provide querying by name with > environment resource, smt. like: > > GET > http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper > > Less convenient, but easier to implement and maintain (from both user > and developer perspective). > > -d > >> >> To clarify, UUIDs are fine imo as an internal canonical id for envs >> within katello as a whole, but once the env is exposed on the cli or in >> a url, label should be used. >> >>> The larger problem: Katello and Candlepin modelling of >>> products/product content/environments lost coherency. >>> >>> Candlepin's view of the above trifecta (use of a monospaced font is >>> encouraged for the content below): >>> +-------------+ +--------------------+ >>> | Environment | 1 <--- * | EnvironmentContent | >>> +-------------+ +--------------------+ >>> ^ >>> | * >>> | 1 >>> +---------+ +----------------+ >>> | Product | 1 ---> * | ProductContent | >>> +---------+ +----------------+ >>> >>> >>> same thing in Katello (with added pulp repositories): >>> >>> +-------------+ >>> | Pulp::Repos |<-----------------------+ >>> +-------------+ | >>> ^ | >>> | uses | >>> +----------------------------------+ | +-------------+ >>> | Candlepin::Product | | | Environment | >>> | (uses Candlepin::ProductContent) | | +-------------+ >>> +----------------------------------+ | ^ >>> | ^ | | 1 >>> |uses | uses | | >>> | | | | * >>> +---------+ +--------------------+ >>> | Product | 1 ---------------> * | EnvironmentProduct | >>> +---------+ +--------------------+ >>> | |1 >>> | |* >>> | V >>> | uses +------------+ >>> +------| Repository | >>> +------------+ >>> >>> >>> I propose: >>> - Rename EnvironmentProduct to ProductContent >>> - make it use Candlepin::ProductContent >>> - remove use of Pulp::Repos from Product >>> - delegate responsibility of generation of environment uuids to >>> Candlepin (should cp folks agree on this) >>> >>> resulting in: >>> >>> +-------------+ >>> | Environment | >>> +-------------+ >>> ^ >>> | 1 >>> | * >>> +---------+ +----------------+ >>> | Product | 1 ---> * | ProductContent | >>> +---------+ +----------------+ >>> |1 | uses >>> | | +---------------------------+ >>> |1 +-> | Candlepin::ProductContent | >>> V +---------------------------+ >>> +-------------+ uses +------------+ >>> | Pulp::Repos |<-----| Repository | >>> +-------------+ +------------+ >>> >>> I don't think many-1 relation is required on >>> Repository-ProductContent, it's 1-1? >>> >>> >>> Thoughts, concerns, opinions? >>> -d >>> >>> >>> >>> >>> _______________________________________________ >>> 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 From dmitri at redhat.com Thu Aug 9 13:08:50 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 14:08:50 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023B1D2.1010105@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> Message-ID: <5023B662.30105@redhat.com> On 09/08/12 01:49 PM, Justin Sherrill wrote: > On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >> On 09/08/12 01:20 PM, James Bowes wrote: >>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>> description of an issue with environment renaming. >>>> >>>> The immediate problems around environments: using of environment >>>> names and environment ids for identification of environments >>>> interchangeably. Using db ids for environment identification when >>>> not using environment names. >>>> >>>> To resolve these: >>>> - introduce environment uuids >>>> - update katello/katello cli to use uuids for environment >>>> identification >>>> - update repository naming to use environment uuids >>>> - update candlepin (this will include updates to schema, and >>>> resource controller) >>>> >>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>> repo labels. a url like: >>> >>> https://my-cdn.local/content/dev/rhel-server/i386/ >>> >>> is way more useful than: >>> >>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>> >>> >>> not to mention, far more handsome! >>> >>> I'd rather see either immutable labels, or supporting renaming labels, >>> too. >> The issue boils down to renaming of environments. If we are to use >> environment names for environment identification, we have to provide >> resolution for urls that are no longer valid (via 301). Doable, but >> additional work. >> >> The idea of labels is interesting, but I don't think it would work >> out in the long-term: it would become stale after a rename or two >> > I would agree with you, except for the fact that in Satellite many > different objects used the idea of a mutable name and an immutable > label (especially for repos). I don't know that I once heard a > complaint from a customer that they couldn't rename a label or that it > was stale. > I just don't think it's possible to communicate the intent using a short (for the benefit of usability) label, so that the label would stay constant while environment name kept changing. Perhaps renaming of environments is overrated? -d > Do you have any thoughts cliff? > > -Justin > > >> With uuid's we won't need to support url redirection, they won't go >> stale. For user-friendliness we should provide querying by name with >> environment resource, smt. like: >> >> GET >> http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper >> >> Less convenient, but easier to implement and maintain (from both user >> and developer perspective). >> >> -d >> >>> >>> To clarify, UUIDs are fine imo as an internal canonical id for envs >>> within katello as a whole, but once the env is exposed on the cli or in >>> a url, label should be used. >>> >>>> The larger problem: Katello and Candlepin modelling of >>>> products/product content/environments lost coherency. >>>> >>>> Candlepin's view of the above trifecta (use of a monospaced font is >>>> encouraged for the content below): >>>> +-------------+ +--------------------+ >>>> | Environment | 1 <--- * | EnvironmentContent | >>>> +-------------+ +--------------------+ >>>> ^ >>>> | * >>>> | 1 >>>> +---------+ +----------------+ >>>> | Product | 1 ---> * | ProductContent | >>>> +---------+ +----------------+ >>>> >>>> >>>> same thing in Katello (with added pulp repositories): >>>> >>>> +-------------+ >>>> | Pulp::Repos |<-----------------------+ >>>> +-------------+ | >>>> ^ | >>>> | uses | >>>> +----------------------------------+ | +-------------+ >>>> | Candlepin::Product | | | Environment | >>>> | (uses Candlepin::ProductContent) | | +-------------+ >>>> +----------------------------------+ | ^ >>>> | ^ | | 1 >>>> |uses | uses | | >>>> | | | | * >>>> +---------+ +--------------------+ >>>> | Product | 1 ---------------> * | EnvironmentProduct | >>>> +---------+ +--------------------+ >>>> | |1 >>>> | |* >>>> | V >>>> | uses +------------+ >>>> +------| Repository | >>>> +------------+ >>>> >>>> >>>> I propose: >>>> - Rename EnvironmentProduct to ProductContent >>>> - make it use Candlepin::ProductContent >>>> - remove use of Pulp::Repos from Product >>>> - delegate responsibility of generation of environment uuids to >>>> Candlepin (should cp folks agree on this) >>>> >>>> resulting in: >>>> >>>> +-------------+ >>>> | Environment | >>>> +-------------+ >>>> ^ >>>> | 1 >>>> | * >>>> +---------+ +----------------+ >>>> | Product | 1 ---> * | ProductContent | >>>> +---------+ +----------------+ >>>> |1 | uses >>>> | | +---------------------------+ >>>> |1 +-> | Candlepin::ProductContent | >>>> V +---------------------------+ >>>> +-------------+ uses +------------+ >>>> | Pulp::Repos |<-----| Repository | >>>> +-------------+ +------------+ >>>> >>>> I don't think many-1 relation is required on >>>> Repository-ProductContent, it's 1-1? >>>> >>>> >>>> Thoughts, concerns, opinions? >>>> -d >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jsherril at redhat.com Thu Aug 9 13:11:32 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 09 Aug 2012 09:11:32 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023B662.30105@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> Message-ID: <5023B704.6070602@redhat.com> On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote: > On 09/08/12 01:49 PM, Justin Sherrill wrote: >> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >>> On 09/08/12 01:20 PM, James Bowes wrote: >>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>> description of an issue with environment renaming. >>>>> >>>>> The immediate problems around environments: using of environment >>>>> names and environment ids for identification of environments >>>>> interchangeably. Using db ids for environment identification when >>>>> not using environment names. >>>>> >>>>> To resolve these: >>>>> - introduce environment uuids >>>>> - update katello/katello cli to use uuids for environment >>>>> identification >>>>> - update repository naming to use environment uuids >>>>> - update candlepin (this will include updates to schema, and >>>>> resource controller) >>>>> >>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>>> repo labels. a url like: >>>> >>>> https://my-cdn.local/content/dev/rhel-server/i386/ >>>> >>>> is way more useful than: >>>> >>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>>> >>>> >>>> not to mention, far more handsome! >>>> >>>> I'd rather see either immutable labels, or supporting renaming labels, >>>> too. >>> The issue boils down to renaming of environments. If we are to use >>> environment names for environment identification, we have to provide >>> resolution for urls that are no longer valid (via 301). Doable, but >>> additional work. >>> >>> The idea of labels is interesting, but I don't think it would work >>> out in the long-term: it would become stale after a rename or two >>> >> I would agree with you, except for the fact that in Satellite many >> different objects used the idea of a mutable name and an immutable >> label (especially for repos). I don't know that I once heard a >> complaint from a customer that they couldn't rename a label or that >> it was stale. >> > I just don't think it's possible to communicate the intent using a > short (for the benefit of usability) label, so that the label would > stay constant while environment name kept changing. > > Perhaps renaming of environments is overrated? > -d I don't think its overrated, and regardless i feel that we need to be able to rename repositories as well (where you'd hit the same issue). It does seem odd, but it worked really well in satellite :) -Justin > > >> Do you have any thoughts cliff? >> >> -Justin >> >> >>> With uuid's we won't need to support url redirection, they won't go >>> stale. For user-friendliness we should provide querying by name with >>> environment resource, smt. like: >>> >>> GET >>> http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper >>> >>> Less convenient, but easier to implement and maintain (from both >>> user and developer perspective). >>> >>> -d >>> >>>> >>>> To clarify, UUIDs are fine imo as an internal canonical id for envs >>>> within katello as a whole, but once the env is exposed on the cli >>>> or in >>>> a url, label should be used. >>>> >>>>> The larger problem: Katello and Candlepin modelling of >>>>> products/product content/environments lost coherency. >>>>> >>>>> Candlepin's view of the above trifecta (use of a monospaced font is >>>>> encouraged for the content below): >>>>> +-------------+ +--------------------+ >>>>> | Environment | 1 <--- * | EnvironmentContent | >>>>> +-------------+ +--------------------+ >>>>> ^ >>>>> | * >>>>> | 1 >>>>> +---------+ +----------------+ >>>>> | Product | 1 ---> * | ProductContent | >>>>> +---------+ +----------------+ >>>>> >>>>> >>>>> same thing in Katello (with added pulp repositories): >>>>> >>>>> +-------------+ >>>>> | Pulp::Repos |<-----------------------+ >>>>> +-------------+ | >>>>> ^ | >>>>> | uses | >>>>> +----------------------------------+ | +-------------+ >>>>> | Candlepin::Product | | | Environment | >>>>> | (uses Candlepin::ProductContent) | | +-------------+ >>>>> +----------------------------------+ | ^ >>>>> | ^ | | 1 >>>>> |uses | uses | | >>>>> | | | | * >>>>> +---------+ +--------------------+ >>>>> | Product | 1 ---------------> * | EnvironmentProduct | >>>>> +---------+ +--------------------+ >>>>> | |1 >>>>> | |* >>>>> | V >>>>> | uses +------------+ >>>>> +------| Repository | >>>>> +------------+ >>>>> >>>>> >>>>> I propose: >>>>> - Rename EnvironmentProduct to ProductContent >>>>> - make it use Candlepin::ProductContent >>>>> - remove use of Pulp::Repos from Product >>>>> - delegate responsibility of generation of environment uuids to >>>>> Candlepin (should cp folks agree on this) >>>>> >>>>> resulting in: >>>>> >>>>> +-------------+ >>>>> | Environment | >>>>> +-------------+ >>>>> ^ >>>>> | 1 >>>>> | * >>>>> +---------+ +----------------+ >>>>> | Product | 1 ---> * | ProductContent | >>>>> +---------+ +----------------+ >>>>> |1 | uses >>>>> | | +---------------------------+ >>>>> |1 +-> | Candlepin::ProductContent | >>>>> V +---------------------------+ >>>>> +-------------+ uses +------------+ >>>>> | Pulp::Repos |<-----| Repository | >>>>> +-------------+ +------------+ >>>>> >>>>> I don't think many-1 relation is required on >>>>> Repository-ProductContent, it's 1-1? >>>>> >>>>> >>>>> Thoughts, concerns, opinions? >>>>> -d >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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 Thu Aug 9 13:23:29 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 14:23:29 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023B704.6070602@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> <5023B704.6070602@redhat.com> Message-ID: <5023B9D1.6070207@redhat.com> On 09/08/12 02:11 PM, Justin Sherrill wrote: > On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote: >> On 09/08/12 01:49 PM, Justin Sherrill wrote: >>> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >>>> On 09/08/12 01:20 PM, James Bowes wrote: >>>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>> description of an issue with environment renaming. >>>>>> >>>>>> The immediate problems around environments: using of environment >>>>>> names and environment ids for identification of environments >>>>>> interchangeably. Using db ids for environment identification when >>>>>> not using environment names. >>>>>> >>>>>> To resolve these: >>>>>> - introduce environment uuids >>>>>> - update katello/katello cli to use uuids for environment >>>>>> identification >>>>>> - update repository naming to use environment uuids >>>>>> - update candlepin (this will include updates to schema, and >>>>>> resource controller) >>>>>> >>>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>>>> repo labels. a url like: >>>>> >>>>> https://my-cdn.local/content/dev/rhel-server/i386/ >>>>> >>>>> is way more useful than: >>>>> >>>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>>>> >>>>> >>>>> not to mention, far more handsome! >>>>> >>>>> I'd rather see either immutable labels, or supporting renaming >>>>> labels, >>>>> too. >>>> The issue boils down to renaming of environments. If we are to use >>>> environment names for environment identification, we have to >>>> provide resolution for urls that are no longer valid (via 301). >>>> Doable, but additional work. >>>> >>>> The idea of labels is interesting, but I don't think it would work >>>> out in the long-term: it would become stale after a rename or two >>>> >>> I would agree with you, except for the fact that in Satellite many >>> different objects used the idea of a mutable name and an immutable >>> label (especially for repos). I don't know that I once heard a >>> complaint from a customer that they couldn't rename a label or that >>> it was stale. >>> >> I just don't think it's possible to communicate the intent using a >> short (for the benefit of usability) label, so that the label would >> stay constant while environment name kept changing. >> >> Perhaps renaming of environments is overrated? >> -d > > I don't think its overrated, and regardless i feel that we need to be > able to rename repositories as well (where you'd hit the same issue). > It does seem odd, but it worked really well in satellite :) I suspect that renaming doesn't happen all that often in the lifetime of a given named resource. While I certainly agree that it's useful and nice to have human-readable urls, it's not always attainable. The benefits are further reduced by: - realizing that the main consumer of those urls is some piece of code. - discoverability (not something we have atm, but something we should be striving for in our REST api) more than compensates for obtuse urls. -d > > -Justin > >> >> >>> Do you have any thoughts cliff? >>> >>> -Justin >>> >>> >>>> With uuid's we won't need to support url redirection, they won't go >>>> stale. For user-friendliness we should provide querying by name >>>> with environment resource, smt. like: >>>> >>>> GET >>>> http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper >>>> >>>> Less convenient, but easier to implement and maintain (from both >>>> user and developer perspective). >>>> >>>> -d >>>> >>>>> >>>>> To clarify, UUIDs are fine imo as an internal canonical id for envs >>>>> within katello as a whole, but once the env is exposed on the cli >>>>> or in >>>>> a url, label should be used. >>>>> >>>>>> The larger problem: Katello and Candlepin modelling of >>>>>> products/product content/environments lost coherency. >>>>>> >>>>>> Candlepin's view of the above trifecta (use of a monospaced font is >>>>>> encouraged for the content below): >>>>>> +-------------+ +--------------------+ >>>>>> | Environment | 1 <--- * | EnvironmentContent | >>>>>> +-------------+ +--------------------+ >>>>>> ^ >>>>>> | * >>>>>> | 1 >>>>>> +---------+ +----------------+ >>>>>> | Product | 1 ---> * | ProductContent | >>>>>> +---------+ +----------------+ >>>>>> >>>>>> >>>>>> same thing in Katello (with added pulp repositories): >>>>>> >>>>>> +-------------+ >>>>>> | Pulp::Repos |<-----------------------+ >>>>>> +-------------+ | >>>>>> ^ | >>>>>> | uses | >>>>>> +----------------------------------+ | +-------------+ >>>>>> | Candlepin::Product | | | Environment | >>>>>> | (uses Candlepin::ProductContent) | | +-------------+ >>>>>> +----------------------------------+ | ^ >>>>>> | ^ | | 1 >>>>>> |uses | uses | | >>>>>> | | | | * >>>>>> +---------+ +--------------------+ >>>>>> | Product | 1 ---------------> * | EnvironmentProduct | >>>>>> +---------+ +--------------------+ >>>>>> | |1 >>>>>> | |* >>>>>> | V >>>>>> | uses +------------+ >>>>>> +------| Repository | >>>>>> +------------+ >>>>>> >>>>>> >>>>>> I propose: >>>>>> - Rename EnvironmentProduct to ProductContent >>>>>> - make it use Candlepin::ProductContent >>>>>> - remove use of Pulp::Repos from Product >>>>>> - delegate responsibility of generation of environment uuids to >>>>>> Candlepin (should cp folks agree on this) >>>>>> >>>>>> resulting in: >>>>>> >>>>>> +-------------+ >>>>>> | Environment | >>>>>> +-------------+ >>>>>> ^ >>>>>> | 1 >>>>>> | * >>>>>> +---------+ +----------------+ >>>>>> | Product | 1 ---> * | ProductContent | >>>>>> +---------+ +----------------+ >>>>>> |1 | uses >>>>>> | | +---------------------------+ >>>>>> |1 +-> | Candlepin::ProductContent | >>>>>> V +---------------------------+ >>>>>> +-------------+ uses +------------+ >>>>>> | Pulp::Repos |<-----| Repository | >>>>>> +-------------+ +------------+ >>>>>> >>>>>> I don't think many-1 relation is required on >>>>>> Repository-ProductContent, it's 1-1? >>>>>> >>>>>> >>>>>> Thoughts, concerns, opinions? >>>>>> -d >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> _______________________________________________ >>> 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 jesusr at redhat.com Thu Aug 9 14:04:35 2012 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 09 Aug 2012 10:04:35 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <20120809122055.GH46364@pipboy.redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> Message-ID: <5023C373.3080606@redhat.com> On 08/09/2012 08:20 AM, James Bowes wrote: > On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >> description of an issue with environment renaming. >> >> The immediate problems around environments: using of environment >> names and environment ids for identification of environments >> interchangeably. Using db ids for environment identification when >> not using environment names. >> >> To resolve these: >> - introduce environment uuids >> - update katello/katello cli to use uuids for environment identification >> - update repository naming to use environment uuids >> - update candlepin (this will include updates to schema, and >> resource controller) >> > > -1 to UUIDs, for the same reason as has been discussed wrt pulp > repo labels. a url like: > > https://my-cdn.local/content/dev/rhel-server/i386/ > > is way more useful than: > > https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ > > not to mention, far more handsome! > > I'd rather see either immutable labels, or supporting renaming labels, > too. > > To clarify, UUIDs are fine imo as an internal canonical id for envs > within katello as a whole, but once the env is exposed on the cli or in > a url, label should be used. +1000 to labels -1000 to using the UUID jesus [snip] -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ From dmitri at redhat.com Thu Aug 9 14:13:21 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 15:13:21 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023C373.3080606@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023C373.3080606@redhat.com> Message-ID: <5023C581.7080307@redhat.com> On 09/08/12 03:04 PM, jesus m. rodriguez wrote: > On 08/09/2012 08:20 AM, James Bowes wrote: >> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>> description of an issue with environment renaming. >>> >>> The immediate problems around environments: using of environment >>> names and environment ids for identification of environments >>> interchangeably. Using db ids for environment identification when >>> not using environment names. >>> >>> To resolve these: >>> - introduce environment uuids >>> - update katello/katello cli to use uuids for environment >>> identification >>> - update repository naming to use environment uuids >>> - update candlepin (this will include updates to schema, and >>> resource controller) >>> >> >> -1 to UUIDs, for the same reason as has been discussed wrt pulp >> repo labels. a url like: >> >> https://my-cdn.local/content/dev/rhel-server/i386/ >> >> is way more useful than: >> >> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >> >> not to mention, far more handsome! >> >> I'd rather see either immutable labels, or supporting renaming labels, >> too. >> >> To clarify, UUIDs are fine imo as an internal canonical id for envs >> within katello as a whole, but once the env is exposed on the cli or in >> a url, label should be used. > > +1000 to labels > -1000 to using the UUID Label comment has been used several times already, without explaining how it helps to resolve the naming issue. -d > > jesus > > [snip] > From jesusr at redhat.com Thu Aug 9 14:37:20 2012 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 09 Aug 2012 10:37:20 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023AF9C.3030400@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> Message-ID: <5023CB20.1050300@redhat.com> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: > On 09/08/12 01:20 PM, James Bowes wrote: >> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>> description of an issue with environment renaming. >>> >>> The immediate problems around environments: using of environment >>> names and environment ids for identification of environments >>> interchangeably. Using db ids for environment identification when >>> not using environment names. >>> >>> To resolve these: >>> - introduce environment uuids >>> - update katello/katello cli to use uuids for environment identification >>> - update repository naming to use environment uuids >>> - update candlepin (this will include updates to schema, and >>> resource controller) >>> >> -1 to UUIDs, for the same reason as has been discussed wrt pulp >> repo labels. a url like: >> >> https://my-cdn.local/content/dev/rhel-server/i386/ >> >> is way more useful than: >> >> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >> >> not to mention, far more handsome! >> >> I'd rather see either immutable labels, or supporting renaming labels, >> too. > The issue boils down to renaming of environments. If we are to use > environment names for environment identification, we have to provide > resolution for urls that are no longer valid (via 301). Doable, but > additional work. Labels are not necessarily environment names. Nothing says you have to allow changing of the label. The label is just a human readable identifier that is both easy to remember and use. While allowing renaming of labels is nice, I don't think it is necessary. Even if you allow renaming the environment (the one shown on the page). Think of the trac wiki url. If I create a new page I can call it DesignLabelsEnvironments. But change the title on the page to be 'Design of Labels for Environments'. Later I change the title to be: 'Environment Label Design'. I don't have to change the page name. If I want to I just create a new one. So if you want to allow label renaming, then make it easy to create Environments. > The idea of labels is interesting, but I don't think it would work out > in the long-term: it would become stale after a rename or two The labels is what we used for RHN Satellite for Channels. It works and a lot easier to remember. I can guarantee if you go with UUID you *WILL* get someone asking why can't they pass in a name. And using the actual name is bad because they will have spaces and might have to be translated. Labels are again human readable. > > With uuid's we won't need to support url redirection, they won't go > stale. For user-friendliness we should provide querying by name with > environment resource, smt. like: Nothing says you have to offer redirection with labels. If you make them static and force users to create a new environment to get a new label. So let's walk through the label rename then. You let a user change the label of an environment. So now instead of being 'int-dev' it becomes 'devel'. You could simply return 404 for anyone still using 'int-dev' just like they were if they used the wrong uuid. If you *MUST* offer 301 'moved permanently' for the label then you'll have to keep a list of labels. But I think that's going to be more of a user issue. Because I know people will want to reuse label names later. So I think most of them will be ok if you have a 404 for a non existent label. IMO I don't think you need to offer label renames. Just allow renaming of the environment for displaying on the UI. That way your urls are easier to use, cli will be easier to use, and you'll get less complaints. > > GET > http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper > > Less convenient, but easier to implement and maintain (from both user > and developer perspective). I don't understand what your example is about. name should never be used, it should be label: ../ACME_Corporation/environments?label=super-duper jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ From jbowes at redhat.com Thu Aug 9 14:49:07 2012 From: jbowes at redhat.com (James Bowes) Date: Thu, 9 Aug 2012 11:49:07 -0300 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023AF9C.3030400@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> Message-ID: <20120809144906.GM46364@pipboy.redhat.com> On Thu, Aug 09, 2012 at 01:39:56PM +0100, Dmitri Dolguikh wrote: > On 09/08/12 01:20 PM, James Bowes wrote: > >On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: > >>Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for > >>description of an issue with environment renaming. > >> > >>The immediate problems around environments: using of environment > >>names and environment ids for identification of environments > >>interchangeably. Using db ids for environment identification when > >>not using environment names. > >> > >>To resolve these: > >> - introduce environment uuids > >> - update katello/katello cli to use uuids for environment identification > >> - update repository naming to use environment uuids > >> - update candlepin (this will include updates to schema, and > >>resource controller) > >> > >-1 to UUIDs, for the same reason as has been discussed wrt pulp > >repo labels. a url like: > > > >https://my-cdn.local/content/dev/rhel-server/i386/ > > > >is way more useful than: > > > >https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ > > > >not to mention, far more handsome! > > > >I'd rather see either immutable labels, or supporting renaming labels, > >too. > The issue boils down to renaming of environments. If we are to use > environment names for environment identification, we have to provide > resolution for urls that are no longer valid (via 301). Doable, but > additional work. > label and name can be seperate. label could be my-env, name could be "My Environment". label is something that can be easily passed into a cli command, or put in a yum url for content downloads. name would just be something you view. I don't think it's necessary to support redirection. > The idea of labels is interesting, but I don't think it would work > out in the long-term: it would become stale after a rename or two > Unless you update the label at the same time. > With uuid's we won't need to support url redirection, they won't go > stale. For user-friendliness we should provide querying by name with > environment resource, smt. like: > > GET http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper > That's effectively the same as using the label directly in the path of the url, isn't it? > Less convenient, but easier to implement and maintain (from both > user and developer perspective). > > -d > > > > >To clarify, UUIDs are fine imo as an internal canonical id for envs > >within katello as a whole, but once the env is exposed on the cli or in > >a url, label should be used. > > > >>The larger problem: Katello and Candlepin modelling of > >>products/product content/environments lost coherency. > >> > >>Candlepin's view of the above trifecta (use of a monospaced font is > >>encouraged for the content below): > >>+-------------+ +--------------------+ > >>| Environment | 1 <--- * | EnvironmentContent | > >>+-------------+ +--------------------+ > >> ^ > >> | * > >> | 1 > >>+---------+ +----------------+ > >> | Product | 1 ---> * | ProductContent | > >> +---------+ +----------------+ > >> > >> > >>same thing in Katello (with added pulp repositories): > >> > >> +-------------+ > >> | Pulp::Repos |<-----------------------+ > >> +-------------+ | > >> ^ | > >> | uses | > >> +----------------------------------+ | +-------------+ > >> | Candlepin::Product | | | Environment | > >> | (uses Candlepin::ProductContent) | | +-------------+ > >> +----------------------------------+ | ^ > >> | ^ | | 1 > >> |uses | uses | | > >> | | | | * > >>+---------+ +--------------------+ > >> | Product | 1 ---------------> * | EnvironmentProduct | > >> +---------+ +--------------------+ > >> | |1 > >> | |* > >> | V > >> | uses +------------+ > >> +------| Repository | > >> +------------+ > >> > >> > >>I propose: > >> - Rename EnvironmentProduct to ProductContent > >> - make it use Candlepin::ProductContent > >> - remove use of Pulp::Repos from Product > >> - delegate responsibility of generation of environment uuids to > >>Candlepin (should cp folks agree on this) > >> > >>resulting in: > >> > >> +-------------+ > >> | Environment | > >> +-------------+ > >> ^ > >> | 1 > >> | * > >> +---------+ +----------------+ > >> | Product | 1 ---> * | ProductContent | > >> +---------+ +----------------+ > >> |1 | uses > >> | | +---------------------------+ > >> |1 +-> | Candlepin::ProductContent | > >> V +---------------------------+ > >> +-------------+ uses +------------+ > >> | Pulp::Repos |<-----| Repository | > >> +-------------+ +------------+ > >> > >>I don't think many-1 relation is required on > >>Repository-ProductContent, it's 1-1? > >> > >> > >>Thoughts, concerns, opinions? > >>-d > >> > >> > >> > >> > >>_______________________________________________ > >>katello-devel mailing list > >>katello-devel at redhat.com > >>https://www.redhat.com/mailman/listinfo/katello-devel > > > >-James > > -James -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jesusr at redhat.com Thu Aug 9 14:52:31 2012 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 09 Aug 2012 10:52:31 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023B9D1.6070207@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> <5023B704.6070602@redhat.com> <5023B9D1.6070207@redhat.com> Message-ID: <5023CEAF.6030701@redhat.com> On 08/09/2012 09:23 AM, Dmitri Dolguikh wrote: > On 09/08/12 02:11 PM, Justin Sherrill wrote: >> On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote: >>> On 09/08/12 01:49 PM, Justin Sherrill wrote: >>>> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >>>>> On 09/08/12 01:20 PM, James Bowes wrote: >>>>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>> description of an issue with environment renaming. >>>>>>> >>>>>>> The immediate problems around environments: using of environment >>>>>>> names and environment ids for identification of environments >>>>>>> interchangeably. Using db ids for environment identification when >>>>>>> not using environment names. >>>>>>> >>>>>>> To resolve these: >>>>>>> - introduce environment uuids >>>>>>> - update katello/katello cli to use uuids for environment >>>>>>> identification >>>>>>> - update repository naming to use environment uuids >>>>>>> - update candlepin (this will include updates to schema, and >>>>>>> resource controller) >>>>>>> >>>>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>>>>> repo labels. a url like: >>>>>> >>>>>> https://my-cdn.local/content/dev/rhel-server/i386/ >>>>>> >>>>>> is way more useful than: >>>>>> >>>>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>>>>> >>>>>> >>>>>> not to mention, far more handsome! >>>>>> >>>>>> I'd rather see either immutable labels, or supporting renaming >>>>>> labels, >>>>>> too. >>>>> The issue boils down to renaming of environments. If we are to use >>>>> environment names for environment identification, we have to >>>>> provide resolution for urls that are no longer valid (via 301). >>>>> Doable, but additional work. >>>>> >>>>> The idea of labels is interesting, but I don't think it would work >>>>> out in the long-term: it would become stale after a rename or two >>>>> >>>> I would agree with you, except for the fact that in Satellite many >>>> different objects used the idea of a mutable name and an immutable >>>> label (especially for repos). I don't know that I once heard a >>>> complaint from a customer that they couldn't rename a label or that >>>> it was stale. >>>> >>> I just don't think it's possible to communicate the intent using a >>> short (for the benefit of usability) label, so that the label would >>> stay constant while environment name kept changing. >>> >>> Perhaps renaming of environments is overrated? >>> -d >> >> I don't think its overrated, and regardless i feel that we need to be >> able to rename repositories as well (where you'd hit the same issue). >> It does seem odd, but it worked really well in satellite :) > I suspect that renaming doesn't happen all that often in the lifetime of > a given named resource. While I certainly agree that it's useful and > nice to have human-readable urls, it's not always attainable. The > benefits are further reduced by: > - realizing that the main consumer of those urls is some piece of code. I respectfully disagree. The main consumer will probably be a user NOT a piece of code. I don't see why label is such a horrible idea. What is there to convey? You show a page with the Environments creation. User enters name, you can start to autogenerate the label for convenience. If the user wants to change it during the creation step, let them. Once created they can rename the Environment until their heart's content. Just not the label. Want a new label? clone the Environment to a new one give it a new label. Remove the old Environment. Again labels unique human readable codes they can use to uniquely identify an environment. > - discoverability (not something we have atm, but something we should > be striving for in our REST api) more than compensates for obtuse urls. True but I'm seeing this as overrated. Having done the HATEOAS thing on candlepin, I don't know how useful it is to a client. Most clients aren't smart enough to look for ref links and follow them besides a browser. But I do know that most curl users will remember 'devel' as their environment name vs '550e8400e29b41d4a716446655440000'. jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ From ewoud+katello at kohlvanwijngaarden.nl Thu Aug 9 15:18:55 2012 From: ewoud+katello at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Thu, 9 Aug 2012 17:18:55 +0200 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023CEAF.6030701@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> <5023B704.6070602@redhat.com> <5023B9D1.6070207@redhat.com> <5023CEAF.6030701@redhat.com> Message-ID: <20120809151855.GA25069@bogey.xentower.nl> On Thu, Aug 09, 2012 at 10:52:31AM -0400, jesus m. rodriguez wrote: > On 08/09/2012 09:23 AM, Dmitri Dolguikh wrote: > >On 09/08/12 02:11 PM, Justin Sherrill wrote: > >>On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote: > >>>On 09/08/12 01:49 PM, Justin Sherrill wrote: > >>>>On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: > >>>>>On 09/08/12 01:20 PM, James Bowes wrote: > >>>>>>On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: > >>>>>>>Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for > >>>>>>>description of an issue with environment renaming. > >>>>>>> > >>>>>>>The immediate problems around environments: using of environment > >>>>>>>names and environment ids for identification of environments > >>>>>>>interchangeably. Using db ids for environment identification when > >>>>>>>not using environment names. > >>>>>>> > >>>>>>>To resolve these: > >>>>>>> - introduce environment uuids > >>>>>>> - update katello/katello cli to use uuids for environment > >>>>>>>identification > >>>>>>> - update repository naming to use environment uuids > >>>>>>> - update candlepin (this will include updates to schema, and > >>>>>>>resource controller) > >>>>>>> > >>>>>>-1 to UUIDs, for the same reason as has been discussed wrt pulp > >>>>>>repo labels. a url like: > >>>>>> > >>>>>>https://my-cdn.local/content/dev/rhel-server/i386/ > >>>>>> > >>>>>>is way more useful than: > >>>>>> > >>>>>>https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ > >>>>>> > >>>>>> > >>>>>>not to mention, far more handsome! > >>>>>> > >>>>>>I'd rather see either immutable labels, or supporting renaming > >>>>>>labels, > >>>>>>too. > >>>>>The issue boils down to renaming of environments. If we are to use > >>>>>environment names for environment identification, we have to > >>>>>provide resolution for urls that are no longer valid (via 301). > >>>>>Doable, but additional work. > >>>>> > >>>>>The idea of labels is interesting, but I don't think it would work > >>>>>out in the long-term: it would become stale after a rename or two > >>>>> > >>>>I would agree with you, except for the fact that in Satellite many > >>>>different objects used the idea of a mutable name and an immutable > >>>>label (especially for repos). I don't know that I once heard a > >>>>complaint from a customer that they couldn't rename a label or that > >>>>it was stale. > >>>> > >>>I just don't think it's possible to communicate the intent using a > >>>short (for the benefit of usability) label, so that the label would > >>>stay constant while environment name kept changing. > >>> > >>>Perhaps renaming of environments is overrated? > >>>-d > >> > >>I don't think its overrated, and regardless i feel that we need to be > >>able to rename repositories as well (where you'd hit the same issue). > >>It does seem odd, but it worked really well in satellite :) > >I suspect that renaming doesn't happen all that often in the lifetime of > >a given named resource. While I certainly agree that it's useful and > >nice to have human-readable urls, it's not always attainable. The > >benefits are further reduced by: > > - realizing that the main consumer of those urls is some piece of code. > > I respectfully disagree. The main consumer will probably be a user > NOT a piece of code. I don't see why label is such a horrible idea. > What is there to convey? You show a page with the Environments > creation. User enters name, you can start to autogenerate the label > for convenience. If the user wants to change it during the creation > step, let them. > > Once created they can rename the Environment until their heart's > content. Just not the label. Want a new label? clone the Environment > to a new one give it a new label. Remove the old Environment. Again > labels unique > human readable codes they can use to uniquely identify an environment. > > > - discoverability (not something we have atm, but something we should > >be striving for in our REST api) more than compensates for obtuse urls. > > True but I'm seeing this as overrated. Having done the HATEOAS thing > on candlepin, I don't know how useful it is to a client. Most > clients aren't smart enough to look for ref links and follow them > besides a browser. > But I do know that most curl users will remember 'devel' as their > environment name vs '550e8400e29b41d4a716446655440000'. I certainly agree that labels are easier to read, but how hard is it to maintain both and symlink the label to the UUID? Here the UUID would be stable and label unstable. Then when you rename the environment you should warn the user that label urls will disappear, but I doubt that happens very often. In cases where it does change often they can switch to using UUIDs. From dmitri at redhat.com Thu Aug 9 15:30:08 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 16:30:08 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023CEAF.6030701@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> <5023B704.6070602@redhat.com> <5023B9D1.6070207@redhat.com> <5023CEAF.6030701@redhat.com> Message-ID: <5023D780.1090108@redhat.com> On 09/08/12 03:52 PM, jesus m. rodriguez wrote: > On 08/09/2012 09:23 AM, Dmitri Dolguikh wrote: >> On 09/08/12 02:11 PM, Justin Sherrill wrote: >>> On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote: >>>> On 09/08/12 01:49 PM, Justin Sherrill wrote: >>>>> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >>>>>> On 09/08/12 01:20 PM, James Bowes wrote: >>>>>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>>> description of an issue with environment renaming. >>>>>>>> >>>>>>>> The immediate problems around environments: using of environment >>>>>>>> names and environment ids for identification of environments >>>>>>>> interchangeably. Using db ids for environment identification when >>>>>>>> not using environment names. >>>>>>>> >>>>>>>> To resolve these: >>>>>>>> - introduce environment uuids >>>>>>>> - update katello/katello cli to use uuids for environment >>>>>>>> identification >>>>>>>> - update repository naming to use environment uuids >>>>>>>> - update candlepin (this will include updates to schema, and >>>>>>>> resource controller) >>>>>>>> >>>>>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>>>>>> repo labels. a url like: >>>>>>> >>>>>>> https://my-cdn.local/content/dev/rhel-server/i386/ >>>>>>> >>>>>>> is way more useful than: >>>>>>> >>>>>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> not to mention, far more handsome! >>>>>>> >>>>>>> I'd rather see either immutable labels, or supporting renaming >>>>>>> labels, >>>>>>> too. >>>>>> The issue boils down to renaming of environments. If we are to use >>>>>> environment names for environment identification, we have to >>>>>> provide resolution for urls that are no longer valid (via 301). >>>>>> Doable, but additional work. >>>>>> >>>>>> The idea of labels is interesting, but I don't think it would work >>>>>> out in the long-term: it would become stale after a rename or two >>>>>> >>>>> I would agree with you, except for the fact that in Satellite many >>>>> different objects used the idea of a mutable name and an immutable >>>>> label (especially for repos). I don't know that I once heard a >>>>> complaint from a customer that they couldn't rename a label or that >>>>> it was stale. >>>>> >>>> I just don't think it's possible to communicate the intent using a >>>> short (for the benefit of usability) label, so that the label would >>>> stay constant while environment name kept changing. >>>> >>>> Perhaps renaming of environments is overrated? >>>> -d >>> >>> I don't think its overrated, and regardless i feel that we need to be >>> able to rename repositories as well (where you'd hit the same issue). >>> It does seem odd, but it worked really well in satellite :) >> I suspect that renaming doesn't happen all that often in the lifetime of >> a given named resource. While I certainly agree that it's useful and >> nice to have human-readable urls, it's not always attainable. The >> benefits are further reduced by: >> - realizing that the main consumer of those urls is some piece of >> code. > > I respectfully disagree. The main consumer will probably be a user NOT > a piece of code. I don't see why label is such a horrible idea. What > is there to convey? You show a page with the Environments creation. > User enters name, you can start to autogenerate the label for > convenience. If the user wants to change it during the creation step, > let them. A label, being product of a human being is going to be: - subjective, and fit this persons taxonomy of w/e they happen to be labelling - associated with (in the case of environments) current use of environment > > Once created they can rename the Environment until their heart's > content. Just not the label. Want a new label? clone the Environment > to a new one give it a new label. Remove the old Environment. Again > labels unique > human readable codes they can use to uniquely identify an environment. > >> - discoverability (not something we have atm, but something we should >> be striving for in our REST api) more than compensates for obtuse urls. > > True but I'm seeing this as overrated. Having done the HATEOAS thing > on candlepin, I don't know how useful it is to a client. Most clients > aren't smart enough to look for ref links and follow them besides a > browser. HATEOAS is a big part of it, another is ability to search (we can even provide search links in ther response for each resource). > But I do know that most curl users will remember 'devel' as their > environment name vs '550e8400e29b41d4a716446655440000'. That's one of the issues - devel in this case may be renamed to 'staging', while you'll be stuck with the label 'devel', which has become misleading. As an API implementor I'd much rather annoy everybody equally, than mislead some users. -d > > jesus > From dmitri at redhat.com Thu Aug 9 15:32:49 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 16:32:49 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <20120809151855.GA25069@bogey.xentower.nl> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> <5023B704.6070602@redhat.com> <5023B9D1.6070207@redhat.com> <5023CEAF.6030701@redhat.com> <20120809151855.GA25069@bogey.xentower.nl> Message-ID: <5023D821.6080004@redhat.com> On 09/08/12 04:18 PM, Ewoud Kohl van Wijngaarden wrote: > On Thu, Aug 09, 2012 at 10:52:31AM -0400, jesus m. rodriguez wrote: >> On 08/09/2012 09:23 AM, Dmitri Dolguikh wrote: >>> On 09/08/12 02:11 PM, Justin Sherrill wrote: >>>> On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote: >>>>> On 09/08/12 01:49 PM, Justin Sherrill wrote: >>>>>> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >>>>>>> On 09/08/12 01:20 PM, James Bowes wrote: >>>>>>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>>>> description of an issue with environment renaming. >>>>>>>>> >>>>>>>>> The immediate problems around environments: using of environment >>>>>>>>> names and environment ids for identification of environments >>>>>>>>> interchangeably. Using db ids for environment identification when >>>>>>>>> not using environment names. >>>>>>>>> >>>>>>>>> To resolve these: >>>>>>>>> - introduce environment uuids >>>>>>>>> - update katello/katello cli to use uuids for environment >>>>>>>>> identification >>>>>>>>> - update repository naming to use environment uuids >>>>>>>>> - update candlepin (this will include updates to schema, and >>>>>>>>> resource controller) >>>>>>>>> >>>>>>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>>>>>>> repo labels. a url like: >>>>>>>> >>>>>>>> https://my-cdn.local/content/dev/rhel-server/i386/ >>>>>>>> >>>>>>>> is way more useful than: >>>>>>>> >>>>>>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>>>>>>> >>>>>>>> >>>>>>>> not to mention, far more handsome! >>>>>>>> >>>>>>>> I'd rather see either immutable labels, or supporting renaming >>>>>>>> labels, >>>>>>>> too. >>>>>>> The issue boils down to renaming of environments. If we are to use >>>>>>> environment names for environment identification, we have to >>>>>>> provide resolution for urls that are no longer valid (via 301). >>>>>>> Doable, but additional work. >>>>>>> >>>>>>> The idea of labels is interesting, but I don't think it would work >>>>>>> out in the long-term: it would become stale after a rename or two >>>>>>> >>>>>> I would agree with you, except for the fact that in Satellite many >>>>>> different objects used the idea of a mutable name and an immutable >>>>>> label (especially for repos). I don't know that I once heard a >>>>>> complaint from a customer that they couldn't rename a label or that >>>>>> it was stale. >>>>>> >>>>> I just don't think it's possible to communicate the intent using a >>>>> short (for the benefit of usability) label, so that the label would >>>>> stay constant while environment name kept changing. >>>>> >>>>> Perhaps renaming of environments is overrated? >>>>> -d >>>> I don't think its overrated, and regardless i feel that we need to be >>>> able to rename repositories as well (where you'd hit the same issue). >>>> It does seem odd, but it worked really well in satellite :) >>> I suspect that renaming doesn't happen all that often in the lifetime of >>> a given named resource. While I certainly agree that it's useful and >>> nice to have human-readable urls, it's not always attainable. The >>> benefits are further reduced by: >>> - realizing that the main consumer of those urls is some piece of code. >> I respectfully disagree. The main consumer will probably be a user >> NOT a piece of code. I don't see why label is such a horrible idea. >> What is there to convey? You show a page with the Environments >> creation. User enters name, you can start to autogenerate the label >> for convenience. If the user wants to change it during the creation >> step, let them. >> >> Once created they can rename the Environment until their heart's >> content. Just not the label. Want a new label? clone the Environment >> to a new one give it a new label. Remove the old Environment. Again >> labels unique >> human readable codes they can use to uniquely identify an environment. >> >>> - discoverability (not something we have atm, but something we should >>> be striving for in our REST api) more than compensates for obtuse urls. >> True but I'm seeing this as overrated. Having done the HATEOAS thing >> on candlepin, I don't know how useful it is to a client. Most >> clients aren't smart enough to look for ref links and follow them >> besides a browser. >> But I do know that most curl users will remember 'devel' as their >> environment name vs '550e8400e29b41d4a716446655440000'. > I certainly agree that labels are easier to read, but how hard is it to > maintain both and symlink the label to the UUID? Here the UUID would be > stable and label unstable. Then when you rename the environment you > should warn the user that label urls will disappear, but I doubt that > happens very often. In cases where it does change often they can switch > to using UUIDs. A published url *must* remain accessible, since you don't know where and how it is being used. The only appropriate way to deal with this situation is to provide a 301 redirect, which requires work (including support on the client side). -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jsherril at redhat.com Thu Aug 9 15:34:19 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 09 Aug 2012 11:34:19 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023D780.1090108@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> <5023B704.6070602@redhat.com> <5023B9D1.6070207@redhat.com> <5023CEAF.6030701@redhat.com> <5023D780.1090108@redhat.com> Message-ID: <5023D87B.8020508@redhat.com> On 08/09/2012 11:30 AM, Dmitri Dolguikh wrote: > On 09/08/12 03:52 PM, jesus m. rodriguez wrote: >> On 08/09/2012 09:23 AM, Dmitri Dolguikh wrote: >>> On 09/08/12 02:11 PM, Justin Sherrill wrote: >>>> On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote: >>>>> On 09/08/12 01:49 PM, Justin Sherrill wrote: >>>>>> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >>>>>>> On 09/08/12 01:20 PM, James Bowes wrote: >>>>>>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>>>> description of an issue with environment renaming. >>>>>>>>> >>>>>>>>> The immediate problems around environments: using of environment >>>>>>>>> names and environment ids for identification of environments >>>>>>>>> interchangeably. Using db ids for environment identification when >>>>>>>>> not using environment names. >>>>>>>>> >>>>>>>>> To resolve these: >>>>>>>>> - introduce environment uuids >>>>>>>>> - update katello/katello cli to use uuids for environment >>>>>>>>> identification >>>>>>>>> - update repository naming to use environment uuids >>>>>>>>> - update candlepin (this will include updates to schema, and >>>>>>>>> resource controller) >>>>>>>>> >>>>>>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>>>>>>> repo labels. a url like: >>>>>>>> >>>>>>>> https://my-cdn.local/content/dev/rhel-server/i386/ >>>>>>>> >>>>>>>> is way more useful than: >>>>>>>> >>>>>>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> not to mention, far more handsome! >>>>>>>> >>>>>>>> I'd rather see either immutable labels, or supporting renaming >>>>>>>> labels, >>>>>>>> too. >>>>>>> The issue boils down to renaming of environments. If we are to use >>>>>>> environment names for environment identification, we have to >>>>>>> provide resolution for urls that are no longer valid (via 301). >>>>>>> Doable, but additional work. >>>>>>> >>>>>>> The idea of labels is interesting, but I don't think it would work >>>>>>> out in the long-term: it would become stale after a rename or two >>>>>>> >>>>>> I would agree with you, except for the fact that in Satellite many >>>>>> different objects used the idea of a mutable name and an immutable >>>>>> label (especially for repos). I don't know that I once heard a >>>>>> complaint from a customer that they couldn't rename a label or that >>>>>> it was stale. >>>>>> >>>>> I just don't think it's possible to communicate the intent using a >>>>> short (for the benefit of usability) label, so that the label would >>>>> stay constant while environment name kept changing. >>>>> >>>>> Perhaps renaming of environments is overrated? >>>>> -d >>>> >>>> I don't think its overrated, and regardless i feel that we need to be >>>> able to rename repositories as well (where you'd hit the same issue). >>>> It does seem odd, but it worked really well in satellite :) >>> I suspect that renaming doesn't happen all that often in the >>> lifetime of >>> a given named resource. While I certainly agree that it's useful and >>> nice to have human-readable urls, it's not always attainable. The >>> benefits are further reduced by: >>> - realizing that the main consumer of those urls is some piece of >>> code. >> >> I respectfully disagree. The main consumer will probably be a user >> NOT a piece of code. I don't see why label is such a horrible idea. >> What is there to convey? You show a page with the Environments >> creation. User enters name, you can start to autogenerate the label >> for convenience. If the user wants to change it during the creation >> step, let them. > A label, being product of a human being is going to be: > - subjective, and fit this persons taxonomy of w/e they happen to be > labelling > - associated with (in the case of environments) current use of > environment >> >> Once created they can rename the Environment until their heart's >> content. Just not the label. Want a new label? clone the Environment >> to a new one give it a new label. Remove the old Environment. Again >> labels unique >> human readable codes they can use to uniquely identify an environment. >> >>> - discoverability (not something we have atm, but something we >>> should >>> be striving for in our REST api) more than compensates for obtuse urls. >> >> True but I'm seeing this as overrated. Having done the HATEOAS thing >> on candlepin, I don't know how useful it is to a client. Most clients >> aren't smart enough to look for ref links and follow them besides a >> browser. > HATEOAS is a big part of it, another is ability to search (we can even > provide search links in ther response for each resource). >> But I do know that most curl users will remember 'devel' as their >> environment name vs '550e8400e29b41d4a716446655440000'. > > That's one of the issues - devel in this case may be renamed to > 'staging', while you'll be stuck with the label 'devel', which has > become misleading. As an API implementor I'd much rather annoy > everybody equally, than mislead some users. > I would normally think along these lines too, however again after years on satellite no one ever complained about this that i know of. Maybe it annoyed them just not enough to complain, but it was not anything that anyone appeared to care about. Logically what you say makes sense, but from experience in practice it doesn't hold IMHO. -Justin > -d >> >> jesus >> > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From dmitri at redhat.com Thu Aug 9 15:37:32 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 16:37:32 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023CB20.1050300@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023CB20.1050300@redhat.com> Message-ID: <5023D93C.9030408@redhat.com> On 09/08/12 03:37 PM, jesus m. rodriguez wrote: > On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >> On 09/08/12 01:20 PM, James Bowes wrote: >>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>> description of an issue with environment renaming. >>>> >>>> The immediate problems around environments: using of environment >>>> names and environment ids for identification of environments >>>> interchangeably. Using db ids for environment identification when >>>> not using environment names. >>>> >>>> To resolve these: >>>> - introduce environment uuids >>>> - update katello/katello cli to use uuids for environment >>>> identification >>>> - update repository naming to use environment uuids >>>> - update candlepin (this will include updates to schema, and >>>> resource controller) >>>> >>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>> repo labels. a url like: >>> >>> https://my-cdn.local/content/dev/rhel-server/i386/ >>> >>> is way more useful than: >>> >>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>> >>> >>> not to mention, far more handsome! >>> >>> I'd rather see either immutable labels, or supporting renaming labels, >>> too. >> The issue boils down to renaming of environments. If we are to use >> environment names for environment identification, we have to provide >> resolution for urls that are no longer valid (via 301). Doable, but >> additional work. > > Labels are not necessarily environment names. Nothing says you have to > allow changing of the label. The label is just a human readable > identifier that is both easy to remember and use. > > While allowing renaming of labels is nice, I don't think it is > necessary. Even if you allow renaming the environment (the one shown > on the page). > > Think of the trac wiki url. If I create a new page I can call it > DesignLabelsEnvironments. But change the title on the page to be > 'Design of Labels for Environments'. Later I change the title to be: > 'Environment Label Design'. I don't have to change the page name. If I > want to I just create a new one. So if you want to allow label > renaming, then make it easy to create Environments. > > >> The idea of labels is interesting, but I don't think it would work out >> in the long-term: it would become stale after a rename or two > > The labels is what we used for RHN Satellite for Channels. It works > and a lot easier to remember. I can guarantee if you go with UUID you > *WILL* get someone asking why can't they pass in a name. And using the > actual name is bad because they will have spaces and might have to be > translated. Labels are again human readable. > >> >> With uuid's we won't need to support url redirection, they won't go >> stale. For user-friendliness we should provide querying by name with >> environment resource, smt. like: > > Nothing says you have to offer redirection with labels. If you make > them static and force users to create a new environment to get a new > label. > > So let's walk through the label rename then. You let a user change the > label of an environment. So now instead of being 'int-dev' it becomes > 'devel'. You could simply return 404 for anyone still using 'int-dev' > just like they were if they used the wrong uuid. > > If you *MUST* offer 301 'moved permanently' for the label then you'll > have to keep a list of labels. But I think that's going to be more of > a user issue. Because I know people will want to reuse label names > later. So I think most of them will be ok if you have a 404 for a non > existent label. > > IMO I don't think you need to offer label renames. Just allow renaming > of the environment for displaying on the UI. That way your urls are > easier to use, cli will be easier to use, and you'll get less complaints. > >> >> GET >> http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper >> >> >> Less convenient, but easier to implement and maintain (from both user >> and developer perspective). > > I don't understand what your example is about. name should never be > used, it should be label: Querying could be done on any field, really, it's a query after all. A uri, on the other hand should include resource id, in your case the label: http://localhost/katello/api/environments/super-duper -d > > > ../ACME_Corporation/environments?label=super-duper > > jesus > From dmitri at redhat.com Thu Aug 9 15:43:04 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 16:43:04 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <20120809144906.GM46364@pipboy.redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <20120809144906.GM46364@pipboy.redhat.com> Message-ID: <5023DA88.4090507@redhat.com> On 09/08/12 03:49 PM, James Bowes wrote: > On Thu, Aug 09, 2012 at 01:39:56PM +0100, Dmitri Dolguikh wrote: >> On 09/08/12 01:20 PM, James Bowes wrote: >>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>> description of an issue with environment renaming. >>>> >>>> The immediate problems around environments: using of environment >>>> names and environment ids for identification of environments >>>> interchangeably. Using db ids for environment identification when >>>> not using environment names. >>>> >>>> To resolve these: >>>> - introduce environment uuids >>>> - update katello/katello cli to use uuids for environment identification >>>> - update repository naming to use environment uuids >>>> - update candlepin (this will include updates to schema, and >>>> resource controller) >>>> >>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>> repo labels. a url like: >>> >>> https://my-cdn.local/content/dev/rhel-server/i386/ >>> >>> is way more useful than: >>> >>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>> >>> not to mention, far more handsome! >>> >>> I'd rather see either immutable labels, or supporting renaming labels, >>> too. >> The issue boils down to renaming of environments. If we are to use >> environment names for environment identification, we have to provide >> resolution for urls that are no longer valid (via 301). Doable, but >> additional work. >> > label and name can be seperate. label could be my-env, name could be "My > Environment". label is something that can be easily passed into a cli > command, or put in a yum url for content downloads. name would just be > something you view. > > I don't think it's necessary to support redirection. I think it is. The resource has to be reachable under the originally-issued url, unless it has been deleted. > >> The idea of labels is interesting, but I don't think it would work >> out in the long-term: it would become stale after a rename or two >> > Unless you update the label at the same time. Defeats the point of the whole exercise. >> With uuid's we won't need to support url redirection, they won't go >> stale. For user-friendliness we should provide querying by name with >> environment resource, smt. like: >> >> GET http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper >> > That's effectively the same as using the label directly in the path of > the url, isn't it? The difference is that uri gives you the resource in question, or a 404. A query can return none, one, or multiple resources. In other words, a query doesn't uniquely identify a resource, only provides a way to find one. > >> Less convenient, but easier to implement and maintain (from both >> user and developer perspective). >> >> -d >> >>> To clarify, UUIDs are fine imo as an internal canonical id for envs >>> within katello as a whole, but once the env is exposed on the cli or in >>> a url, label should be used. >>> >>>> The larger problem: Katello and Candlepin modelling of >>>> products/product content/environments lost coherency. >>>> >>>> Candlepin's view of the above trifecta (use of a monospaced font is >>>> encouraged for the content below): >>>> +-------------+ +--------------------+ >>>> | Environment | 1 <--- * | EnvironmentContent | >>>> +-------------+ +--------------------+ >>>> ^ >>>> | * >>>> | 1 >>>> +---------+ +----------------+ >>>> | Product | 1 ---> * | ProductContent | >>>> +---------+ +----------------+ >>>> >>>> >>>> same thing in Katello (with added pulp repositories): >>>> >>>> +-------------+ >>>> | Pulp::Repos |<-----------------------+ >>>> +-------------+ | >>>> ^ | >>>> | uses | >>>> +----------------------------------+ | +-------------+ >>>> | Candlepin::Product | | | Environment | >>>> | (uses Candlepin::ProductContent) | | +-------------+ >>>> +----------------------------------+ | ^ >>>> | ^ | | 1 >>>> |uses | uses | | >>>> | | | | * >>>> +---------+ +--------------------+ >>>> | Product | 1 ---------------> * | EnvironmentProduct | >>>> +---------+ +--------------------+ >>>> | |1 >>>> | |* >>>> | V >>>> | uses +------------+ >>>> +------| Repository | >>>> +------------+ >>>> >>>> >>>> I propose: >>>> - Rename EnvironmentProduct to ProductContent >>>> - make it use Candlepin::ProductContent >>>> - remove use of Pulp::Repos from Product >>>> - delegate responsibility of generation of environment uuids to >>>> Candlepin (should cp folks agree on this) >>>> >>>> resulting in: >>>> >>>> +-------------+ >>>> | Environment | >>>> +-------------+ >>>> ^ >>>> | 1 >>>> | * >>>> +---------+ +----------------+ >>>> | Product | 1 ---> * | ProductContent | >>>> +---------+ +----------------+ >>>> |1 | uses >>>> | | +---------------------------+ >>>> |1 +-> | Candlepin::ProductContent | >>>> V +---------------------------+ >>>> +-------------+ uses +------------+ >>>> | Pulp::Repos |<-----| Repository | >>>> +-------------+ +------------+ >>>> >>>> I don't think many-1 relation is required on >>>> Repository-ProductContent, it's 1-1? >>>> >>>> >>>> Thoughts, concerns, opinions? >>>> -d >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> -James >> > -James > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From esammons at redhat.com Thu Aug 9 15:48:17 2012 From: esammons at redhat.com (Eric Sammons) Date: Thu, 9 Aug 2012 11:48:17 -0400 (EDT) Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <447856879.2692114.1344521781198.JavaMail.root@redhat.com> Message-ID: <623874311.2811995.1344527297642.JavaMail.root@redhat.com> During a call today some questions about case sensitive behavior for users, environments, and I'm sure applicable to other areas, came up. ?The short, should Name == name == NaMe == NAME? ? The issue here is, especially with usernames, orgs, and environments, username should equal USERNAME likewise a dev environment should be the same as a DEV environment (within a org Dev is not going to be different from DEV and JOHNDOE won't be a different user from JohnDoe). ?Does everyone agree? Keep in mind this would likely apply to organizational names as well. -- +--------------------------------------------------------+ | Eric L. Sammons ? ? ? ? ? ? ? ? ? ?esammons at redhat.com | | Senior Quality Assurance Engineer ?irc: eanxgeek ? ? ? | | Red Hat Quality Engineering ? ? ? ?919.754.4963 (w) ? ?| | rhce ?# 805007668329332 ? ? ? ? ? ?919.889.3279 (c) ? ?| | rhcva # 805007668329332 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| +--------------------------------------------------------+ From dmitri at redhat.com Thu Aug 9 15:51:21 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 09 Aug 2012 16:51:21 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023A061.40507@redhat.com> References: <5023A061.40507@redhat.com> Message-ID: <5023DC79.7070205@redhat.com> Since uuids got no love, let's replace uuids with immutable human-readable labels. -d On 09/08/12 12:34 PM, Dmitri Dolguikh wrote: > Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for > description of an issue with environment renaming. > > The immediate problems around environments: using of environment names > and environment ids for identification of environments > interchangeably. Using db ids for environment identification when not > using environment names. > > To resolve these: > - introduce environment uuids > - update katello/katello cli to use uuids for environment identification > - update repository naming to use environment uuids > - update candlepin (this will include updates to schema, and resource > controller) > > > The larger problem: Katello and Candlepin modelling of > products/product content/environments lost coherency. > > Candlepin's view of the above trifecta (use of a monospaced font is > encouraged for the content below): > +-------------+ +--------------------+ > | Environment | 1 <--- * | EnvironmentContent | > +-------------+ +--------------------+ > ^ > | * > | 1 > +---------+ +----------------+ > | Product | 1 ---> * | ProductContent | > +---------+ +----------------+ > > > same thing in Katello (with added pulp repositories): > > +-------------+ > | Pulp::Repos |<-----------------------+ > +-------------+ | > ^ | > | uses | > +----------------------------------+ | +-------------+ > | Candlepin::Product | | | Environment | > | (uses Candlepin::ProductContent) | | +-------------+ > +----------------------------------+ | ^ > | ^ | | 1 > |uses | uses | | > | | | | * > +---------+ +--------------------+ > | Product | 1 ---------------> * | EnvironmentProduct | > +---------+ +--------------------+ > | |1 > | |* > | V > | uses +------------+ > +------| Repository | > +------------+ > > > I propose: > - Rename EnvironmentProduct to ProductContent > - make it use Candlepin::ProductContent > - remove use of Pulp::Repos from Product > - delegate responsibility of generation of environment uuids to > Candlepin (should cp folks agree on this) > > resulting in: > > +-------------+ > | Environment | > +-------------+ > ^ > | 1 > | * > +---------+ +----------------+ > | Product | 1 ---> * | ProductContent | > +---------+ +----------------+ > |1 | uses > | | +---------------------------+ > |1 +-> | Candlepin::ProductContent | > V +---------------------------+ > +-------------+ uses +------------+ > | Pulp::Repos |<-----| Repository | > +-------------+ +------------+ > > I don't think many-1 relation is required on > Repository-ProductContent, it's 1-1? > > > Thoughts, concerns, opinions? > -d > > > > > > > _______________________________________________ > 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 msuchy at redhat.com Thu Aug 9 15:54:31 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Thu, 09 Aug 2012 17:54:31 +0200 Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <623874311.2811995.1344527297642.JavaMail.root@redhat.com> References: <623874311.2811995.1344527297642.JavaMail.root@redhat.com> Message-ID: <5023DD37.1070408@redhat.com> On 9.8.2012 17:48, Eric Sammons wrote: > During a call today some questions about case sensitive behavior for users, environments, and I'm sure applicable to other areas, came up. The short, should Name == name == NaMe == NAME? > > The issue here is, especially with usernames, orgs, and environments, username should equal USERNAME likewise a dev environment should be the same as a DEV environment (within a org Dev is not going to be different from DEV and JOHNDOE won't be a different user from JohnDoe). Does everyone agree? Keep in mind this would likely apply to organizational names as well. Do we support UTF-8 characters in some of those NAMEs? Mirek From esammons at redhat.com Thu Aug 9 16:08:09 2012 From: esammons at redhat.com (Eric Sammons) Date: Thu, 9 Aug 2012 12:08:09 -0400 (EDT) Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <5023DD37.1070408@redhat.com> Message-ID: <214256386.2822916.1344528489490.JavaMail.root@redhat.com> ----- Original Message ----- > On 9.8.2012 17:48, Eric Sammons wrote: > > During a call today some questions about case sensitive behavior > > for users, environments, and I'm sure applicable to other areas, > > came up. The short, should Name == name == NaMe == NAME? > > > > The issue here is, especially with usernames, orgs, and > > environments, username should equal USERNAME likewise a dev > > environment should be the same as a DEV environment (within a org > > Dev is not going to be different from DEV and JOHNDOE won't be a > > different user from JohnDoe). Does everyone agree? Keep in mind > > this would likely apply to organizational names as well. > > Do we support UTF-8 characters in some of those NAMEs? > > Mirek > I should have mentioned that the issue today is that katello treats these values as unique; i.e. under ACME_Corporation I can have Library->DEV->dev. I am under the impression that this should not be permitted. --Eric From msuchy at redhat.com Thu Aug 9 16:16:48 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Thu, 09 Aug 2012 18:16:48 +0200 Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <214256386.2822916.1344528489490.JavaMail.root@redhat.com> References: <214256386.2822916.1344528489490.JavaMail.root@redhat.com> Message-ID: <5023E270.1060207@redhat.com> On 9.8.2012 18:08, Eric Sammons wrote: > > > ----- Original Message ----- >> On 9.8.2012 17:48, Eric Sammons wrote: >>> During a call today some questions about case sensitive behavior >>> for users, environments, and I'm sure applicable to other areas, >>> came up. The short, should Name == name == NaMe == NAME? >>> >>> The issue here is, especially with usernames, orgs, and >>> environments, username should equal USERNAME likewise a dev >>> environment should be the same as a DEV environment (within a org >>> Dev is not going to be different from DEV and JOHNDOE won't be a >>> different user from JohnDoe). Does everyone agree? Keep in mind >>> this would likely apply to organizational names as well. >> >> Do we support UTF-8 characters in some of those NAMEs? >> >> Mirek >> > > I should have mentioned that the issue today is that katello treats these values as unique; i.e. under ACME_Corporation I can have Library->DEV->dev. I am under the impression that this should not be permitted. > > --Eric While I was trying to point that ruby does not handle UTF well: a='ex?mple' a.upcase => "EX?MPLE" And I personally do not see Library->DEV->dev as problem. I can even imagine, that somebody may want this. Mirek From esammons at redhat.com Thu Aug 9 16:25:41 2012 From: esammons at redhat.com (Eric Sammons) Date: Thu, 9 Aug 2012 12:25:41 -0400 (EDT) Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <5023E270.1060207@redhat.com> Message-ID: <397591730.2828308.1344529541769.JavaMail.root@redhat.com> ----- Original Message ----- > On 9.8.2012 18:08, Eric Sammons wrote: > > > > > > ----- Original Message ----- > >> On 9.8.2012 17:48, Eric Sammons wrote: > >>> During a call today some questions about case sensitive behavior > >>> for users, environments, and I'm sure applicable to other areas, > >>> came up. The short, should Name == name == NaMe == NAME? > >>> > >>> The issue here is, especially with usernames, orgs, and > >>> environments, username should equal USERNAME likewise a dev > >>> environment should be the same as a DEV environment (within a org > >>> Dev is not going to be different from DEV and JOHNDOE won't be a > >>> different user from JohnDoe). Does everyone agree? Keep in mind > >>> this would likely apply to organizational names as well. > >> > >> Do we support UTF-8 characters in some of those NAMEs? > >> > >> Mirek > >> > > > > I should have mentioned that the issue today is that katello treats > > these values as unique; i.e. under ACME_Corporation I can have > > Library->DEV->dev. I am under the impression that this should not > > be permitted. > > > > --Eric > > While I was trying to point that ruby does not handle UTF well: > > a='ex?mple' > a.upcase > => "EX?MPLE" > > And I personally do not see Library->DEV->dev as problem. I can even > imagine, that somebody may want this. > > Mirek > Coming from GSS and having been a customer I can assure you that DEV == dev == Dev in a production world. Anything like Library->DEV->dev would be bad design within a company because in the real world dev is dev is dev regardless of how you type it. The same goes for usernames; in fact most web ui apps will convert for you the username entered to the case supported (for example I have seen, esammons at example.com get changed to ESAMMONS at EXAMPLE.COM, perhaps they have a Mainframe backend). So while I may not agree here that allowing Dev DEV and dev, I am more of the opinion that we either fix it or we document it because as is the current behavior could be dangerous. From cperry at redhat.com Thu Aug 9 16:37:02 2012 From: cperry at redhat.com (Cliff Perry) Date: Thu, 09 Aug 2012 17:37:02 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023DC79.7070205@redhat.com> References: <5023A061.40507@redhat.com> <5023DC79.7070205@redhat.com> Message-ID: <5023E72E.3090200@redhat.com> On 08/09/2012 04:51 PM, Dmitri Dolguikh wrote: > Since uuids got no love, let's replace uuids with immutable > human-readable labels. > -d Hmm... random thoughts here. How often will rename of an environment actually happen? - Continue to do not allow rename of an environment. If you really do not want to continue using an environment, I would think that: - Would it be easier to allow customers to 'clone' an environment into a new Environment, then move systems from one environment to another. - They would then retire (or delete) the old environment, when no longer used/needed. If you do wish to allow to rename an Environment. - How will any proposed solution be impacted by upgrades? Can what you propose be implemented sanely to allow a current katello 1.0 user to consume/upgrade smoothly to this new model. - I would vote for a unique immutable human-readable (assuming you have a latin based/derived alphabet) label. Or a numberic ID. - I agree with Justin, that there was almost zero negative feedback in Satellite for customers wanting to change the label, as long as they could modify the description/name of the object. I know this could be its own thread... but IMHO using/feeding environment name/label into a yum URL is a bit limiting, if we have to restrict it and would propose that Environment name/label is not used but an arbitrary numeric ID, thus allowing Japanese, etc languages to be used in creation of an Environment name. (unless I am mistaken on how this works today). If something else pops into my head, I'll reply again :) Cliff > > On 09/08/12 12:34 PM, Dmitri Dolguikh wrote: >> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >> description of an issue with environment renaming. >> >> The immediate problems around environments: using of environment names >> and environment ids for identification of environments >> interchangeably. Using db ids for environment identification when not >> using environment names. >> >> To resolve these: >> - introduce environment uuids >> - update katello/katello cli to use uuids for environment identification >> - update repository naming to use environment uuids >> - update candlepin (this will include updates to schema, and resource >> controller) >> >> >> The larger problem: Katello and Candlepin modelling of >> products/product content/environments lost coherency. >> >> Candlepin's view of the above trifecta (use of a monospaced font is >> encouraged for the content below): >> +-------------+ +--------------------+ >> | Environment | 1 <--- * | EnvironmentContent | >> +-------------+ +--------------------+ >> ^ >> | * >> | 1 >> +---------+ +----------------+ >> | Product | 1 ---> * | ProductContent | >> +---------+ +----------------+ >> >> >> same thing in Katello (with added pulp repositories): >> >> +-------------+ >> | Pulp::Repos |<-----------------------+ >> +-------------+ | >> ^ | >> | uses | >> +----------------------------------+ | +-------------+ >> | Candlepin::Product | | | Environment | >> | (uses Candlepin::ProductContent) | | +-------------+ >> +----------------------------------+ | ^ >> | ^ | | 1 >> |uses | uses | | >> | | | | * >> +---------+ +--------------------+ >> | Product | 1 ---------------> * | EnvironmentProduct | >> +---------+ +--------------------+ >> | |1 >> | |* >> | V >> | uses +------------+ >> +------| Repository | >> +------------+ >> >> >> I propose: >> - Rename EnvironmentProduct to ProductContent >> - make it use Candlepin::ProductContent >> - remove use of Pulp::Repos from Product >> - delegate responsibility of generation of environment uuids to >> Candlepin (should cp folks agree on this) >> >> resulting in: >> >> +-------------+ >> | Environment | >> +-------------+ >> ^ >> | 1 >> | * >> +---------+ +----------------+ >> | Product | 1 ---> * | ProductContent | >> +---------+ +----------------+ >> |1 | uses >> | | +---------------------------+ >> |1 +-> | Candlepin::ProductContent | >> V +---------------------------+ >> +-------------+ uses +------------+ >> | Pulp::Repos |<-----| Repository | >> +-------------+ +------------+ >> >> I don't think many-1 relation is required on >> Repository-ProductContent, it's 1-1? >> >> >> Thoughts, concerns, opinions? >> -d >> >> >> >> >> >> >> _______________________________________________ >> 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 Aug 9 16:46:32 2012 From: cperry at redhat.com (Cliff Perry) Date: Thu, 09 Aug 2012 17:46:32 +0100 Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <397591730.2828308.1344529541769.JavaMail.root@redhat.com> References: <397591730.2828308.1344529541769.JavaMail.root@redhat.com> Message-ID: <5023E968.3080302@redhat.com> On 08/09/2012 05:25 PM, Eric Sammons wrote: > ----- Original Message ----- >> On 9.8.2012 18:08, Eric Sammons wrote: >>> >>> >>> ----- Original Message ----- >>>> On 9.8.2012 17:48, Eric Sammons wrote: >>>>> During a call today some questions about case sensitive behavior >>>>> for users, environments, and I'm sure applicable to other areas, >>>>> came up. The short, should Name == name == NaMe == NAME? >>>>> >>>>> The issue here is, especially with usernames, orgs, and >>>>> environments, username should equal USERNAME likewise a dev >>>>> environment should be the same as a DEV environment (within a org >>>>> Dev is not going to be different from DEV and JOHNDOE won't be a >>>>> different user from JohnDoe). Does everyone agree? Keep in mind >>>>> this would likely apply to organizational names as well. >>>> >>>> Do we support UTF-8 characters in some of those NAMEs? >>>> >>>> Mirek >>>> >>> >>> I should have mentioned that the issue today is that katello treats >>> these values as unique; i.e. under ACME_Corporation I can have >>> Library->DEV->dev. I am under the impression that this should not >>> be permitted. >>> >>> --Eric >> >> While I was trying to point that ruby does not handle UTF well: >> >> a='ex?mple' >> a.upcase >> => "EX?MPLE" >> >> And I personally do not see Library->DEV->dev as problem. I can even >> imagine, that somebody may want this. >> >> Mirek >> > > Coming from GSS and having been a customer I can assure you that DEV == dev == Dev in a production world. Anything like Library->DEV->dev would be bad design within a company because in the real world dev is dev is dev regardless of how you type it. The same goes for usernames; in fact most web ui apps will convert for you the username entered to the case supported (for example I have seen, esammons at example.com get changed to ESAMMONS at EXAMPLE.COM, perhaps they have a Mainframe backend). > > So while I may not agree here that allowing Dev DEV and dev, I am more of the opinion that we either fix it or we document it because as is the current behavior could be dangerous. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel IMHO - usernames should not be case sensitive, but I could also see where an MS Active Directory environment in play it may be important to not lowercase everything for a user authentication to successfully occur. In general, I feel that we shouldn't allow Dev, DEV, dev to be different... but, with how we have things today, what is the negative user experience/feedback to say we should change? - I'd prefer to not change things, just to change it into what we think is more correct. - Upgrades would be a blast to try and force upgrade folks from Dev, DEV, dev to dev, dev1, dev2. Cliff From esammons at redhat.com Thu Aug 9 17:06:57 2012 From: esammons at redhat.com (Eric Sammons) Date: Thu, 9 Aug 2012 13:06:57 -0400 (EDT) Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <5023E968.3080302@redhat.com> Message-ID: <151860010.2853313.1344532017893.JavaMail.root@redhat.com> > > IMHO - usernames should not be case sensitive, but I could also see > where an MS Active Directory environment in play it may be important > to > not lowercase everything for a user authentication to successfully > occur. > > In general, I feel that we shouldn't allow Dev, DEV, dev to be > different... but, with how we have things today, what is the negative > user experience/feedback to say we should change? > - I'd prefer to not change things, just to change it into what we > think is more correct. > - Upgrades would be a blast to try and force upgrade folks from > Dev, > DEV, dev to dev, dev1, dev2. > > Cliff > I would consider this change to be a proactive change. It is only a matter of time before this could negatively impact a customer and it also takes away from the quality of the product we are delivering. Also, it should be noted, what I am suggesting here is based on a couple of bugs that others in QE have opened. The suggestion is a check to verify that when you create a new "abc" that it and no other incarnation of it exists. Again, this is more of a design and proactive change - we don't have a large enough customer base yet to where I would expect someone to be complaining about this. From mrao at redhat.com Thu Aug 9 18:01:56 2012 From: mrao at redhat.com (Malini Rao) Date: Thu, 9 Aug 2012 14:01:56 -0400 (EDT) Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <5023E968.3080302@redhat.com> Message-ID: <1639483421.4803592.1344535316075.JavaMail.root@redhat.com> ----- Original Message ----- From: "Cliff Perry" To: "Eric Sammons" Cc: katello-devel at redhat.com Sent: Thursday, August 9, 2012 12:46:32 PM Subject: Re: [katello-devel] Case sensitive behavior in katello On 08/09/2012 05:25 PM, Eric Sammons wrote: > ----- Original Message ----- >> On 9.8.2012 18:08, Eric Sammons wrote: >>> >>> >>> ----- Original Message ----- >>>> On 9.8.2012 17:48, Eric Sammons wrote: >>>>> During a call today some questions about case sensitive behavior >>>>> for users, environments, and I'm sure applicable to other areas, >>>>> came up. The short, should Name == name == NaMe == NAME? >>>>> >>>>> The issue here is, especially with usernames, orgs, and >>>>> environments, username should equal USERNAME likewise a dev >>>>> environment should be the same as a DEV environment (within a org >>>>> Dev is not going to be different from DEV and JOHNDOE won't be a >>>>> different user from JohnDoe). Does everyone agree? Keep in mind >>>>> this would likely apply to organizational names as well. >>>> >>>> Do we support UTF-8 characters in some of those NAMEs? >>>> >>>> Mirek >>>> >>> >>> I should have mentioned that the issue today is that katello treats >>> these values as unique; i.e. under ACME_Corporation I can have >>> Library->DEV->dev. I am under the impression that this should not >>> be permitted. >>> >>> --Eric >> >> While I was trying to point that ruby does not handle UTF well: >> >> a='ex?mple' >> a.upcase >> => "EX?MPLE" >> >> And I personally do not see Library->DEV->dev as problem. I can even >> imagine, that somebody may want this. >> >> Mirek >> > > Coming from GSS and having been a customer I can assure you that DEV == dev == Dev in a production world. Anything like Library->DEV->dev would be bad design within a company because in the real world dev is dev is dev regardless of how you type it. The same goes for usernames; in fact most web ui apps will convert for you the username entered to the case supported (for example I have seen, esammons at example.com get changed to ESAMMONS at EXAMPLE.COM, perhaps they have a Mainframe backend). +1 from a UX perspective and for the real world insight. > > So while I may not agree here that allowing Dev DEV and dev, I am more of the opinion that we either fix it or we document it because as is the current behavior could be dangerous. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel IMHO - usernames should not be case sensitive, but I could also see where an MS Active Directory environment in play it may be important to not lowercase everything for a user authentication to successfully occur. In general, I feel that we shouldn't allow Dev, DEV, dev to be different... but, with how we have things today, what is the negative user experience/feedback to say we should change? - I'd prefer to not change things, just to change it into what we think is more correct. - Upgrades would be a blast to try and force upgrade folks from Dev, DEV, dev to dev, dev1, dev2. Cliff _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From cperry at redhat.com Thu Aug 9 19:22:56 2012 From: cperry at redhat.com (Cliff Perry) Date: Thu, 09 Aug 2012 20:22:56 +0100 Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <151860010.2853313.1344532017893.JavaMail.root@redhat.com> References: <151860010.2853313.1344532017893.JavaMail.root@redhat.com> Message-ID: <50240E10.9030708@redhat.com> On 08/09/2012 06:06 PM, Eric Sammons wrote: >> >> IMHO - usernames should not be case sensitive, but I could also see >> where an MS Active Directory environment in play it may be important >> to >> not lowercase everything for a user authentication to successfully >> occur. >> >> In general, I feel that we shouldn't allow Dev, DEV, dev to be >> different... but, with how we have things today, what is the negative >> user experience/feedback to say we should change? >> - I'd prefer to not change things, just to change it into what we >> think is more correct. >> - Upgrades would be a blast to try and force upgrade folks from >> Dev, >> DEV, dev to dev, dev1, dev2. >> >> Cliff >> > > I would consider this change to be a proactive change. It is only a matter of time before this could negatively impact a customer and it also takes away from the quality of the product we are delivering. > I figured I should ask for motivation, since it was obvious to me, but better to check than assume. I like the proactive approach. I wish we hadn't implemented the code as we have it today :) So, likely for others to give input/decide. My only negative is potential impact to current users for upgrades. > Also, it should be noted, what I am suggesting here is based on a couple of bugs that others in QE have opened. The suggestion is a check to verify that when you create a new "abc" that it and no other incarnation of it exists. > > Again, this is more of a design and proactive change - we don't have a large enough customer base yet to where I would expect someone to be complaining about this. Cliff, From bkearney at redhat.com Thu Aug 9 23:21:54 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 09 Aug 2012 19:21:54 -0400 Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <1639483421.4803592.1344535316075.JavaMail.root@redhat.com> References: <1639483421.4803592.1344535316075.JavaMail.root@redhat.com> Message-ID: <50244612.6000300@redhat.com> On 08/09/2012 02:01 PM, Malini Rao wrote: > > > ----- Original Message ----- > From: "Cliff Perry" > To: "Eric Sammons" > Cc: katello-devel at redhat.com > Sent: Thursday, August 9, 2012 12:46:32 PM > Subject: Re: [katello-devel] Case sensitive behavior in katello > > On 08/09/2012 05:25 PM, Eric Sammons wrote: >> ----- Original Message ----- >>> On 9.8.2012 18:08, Eric Sammons wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> On 9.8.2012 17:48, Eric Sammons wrote: >>>>>> During a call today some questions about case sensitive behavior >>>>>> for users, environments, and I'm sure applicable to other areas, >>>>>> came up. The short, should Name == name == NaMe == NAME? >>>>>> >>>>>> The issue here is, especially with usernames, orgs, and >>>>>> environments, username should equal USERNAME likewise a dev >>>>>> environment should be the same as a DEV environment (within a org >>>>>> Dev is not going to be different from DEV and JOHNDOE won't be a >>>>>> different user from JohnDoe). Does everyone agree? Keep in mind >>>>>> this would likely apply to organizational names as well. >>>>> >>>>> Do we support UTF-8 characters in some of those NAMEs? >>>>> >>>>> Mirek >>>>> >>>> >>>> I should have mentioned that the issue today is that katello treats >>>> these values as unique; i.e. under ACME_Corporation I can have >>>> Library->DEV->dev. I am under the impression that this should not >>>> be permitted. >>>> >>>> --Eric >>> >>> While I was trying to point that ruby does not handle UTF well: >>> >>> a='ex?mple' >>> a.upcase >>> => "EX?MPLE" >>> >>> And I personally do not see Library->DEV->dev as problem. I can even >>> imagine, that somebody may want this. >>> >>> Mirek >>> >> >> Coming from GSS and having been a customer I can assure you that DEV == dev == Dev in a production world. Anything like Library->DEV->dev would be bad design within a company because in the real world dev is dev is dev regardless of how you type it. The same goes for usernames; in fact most web ui apps will convert for you the username entered to the case supported (for example I have seen, esammons at example.com get changed to ESAMMONS at EXAMPLE.COM, perhaps they have a Mainframe backend). > > +1 from a UX perspective and for the real world insight. > > >> >> So while I may not agree here that allowing Dev DEV and dev, I am more of the opinion that we either fix it or we document it because as is the current behavior could be dangerous. >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > IMHO - usernames should not be case sensitive, but I could also see > where an MS Active Directory environment in play it may be important to > not lowercase everything for a user authentication to successfully occur. > > In general, I feel that we shouldn't allow Dev, DEV, dev to be > different... but, with how we have things today, what is the negative > user experience/feedback to say we should change? > - I'd prefer to not change things, just to change it into what we > think is more correct. > - Upgrades would be a blast to try and force upgrade folks from Dev, > DEV, dev to dev, dev1, dev2. > Yeah.. i think it will depend. For orgs and envrionment,s it should not matter. For usernames.. same. For packages.. perhaps. -- bk From bkearney at redhat.com Thu Aug 9 23:59:09 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 09 Aug 2012 19:59:09 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023B704.6070602@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> <5023B704.6070602@redhat.com> Message-ID: <50244ECD.2000808@redhat.com> On 08/09/2012 09:11 AM, Justin Sherrill wrote: > On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote: >> On 09/08/12 01:49 PM, Justin Sherrill wrote: >>> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >>>> On 09/08/12 01:20 PM, James Bowes wrote: >>>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>> description of an issue with environment renaming. >>>>>> >>>>>> The immediate problems around environments: using of environment >>>>>> names and environment ids for identification of environments >>>>>> interchangeably. Using db ids for environment identification when >>>>>> not using environment names. >>>>>> >>>>>> To resolve these: >>>>>> - introduce environment uuids >>>>>> - update katello/katello cli to use uuids for environment >>>>>> identification >>>>>> - update repository naming to use environment uuids >>>>>> - update candlepin (this will include updates to schema, and >>>>>> resource controller) >>>>>> >>>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>>>> repo labels. a url like: >>>>> >>>>> https://my-cdn.local/content/dev/rhel-server/i386/ >>>>> >>>>> is way more useful than: >>>>> >>>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>>>> >>>>> >>>>> not to mention, far more handsome! >>>>> >>>>> I'd rather see either immutable labels, or supporting renaming labels, >>>>> too. >>>> The issue boils down to renaming of environments. If we are to use >>>> environment names for environment identification, we have to provide >>>> resolution for urls that are no longer valid (via 301). Doable, but >>>> additional work. >>>> >>>> The idea of labels is interesting, but I don't think it would work >>>> out in the long-term: it would become stale after a rename or two >>>> >>> I would agree with you, except for the fact that in Satellite many >>> different objects used the idea of a mutable name and an immutable >>> label (especially for repos). I don't know that I once heard a >>> complaint from a customer that they couldn't rename a label or that >>> it was stale. >>> >> I just don't think it's possible to communicate the intent using a >> short (for the benefit of usability) label, so that the label would >> stay constant while environment name kept changing. >> >> Perhaps renaming of environments is overrated? >> -d > > I don't think its overrated, and regardless i feel that we need to be > able to rename repositories as well (where you'd hit the same issue). It > does seem odd, but it worked really well in satellite :) > > -Justin Did folks on the client ever see the repos? If I remember, they were always server side. We could move to a model where the name and id are readable, but the url is not: [Dev-Evironment-Wiked-Product-Kick-Arse-Repo] name= Dev Evironment Wiked Product Kick Arse Repo url= /content/919/555/1212/ -- bk From bkearney at redhat.com Fri Aug 10 00:00:05 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 09 Aug 2012 20:00:05 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <20120809151855.GA25069@bogey.xentower.nl> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> <5023B704.6070602@redhat.com> <5023B9D1.6070207@redhat.com> <5023CEAF.6030701@redhat.com> <20120809151855.GA25069@bogey.xentower.nl> Message-ID: <50244F05.4080108@redhat.com> On 08/09/2012 11:18 AM, Ewoud Kohl van Wijngaarden wrote: > On Thu, Aug 09, 2012 at 10:52:31AM -0400, jesus m. rodriguez wrote: >> On 08/09/2012 09:23 AM, Dmitri Dolguikh wrote: >>> On 09/08/12 02:11 PM, Justin Sherrill wrote: >>>> On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote: >>>>> On 09/08/12 01:49 PM, Justin Sherrill wrote: >>>>>> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >>>>>>> On 09/08/12 01:20 PM, James Bowes wrote: >>>>>>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>>>> description of an issue with environment renaming. >>>>>>>>> >>>>>>>>> The immediate problems around environments: using of environment >>>>>>>>> names and environment ids for identification of environments >>>>>>>>> interchangeably. Using db ids for environment identification when >>>>>>>>> not using environment names. >>>>>>>>> >>>>>>>>> To resolve these: >>>>>>>>> - introduce environment uuids >>>>>>>>> - update katello/katello cli to use uuids for environment >>>>>>>>> identification >>>>>>>>> - update repository naming to use environment uuids >>>>>>>>> - update candlepin (this will include updates to schema, and >>>>>>>>> resource controller) >>>>>>>>> >>>>>>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>>>>>>> repo labels. a url like: >>>>>>>> >>>>>>>> https://my-cdn.local/content/dev/rhel-server/i386/ >>>>>>>> >>>>>>>> is way more useful than: >>>>>>>> >>>>>>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>>>>>>> >>>>>>>> >>>>>>>> not to mention, far more handsome! >>>>>>>> >>>>>>>> I'd rather see either immutable labels, or supporting renaming >>>>>>>> labels, >>>>>>>> too. >>>>>>> The issue boils down to renaming of environments. If we are to use >>>>>>> environment names for environment identification, we have to >>>>>>> provide resolution for urls that are no longer valid (via 301). >>>>>>> Doable, but additional work. >>>>>>> >>>>>>> The idea of labels is interesting, but I don't think it would work >>>>>>> out in the long-term: it would become stale after a rename or two >>>>>>> >>>>>> I would agree with you, except for the fact that in Satellite many >>>>>> different objects used the idea of a mutable name and an immutable >>>>>> label (especially for repos). I don't know that I once heard a >>>>>> complaint from a customer that they couldn't rename a label or that >>>>>> it was stale. >>>>>> >>>>> I just don't think it's possible to communicate the intent using a >>>>> short (for the benefit of usability) label, so that the label would >>>>> stay constant while environment name kept changing. >>>>> >>>>> Perhaps renaming of environments is overrated? >>>>> -d >>>> >>>> I don't think its overrated, and regardless i feel that we need to be >>>> able to rename repositories as well (where you'd hit the same issue). >>>> It does seem odd, but it worked really well in satellite :) >>> I suspect that renaming doesn't happen all that often in the lifetime of >>> a given named resource. While I certainly agree that it's useful and >>> nice to have human-readable urls, it's not always attainable. The >>> benefits are further reduced by: >>> - realizing that the main consumer of those urls is some piece of code. >> >> I respectfully disagree. The main consumer will probably be a user >> NOT a piece of code. I don't see why label is such a horrible idea. >> What is there to convey? You show a page with the Environments >> creation. User enters name, you can start to autogenerate the label >> for convenience. If the user wants to change it during the creation >> step, let them. >> >> Once created they can rename the Environment until their heart's >> content. Just not the label. Want a new label? clone the Environment >> to a new one give it a new label. Remove the old Environment. Again >> labels unique >> human readable codes they can use to uniquely identify an environment. >> >>> - discoverability (not something we have atm, but something we should >>> be striving for in our REST api) more than compensates for obtuse urls. >> >> True but I'm seeing this as overrated. Having done the HATEOAS thing >> on candlepin, I don't know how useful it is to a client. Most >> clients aren't smart enough to look for ref links and follow them >> besides a browser. >> But I do know that most curl users will remember 'devel' as their >> environment name vs '550e8400e29b41d4a716446655440000'. > > I certainly agree that labels are easier to read, but how hard is it to > maintain both and symlink the label to the UUID? Here the UUID would be > stable and label unstable. Then when you rename the environment you > should warn the user that label urls will disappear, but I doubt that > happens very often. In cases where it does change often they can switch > to using UUIDs. > We need to regen the certs, which rely on a hierarchy to protect the content. -- bk From bkearney at redhat.com Fri Aug 10 00:01:42 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 09 Aug 2012 20:01:42 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023C373.3080606@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023C373.3080606@redhat.com> Message-ID: <50244F66.9000309@redhat.com> On 08/09/2012 10:04 AM, jesus m. rodriguez wrote: > On 08/09/2012 08:20 AM, James Bowes wrote: >> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>> description of an issue with environment renaming. >>> >>> The immediate problems around environments: using of environment >>> names and environment ids for identification of environments >>> interchangeably. Using db ids for environment identification when >>> not using environment names. >>> >>> To resolve these: >>> - introduce environment uuids >>> - update katello/katello cli to use uuids for environment >>> identification >>> - update repository naming to use environment uuids >>> - update candlepin (this will include updates to schema, and >>> resource controller) >>> >> >> -1 to UUIDs, for the same reason as has been discussed wrt pulp >> repo labels. a url like: >> >> https://my-cdn.local/content/dev/rhel-server/i386/ >> >> is way more useful than: >> >> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >> >> not to mention, far more handsome! >> >> I'd rather see either immutable labels, or supporting renaming labels, >> too. >> >> To clarify, UUIDs are fine imo as an internal canonical id for envs >> within katello as a whole, but once the env is exposed on the cli or in >> a url, label should be used. > > +1000 to labels > -1000 to using the UUID you dont get to vote in thousands. :) -- bk From bkearney at redhat.com Fri Aug 10 00:05:58 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 09 Aug 2012 20:05:58 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023E72E.3090200@redhat.com> References: <5023A061.40507@redhat.com> <5023DC79.7070205@redhat.com> <5023E72E.3090200@redhat.com> Message-ID: <50245066.2030105@redhat.com> On 08/09/2012 12:37 PM, Cliff Perry wrote: > On 08/09/2012 04:51 PM, Dmitri Dolguikh wrote: >> Since uuids got no love, let's replace uuids with immutable >> human-readable labels. >> -d > > Hmm... random thoughts here. > > How often will rename of an environment actually happen? > - Continue to do not allow rename of an environment. If you really do > not want to continue using an environment, I would think that: > - Would it be easier to allow customers to 'clone' an environment > into a new Environment, then move systems from one environment to another. > - They would then retire (or delete) the old environment, when no > longer used/needed. The same issue is with products. As we put them into the url path, renames require regens of the certs. > > If you do wish to allow to rename an Environment. > - How will any proposed solution be impacted by upgrades? Can what you > propose be implemented sanely to allow a current katello 1.0 user to > consume/upgrade smoothly to this new model. > - I would vote for a unique immutable human-readable (assuming you > have a latin based/derived alphabet) label. Or a numberic ID. > - I agree with Justin, that there was almost zero negative feedback > in Satellite for customers wanting to change the label, as long as they > could modify the description/name of the object. > > I know this could be its own thread... but IMHO using/feeding > environment name/label into a yum URL is a bit limiting, if we have to > restrict it and would propose that Environment name/label is not used > but an arbitrary numeric ID, thus allowing Japanese, etc languages to be > used in creation of an Environment name. (unless I am mistaken on how > this works today). The goal has been to make them somewhat readable since we are populating a repo file on disk. -- bk From jpazdziora at redhat.com Fri Aug 10 07:53:14 2012 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 10 Aug 2012 09:53:14 +0200 Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <5023E270.1060207@redhat.com> References: <214256386.2822916.1344528489490.JavaMail.root@redhat.com> <5023E270.1060207@redhat.com> Message-ID: <20120810075314.GA8837@redhat.com> On Thu, Aug 09, 2012 at 06:16:48PM +0200, Miroslav Suchy wrote: > > While I was trying to point that ruby does not handle UTF well: > > a='ex?mple' > a.upcase > => "EX?MPLE" Shouldn't you use UnicodeUtils gem for that? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat From dmitri at redhat.com Fri Aug 10 08:21:03 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 10 Aug 2012 09:21:03 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023E72E.3090200@redhat.com> References: <5023A061.40507@redhat.com> <5023DC79.7070205@redhat.com> <5023E72E.3090200@redhat.com> Message-ID: <5024C46F.2060500@redhat.com> On 09/08/12 05:37 PM, Cliff Perry wrote: > On 08/09/2012 04:51 PM, Dmitri Dolguikh wrote: >> Since uuids got no love, let's replace uuids with immutable >> human-readable labels. >> -d > > Hmm... random thoughts here. > > How often will rename of an environment actually happen? > - Continue to do not allow rename of an environment. If you really do > not want to continue using an environment, I would think that: > - Would it be easier to allow customers to 'clone' an environment > into a new Environment, then move systems from one environment to > another. > - They would then retire (or delete) the old environment, when no > longer used/needed. That would work, considering we now have support for moving of systems between environments. > > If you do wish to allow to rename an Environment. > - How will any proposed solution be impacted by upgrades? Can what > you propose be implemented sanely to allow a current katello 1.0 user > to consume/upgrade smoothly to this new model. Could be very disruptive, as repository ids will have to change, resulting in need to regenerate all entitlement certificates that have content. Could be handled by an upgrade script though. > - I would vote for a unique immutable human-readable (assuming you > have a latin based/derived alphabet) label. Or a numberic ID. > - I agree with Justin, that there was almost zero negative feedback > in Satellite for customers wanting to change the label, as long as > they could modify the description/name of the object. > > I know this could be its own thread... but IMHO using/feeding > environment name/label into a yum URL is a bit limiting, if we have to > restrict it and would propose that Environment name/label is not used > but an arbitrary numeric ID, thus allowing Japanese, etc languages to > be used in creation of an Environment name. (unless I am mistaken on > how this works today). Something I haven't considered at all. Any human-readable id will have to be limited to ascii, as URL-encoding a non-ascii human readable label will turn it into human-unreadable. Back to uuids. Very good points. Should we choose to go with editing of environment names (which seems inevitable), I think we could migrate environments to new ones by cloning environment name as the id, and use uuid for all newly created environments. This would eliminate the need for regeneration of repository urls and entitlement certificates for all systems involved. Alternatively, moving of systems provides a graceful way to change environments (although we'll need bulk system moving for this to be a functional equivalent). -d > > If something else pops into my head, I'll reply again :) > > Cliff > >> >> On 09/08/12 12:34 PM, Dmitri Dolguikh wrote: >>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>> description of an issue with environment renaming. >>> >>> The immediate problems around environments: using of environment names >>> and environment ids for identification of environments >>> interchangeably. Using db ids for environment identification when not >>> using environment names. >>> >>> To resolve these: >>> - introduce environment uuids >>> - update katello/katello cli to use uuids for environment >>> identification >>> - update repository naming to use environment uuids >>> - update candlepin (this will include updates to schema, and resource >>> controller) >>> >>> >>> The larger problem: Katello and Candlepin modelling of >>> products/product content/environments lost coherency. >>> >>> Candlepin's view of the above trifecta (use of a monospaced font is >>> encouraged for the content below): >>> +-------------+ +--------------------+ >>> | Environment | 1 <--- * | EnvironmentContent | >>> +-------------+ +--------------------+ >>> ^ >>> | * >>> | 1 >>> +---------+ +----------------+ >>> | Product | 1 ---> * | ProductContent | >>> +---------+ +----------------+ >>> >>> >>> same thing in Katello (with added pulp repositories): >>> >>> +-------------+ >>> | Pulp::Repos |<-----------------------+ >>> +-------------+ | >>> ^ | >>> | uses | >>> +----------------------------------+ | +-------------+ >>> | Candlepin::Product | | | Environment | >>> | (uses Candlepin::ProductContent) | | +-------------+ >>> +----------------------------------+ | ^ >>> | ^ | | 1 >>> |uses | uses | | >>> | | | | * >>> +---------+ +--------------------+ >>> | Product | 1 ---------------> * | EnvironmentProduct | >>> +---------+ +--------------------+ >>> | |1 >>> | |* >>> | V >>> | uses +------------+ >>> +------| Repository | >>> +------------+ >>> >>> >>> I propose: >>> - Rename EnvironmentProduct to ProductContent >>> - make it use Candlepin::ProductContent >>> - remove use of Pulp::Repos from Product >>> - delegate responsibility of generation of environment uuids to >>> Candlepin (should cp folks agree on this) >>> >>> resulting in: >>> >>> +-------------+ >>> | Environment | >>> +-------------+ >>> ^ >>> | 1 >>> | * >>> +---------+ +----------------+ >>> | Product | 1 ---> * | ProductContent | >>> +---------+ +----------------+ >>> |1 | uses >>> | | +---------------------------+ >>> |1 +-> | Candlepin::ProductContent | >>> V +---------------------------+ >>> +-------------+ uses +------------+ >>> | Pulp::Repos |<-----| Repository | >>> +-------------+ +------------+ >>> >>> I don't think many-1 relation is required on >>> Repository-ProductContent, it's 1-1? >>> >>> >>> Thoughts, concerns, opinions? >>> -d >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 jsherril at redhat.com Fri Aug 10 19:52:48 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Fri, 10 Aug 2012 15:52:48 -0400 Subject: [katello-devel] Candlepin rpms not signed in our repos Message-ID: <50256690.4050802@redhat.com> Any reason for $SUBJECT? -Justin From mmccune at redhat.com Fri Aug 10 21:06:26 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 10 Aug 2012 14:06:26 -0700 Subject: [katello-devel] Candlepin rpms not signed in our repos In-Reply-To: <50256690.4050802@redhat.com> References: <50256690.4050802@redhat.com> Message-ID: <502577D2.9020205@redhat.com> On 08/10/2012 12:52 PM, Justin Sherrill wrote: > Any reason for $SUBJECT? > > -Justin I pushed the latest rev into Koji so we would have 0.7 across both Fedora and RHEL6 builds Unfortunately they are not signed, I'm working to get that fixed here ASAP Mike From msuchy at redhat.com Sat Aug 11 09:31:02 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Sat, 11 Aug 2012 11:31:02 +0200 Subject: [katello-devel] Candlepin rpms not signed in our repos In-Reply-To: <502577D2.9020205@redhat.com> References: <50256690.4050802@redhat.com> <502577D2.9020205@redhat.com> Message-ID: <50262656.1080802@redhat.com> On 10.8.2012 23:06, Mike McCune wrote: >> Any reason for $SUBJECT? >> >> -Justin > > I pushed the latest rev into Koji so we would have 0.7 across both > Fedora and RHEL6 builds > > Unfortunately they are not signed, I'm working to get that fixed here ASAP Signed. It will appear on public yum repo in 2 hours. Mirek From jsherril at redhat.com Mon Aug 13 14:33:36 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 13 Aug 2012 10:33:36 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <50244ECD.2000808@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> <5023B704.6070602@redhat.com> <50244ECD.2000808@redhat.com> Message-ID: <50291040.8090300@redhat.com> On 08/09/2012 07:59 PM, Bryan Kearney wrote: > On 08/09/2012 09:11 AM, Justin Sherrill wrote: >> On 08/09/2012 09:08 AM, Dmitri Dolguikh wrote: >>> On 09/08/12 01:49 PM, Justin Sherrill wrote: >>>> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >>>>> On 09/08/12 01:20 PM, James Bowes wrote: >>>>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>> description of an issue with environment renaming. >>>>>>> >>>>>>> The immediate problems around environments: using of environment >>>>>>> names and environment ids for identification of environments >>>>>>> interchangeably. Using db ids for environment identification when >>>>>>> not using environment names. >>>>>>> >>>>>>> To resolve these: >>>>>>> - introduce environment uuids >>>>>>> - update katello/katello cli to use uuids for environment >>>>>>> identification >>>>>>> - update repository naming to use environment uuids >>>>>>> - update candlepin (this will include updates to schema, and >>>>>>> resource controller) >>>>>>> >>>>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>>>>> repo labels. a url like: >>>>>> >>>>>> https://my-cdn.local/content/dev/rhel-server/i386/ >>>>>> >>>>>> is way more useful than: >>>>>> >>>>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>>>>> >>>>>> >>>>>> >>>>>> not to mention, far more handsome! >>>>>> >>>>>> I'd rather see either immutable labels, or supporting renaming >>>>>> labels, >>>>>> too. >>>>> The issue boils down to renaming of environments. If we are to use >>>>> environment names for environment identification, we have to provide >>>>> resolution for urls that are no longer valid (via 301). Doable, but >>>>> additional work. >>>>> >>>>> The idea of labels is interesting, but I don't think it would work >>>>> out in the long-term: it would become stale after a rename or two >>>>> >>>> I would agree with you, except for the fact that in Satellite many >>>> different objects used the idea of a mutable name and an immutable >>>> label (especially for repos). I don't know that I once heard a >>>> complaint from a customer that they couldn't rename a label or that >>>> it was stale. >>>> >>> I just don't think it's possible to communicate the intent using a >>> short (for the benefit of usability) label, so that the label would >>> stay constant while environment name kept changing. >>> >>> Perhaps renaming of environments is overrated? >>> -d >> >> I don't think its overrated, and regardless i feel that we need to be >> able to rename repositories as well (where you'd hit the same issue). It >> does seem odd, but it worked really well in satellite :) >> >> -Justin > > Did folks on the client ever see the repos? If I remember, they were > always server side. > > We could move to a model where the name and id are readable, but the > url is not: > > [Dev-Evironment-Wiked-Product-Kick-Arse-Repo] > name= Dev Evironment Wiked Product Kick Arse Repo > url= /content/919/555/1212/ > > -- bk You would see them when interacting with yum (yum repolist, etc..) There was no file that contained the list though. I think the above would be fine, as in satellite you couldn't ever really see the url in any way. I think the priority is to make the yum repo ID and name human readable. I don't think its important at all for the url to be human readable. -Justin > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From dmitri at redhat.com Mon Aug 13 14:45:46 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 13 Aug 2012 15:45:46 +0100 Subject: [katello-devel] Renaming of environments: summary Message-ID: <5029131A.7030405@redhat.com> This is a summary of the thread started at https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for details of the issue with environment renaming. Quite a few folks suggested using of an immutable label instead of environment name, but at the end the idea was defeated by a comment from Cliff Perry about users from locales using non-ascii-based character sets. Another issue that was discovered was the migration of already established environments from current version of Katello to the version containing the fix. My current thinking is to use environment name value as uuid for "legacy" environments. This would significantly simply upgrade, as there will be no need to regenerate entitlement certificates, etc. Katello: - introduce environment uuids (update db schema, model, etc) - update candlepin (this will include updates to schema, and resource controller) - update katello/katello cli to use uuids for environment identification - update repository-related functionality to use environment uuids - figure out/create migration from 1.0 to current Bryan, everything minus the migration bit is probably a couple days worth of work. Should I create a new story, or I can start on this right away? -d From jsherril at redhat.com Mon Aug 13 14:52:12 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 13 Aug 2012 10:52:12 -0400 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <5029131A.7030405@redhat.com> References: <5029131A.7030405@redhat.com> Message-ID: <5029149C.4030509@redhat.com> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: > This is a summary of the thread started at > https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. > Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for > details of the issue with environment renaming. > > Quite a few folks suggested using of an immutable label instead of > environment name, but at the end the idea was defeated by a comment > from Cliff Perry about users from locales using non-ascii-based > character sets. > Another issue that was discovered was the migration of already > established environments from current version of Katello to the > version containing the fix. My current thinking is to use environment > name value as uuid for "legacy" environments. This would significantly > simply upgrade, as there will be no need to regenerate entitlement > certificates, etc. > > Katello: > - introduce environment uuids (update db schema, model, etc) > - update candlepin (this will include updates to schema, and resource > controller) > - update katello/katello cli to use uuids for environment identification > - update repository-related functionality to use environment uuids > - figure out/create migration from 1.0 to current > > Bryan, everything minus the migration bit is probably a couple days > worth of work. Should I create a new story, or I can start on this > right away? > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Any idea what the redhat.repo file will look like with numerical ids? Or yum repolist ? -Justin From jrist at redhat.com Mon Aug 13 14:54:57 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 13 Aug 2012 08:54:57 -0600 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <5029131A.7030405@redhat.com> References: <5029131A.7030405@redhat.com> Message-ID: <50291541.2080701@redhat.com> On Mon 13 Aug 2012 08:45:46 AM MDT, Dmitri Dolguikh wrote: > This is a summary of the thread started at > https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. > Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for > details of the issue with environment renaming. > > Quite a few folks suggested using of an immutable label instead of > environment name, but at the end the idea was defeated by a comment > from Cliff Perry about users from locales using non-ascii-based > character sets. > Another issue that was discovered was the migration of already > established environments from current version of Katello to the > version containing the fix. My current thinking is to use environment > name value as uuid for "legacy" environments. This would significantly > simply upgrade, as there will be no need to regenerate entitlement > certificates, etc. > > Katello: > - introduce environment uuids (update db schema, model, etc) > - update candlepin (this will include updates to schema, and resource > controller) > - update katello/katello cli to use uuids for environment identification > - update repository-related functionality to use environment uuids > - figure out/create migration from 1.0 to current > > Bryan, everything minus the migration bit is probably a couple days > worth of work. Should I create a new story, or I can start on this > right away? > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Dmitri - I'd like to thank you for setting the precedent of summarizing the email chain that you started. This is so helpful for those of us that a) have a hard time tracking such a long conversation and b) want to get an understanding of the expectations and scope of these types of changes. That said, I agree with the points you've laid out. This seems like a valid way forward. Can we use the current naming if it already exists rather than reassigning or migrating to a UUID? -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From dmitri at redhat.com Mon Aug 13 14:55:27 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 13 Aug 2012 15:55:27 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <5029149C.4030509@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> Message-ID: <5029155F.5040100@redhat.com> On 13/08/12 03:52 PM, Justin Sherrill wrote: > On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >> This is a summary of the thread started at >> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >> details of the issue with environment renaming. >> >> Quite a few folks suggested using of an immutable label instead of >> environment name, but at the end the idea was defeated by a comment >> from Cliff Perry about users from locales using non-ascii-based >> character sets. >> Another issue that was discovered was the migration of already >> established environments from current version of Katello to the >> version containing the fix. My current thinking is to use environment >> name value as uuid for "legacy" environments. This would >> significantly simply upgrade, as there will be no need to regenerate >> entitlement certificates, etc. >> >> Katello: >> - introduce environment uuids (update db schema, model, etc) >> - update candlepin (this will include updates to schema, and >> resource controller) >> - update katello/katello cli to use uuids for environment >> identification >> - update repository-related functionality to use environment uuids >> - figure out/create migration from 1.0 to current >> >> Bryan, everything minus the migration bit is probably a couple days >> worth of work. Should I create a new story, or I can start on this >> right away? >> >> -d >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Any idea what the redhat.repo file will look like with numerical ids? > Or yum repolist ? Same as now, but with environment uuids instead on environment names. -d > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jsherril at redhat.com Mon Aug 13 14:57:57 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 13 Aug 2012 10:57:57 -0400 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <5029155F.5040100@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> Message-ID: <502915F5.8060403@redhat.com> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: > On 13/08/12 03:52 PM, Justin Sherrill wrote: >> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>> This is a summary of the thread started at >>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>> >>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>> details of the issue with environment renaming. >>> >>> Quite a few folks suggested using of an immutable label instead of >>> environment name, but at the end the idea was defeated by a comment >>> from Cliff Perry about users from locales using non-ascii-based >>> character sets. >>> Another issue that was discovered was the migration of already >>> established environments from current version of Katello to the >>> version containing the fix. My current thinking is to use >>> environment name value as uuid for "legacy" environments. This would >>> significantly simply upgrade, as there will be no need to regenerate >>> entitlement certificates, etc. >>> >>> Katello: >>> - introduce environment uuids (update db schema, model, etc) >>> - update candlepin (this will include updates to schema, and >>> resource controller) >>> - update katello/katello cli to use uuids for environment >>> identification >>> - update repository-related functionality to use environment uuids >>> - figure out/create migration from 1.0 to current >>> >>> Bryan, everything minus the migration bit is probably a couple days >>> worth of work. Should I create a new story, or I can start on this >>> right away? >>> >>> -d >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> Any idea what the redhat.repo file will look like with numerical >> ids? Or yum repolist ? > Same as now, but with environment uuids instead on environment names. > -d So [123456] name=123456 baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ or [123456] name=Red Hat Enterprise Linux Server 6 RPMS baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ ? >> >> -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 dmitri at redhat.com Mon Aug 13 14:58:05 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 13 Aug 2012 15:58:05 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <50291541.2080701@redhat.com> References: <5029131A.7030405@redhat.com> <50291541.2080701@redhat.com> Message-ID: <502915FD.50300@redhat.com> On 13/08/12 03:54 PM, Jason Rist wrote: > On Mon 13 Aug 2012 08:45:46 AM MDT, Dmitri Dolguikh wrote: >> This is a summary of the thread started at >> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >> details of the issue with environment renaming. >> >> Quite a few folks suggested using of an immutable label instead of >> environment name, but at the end the idea was defeated by a comment >> from Cliff Perry about users from locales using non-ascii-based >> character sets. >> Another issue that was discovered was the migration of already >> established environments from current version of Katello to the >> version containing the fix. My current thinking is to use environment >> name value as uuid for "legacy" environments. This would significantly >> simply upgrade, as there will be no need to regenerate entitlement >> certificates, etc. >> >> Katello: >> - introduce environment uuids (update db schema, model, etc) >> - update candlepin (this will include updates to schema, and resource >> controller) >> - update katello/katello cli to use uuids for environment identification >> - update repository-related functionality to use environment uuids >> - figure out/create migration from 1.0 to current >> >> Bryan, everything minus the migration bit is probably a couple days >> worth of work. Should I create a new story, or I can start on this >> right away? >> >> -d >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > Dmitri - I'd like to thank you for setting the precedent of summarizing > the email chain that you started. This is so helpful for those of us > that a) have a hard time tracking such a long conversation and b) want > to get an understanding of the expectations and scope of these types of > changes. > > That said, I agree with the points you've laid out. This seems like a > valid way forward. Can we use the current naming if it already exists > rather than reassigning or migrating to a UUID? My current thinking is exactly that - I'm proposing using current environment names as environment ids for current installations of Katello. -d > > -J > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > From dmitri at redhat.com Mon Aug 13 15:00:35 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 13 Aug 2012 16:00:35 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502915F5.8060403@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> Message-ID: <50291693.9080001@redhat.com> On 13/08/12 03:57 PM, Justin Sherrill wrote: > On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>> This is a summary of the thread started at >>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>> >>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>> details of the issue with environment renaming. >>>> >>>> Quite a few folks suggested using of an immutable label instead of >>>> environment name, but at the end the idea was defeated by a comment >>>> from Cliff Perry about users from locales using non-ascii-based >>>> character sets. >>>> Another issue that was discovered was the migration of already >>>> established environments from current version of Katello to the >>>> version containing the fix. My current thinking is to use >>>> environment name value as uuid for "legacy" environments. This >>>> would significantly simply upgrade, as there will be no need to >>>> regenerate entitlement certificates, etc. >>>> >>>> Katello: >>>> - introduce environment uuids (update db schema, model, etc) >>>> - update candlepin (this will include updates to schema, and >>>> resource controller) >>>> - update katello/katello cli to use uuids for environment >>>> identification >>>> - update repository-related functionality to use environment uuids >>>> - figure out/create migration from 1.0 to current >>>> >>>> Bryan, everything minus the migration bit is probably a couple days >>>> worth of work. Should I create a new story, or I can start on this >>>> right away? >>>> >>>> -d >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> Any idea what the redhat.repo file will look like with numerical >>> ids? Or yum repolist ? >> Same as now, but with environment uuids instead on environment names. >> -d > Apologies, I didn't understand the question. The latter. -d > So > > [123456] > name=123456 > baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ > > or > > [123456] > name=Red Hat Enterprise Linux Server 6 RPMS > baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ > > > ? > > >>> >>> -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 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From dmitri at redhat.com Mon Aug 13 15:05:07 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 13 Aug 2012 16:05:07 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (take ||) Message-ID: <502917A3.6050905@redhat.com> Could a couple of folks on Katello team spend an hour or so and take a look at the architectural changes I propose in https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html? Much appreciated, -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitri at redhat.com Mon Aug 13 15:28:25 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 13 Aug 2012 16:28:25 +0100 Subject: [katello-devel] some small wiki changes Message-ID: <50291D19.6090301@redhat.com> Hey everybody, I made a few changes on Katello public wiki: - put https://fedorahosted.org/katello/wiki/GitGuide on the home page - created an "End of Iteration" page (https://fedorahosted.org/katello/wiki/EndOfIteration) - and moved tagging-related steps to the page above Could folks who have been doing packaging lately document the process and a link to "End of Iteration" page pls? Or just the latter bit if the page already exist? Thanks, -d From jsherril at redhat.com Mon Aug 13 16:18:55 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 13 Aug 2012 12:18:55 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (take ||) In-Reply-To: <502917A3.6050905@redhat.com> References: <502917A3.6050905@redhat.com> Message-ID: <502928EF.4050207@redhat.com> On 08/13/2012 11:05 AM, Dmitri Dolguikh wrote: > Could a couple of folks on Katello team spend an hour or so and take a > look at the architectural changes I propose in > https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html? > > > Much appreciated, > -d > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel A couple of thoughts. As we discussed previously productContent does not have a 1-1 mapping to a pulp repo, so with that in mind: 1. Pulp::Repos is a module made up of product and content related items in relation to pulp. I understand that product may not be the best fit for this, however sticking it within repo really isn't either (I would be 100% against this). Potentially breaking it up into product related items and product content related items would make the most sense. 2. I don't see how repositories are tied to environments in this diagram. How would i go about getting all the repositories for a product within an environment? 3. Data level organization is great and all, but if the code isn't more readable (or at least isn't less readable) its all for nothing. Its been my experience that rarely within the code do we need all the repos for a product content within an environment (I don''t know that i've ever needed that information). This is how you've proposed to organize the data however. So if i have to do something like my_product.product_content.collect{|pc| pc.repositories}.flatten in order to get the list of repos in a product, it would not be worth it. I believe the current structure came out of the lack of a need for product content within katello itself (as a user facing object). Try to keep the scopes within product as they are today as much as possible. (i.e. I should still be able to do my_product.repos(my_environment) as that is much nicer :} ). I understand that candlepin relies on product content for lots of things, but katello itself really doesn't care about product content. I'm hesitant to make it a first class model citizen in katello as it could make a lot of code more complicated, but as long as that's kept to a minimum, I'm ok with it. I would say as part of this if you find yourself replacing lots of db queries/AR lookups with longer statements, step back and ask yourself how to simplify it. 4. I would like to see a new proposed diagram with some of these concerns (#1 & #2 & the fact that productContent and repos are not 1-1 mapped) addressed. Thanks, -Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlabocki at redhat.com Mon Aug 13 18:30:34 2012 From: jlabocki at redhat.com (James Labocki) Date: Mon, 13 Aug 2012 14:30:34 -0400 (EDT) Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <2110731970.8903009.1344878030044.JavaMail.root@redhat.com> Message-ID: <713002230.8961790.1344882634730.JavaMail.root@redhat.com> Sorry for posting across both lists, but this involves both aeolus and katello. Last week a few of us were discussing the ability to import/export deployables within aeolus for sharing between differing implementations. The attached photo 1.JPG provides a high level diagram of some of the problems we believe exist in achieving this today. Please note that I used enterprise nomenclature, so I think that: - System Engine = Katello - Component Outline = Assembly - Blueprint = Deployable - AppForm = Deployment We found the following areas differ between implementations and would need to be accounted for. Note this this was not an exhaustive exercise and I'm sure we missed some areas. - Providers paths are different in katello - Certificates are different in system templates - Repositories are different in system templates - Deployables and their services are tightly coupled (not shareable) - Clouds, Cloud Resource Zones, and Catalogs are different in aeolus There seem to be a few approaches that we can use. #1 Create an import/export tool that prompts users for various implementation specific areas (repository names, certificate locations, etc). #2 Use the work Francesco has been doing on templates.aeolusproject.org to solve the problem by having it integrated into aeolus and contain the logic that would abstract environment differences from end users. #3 Allow users to import/export the corresponding images along with the blueprint (this does not help with ongoing management through katello). #4 Change the template/image/assembly/deployment model to allow for users to easily create an application blueprint from someone elses environment. #5 Create some consistency in implementation (share system templates via ACME_Corporation org in katello for example). I'm curious as to what approaches are being considered in both aeolus and katello to allow for users to share their system templates and deployables with minimal effort. -------------- next part -------------- A non-text attachment was scrubbed... Name: photo 1.JPG Type: image/jpeg Size: 445445 bytes Desc: not available URL: From jsherril at redhat.com Mon Aug 13 19:45:51 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 13 Aug 2012 15:45:51 -0400 Subject: [katello-devel] Modelling of environments, products, etc in Katello (take ||) In-Reply-To: <502928EF.4050207@redhat.com> References: <502917A3.6050905@redhat.com> <502928EF.4050207@redhat.com> Message-ID: <5029596F.9090409@redhat.com> On 08/13/2012 12:18 PM, Justin Sherrill wrote: > On 08/13/2012 11:05 AM, Dmitri Dolguikh wrote: >> Could a couple of folks on Katello team spend an hour or so and take >> a look at the architectural changes I propose in >> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html? >> >> >> Much appreciated, >> -d >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > A couple of thoughts. As we discussed previously productContent does > not have a 1-1 mapping to a pulp repo, so with that in mind: > > 1. Pulp::Repos is a module made up of product and content related > items in relation to pulp. I understand that product may not be the > best fit for this, however sticking it within repo really isn't either > (I would be 100% against this). Potentially breaking it up into > product related items and product content related items would make the > most sense. > > 2. I don't see how repositories are tied to environments in this > diagram. How would i go about getting all the repositories for a > product within an environment? > > 3. Data level organization is great and all, but if the code isn't > more readable (or at least isn't less readable) its all for nothing. > Its been my experience that rarely within the code do we need all the > repos for a product content within an environment (I don''t know that > i've ever needed that information). This is how you've proposed to > organize the data however. So if i have to do something like > my_product.product_content.collect{|pc| pc.repositories}.flatten in > order to get the list of repos in a product, it would not be worth > it. I believe the current structure came out of the lack of a need > for product content within katello itself (as a user facing object). > Try to keep the scopes within product as they are today as much as > possible. (i.e. I should still be able to do > my_product.repos(my_environment) as that is much nicer :} ). I > understand that candlepin relies on product content for lots of > things, but katello itself really doesn't care about product content. > I'm hesitant to make it a first class model citizen in katello as it > could make a lot of code more complicated, but as long as that's kept > to a minimum, I'm ok with it. > > I would say as part of this if you find yourself replacing lots of db > queries/AR lookups with longer statements, step back and ask yourself > how to simplify it. > > 4. I would like to see a new proposed diagram with some of these > concerns (#1 & #2 & the fact that productContent and repos are not 1-1 > mapped) addressed. > > Thanks, > > -Justin Couple of other things I noticed which kinda might address some of the confusion around my previous questions: 5. You're current katello diagram is incorrect in that Repository does not "use" (aka include i assume) Pulp::Repos, it includes Pulp::Repo. 6. In your proposed model, a product is only related to an environment by its Product content and I believe a repo is only related to an environment through its product content. This changes how we today consider if a product is promoted within katello and what it means for a repository to be in an environment. Currently if I promote repo "RHEL Server 6.2 x86_64" That doesn't mean all repos within that content (RHEL Server $relver $arch) exist in that environment, which i feel is kinda what it implies. We also I believe allow the promotion of empty products, which i don't think this model allows. I do believe there is a disconnect between repos in katello and product content in candlepin and as long we allow you to selectively enable and promote only certain instances of content (aka repos), then I think there always will be. I know we are not handling this perfectly today within katello (i.e. a client might assume that RHEL Server 6.1 x86_64 exist in an environment when it does not), but i'm not entirely sure this is improves the situation? -Justin > > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmccune at redhat.com Mon Aug 13 22:13:32 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 13 Aug 2012 15:13:32 -0700 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <50291693.9080001@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> Message-ID: <50297C0C.2080501@redhat.com> On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote: > On 13/08/12 03:57 PM, Justin Sherrill wrote: >> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >>> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>>> This is a summary of the thread started at >>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>>> >>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>> details of the issue with environment renaming. >>>>> >>>>> Quite a few folks suggested using of an immutable label instead of >>>>> environment name, but at the end the idea was defeated by a comment >>>>> from Cliff Perry about users from locales using non-ascii-based >>>>> character sets. >>>>> Another issue that was discovered was the migration of already >>>>> established environments from current version of Katello to the >>>>> version containing the fix. My current thinking is to use >>>>> environment name value as uuid for "legacy" environments. This >>>>> would significantly simply upgrade, as there will be no need to >>>>> regenerate entitlement certificates, etc. >>>>> >>>>> Katello: >>>>> - introduce environment uuids (update db schema, model, etc) >>>>> - update candlepin (this will include updates to schema, and >>>>> resource controller) >>>>> - update katello/katello cli to use uuids for environment >>>>> identification >>>>> - update repository-related functionality to use environment uuids >>>>> - figure out/create migration from 1.0 to current >>>>> >>>>> Bryan, everything minus the migration bit is probably a couple days >>>>> worth of work. Should I create a new story, or I can start on this >>>>> right away? >>>>> >>>>> -d >>>>> >>>>> _______________________________________________ >>>>> katello-devel mailing list >>>>> katello-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> Any idea what the redhat.repo file will look like with numerical >>>> ids? Or yum repolist ? >>> Same as now, but with environment uuids instead on environment names. >>> -d >> > Apologies, I didn't understand the question. The latter. > -d >> So >> >> [123456] >> name=123456 >> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >> >> or >> >> [123456] >> name=Red Hat Enterprise Linux Server 6 RPMS >> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >> >> >> ? >> and this really blows for our users, IMHO. You go from a relatively readable and clear yum configuration file that a sysadmin can look at quickly and understand: [ACME_Corporation_zoo_zoorepo] name = zoorepo baseurl = https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo enabled = 1 gpgcheck = 1 sslverify = 1 sslcacert = /etc/rhsm/ca/candlepin-local.pem sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem sslclientcert = /etc/pki/entitlement/3783882558646362292.pem to: [313024c0-c7bd-012f-d852-1803734d16c4] name = zoorepo baseurl = https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 enabled = 1 gpgcheck = 1 sslverify = 1 sslcacert = /etc/rhsm/ca/candlepin-local.pem sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem sslclientcert = /etc/pki/entitlement/3783882558646362292.pem now as a user you have no idea what env+repo you are really looking at. You know it is the zoorepo in the locker for ACME_Corporation but you would have to know what IDs the environments have to even begin to figure out what content you are pointing at. we are taking something readable and turning it into a generated configuration value that our sysadmins will *really* hate. I think the changes outlined above while clear are a definite step backwards in functionality for Katello. The price to pay to support Env renaming is *not* worth it if we implement it as such. Lets not take this decision likely because one of the primary touch points at the client is the redhat.repo file that lists the content you are pulling down. I'd much rather do the following to ensure our yum config values on the clients are readable and sacrifice i18n in order to do so: 1) use an ASCII label for reops if we are going to really implement repo renaming 2) force Org (possibly), Env and Repo names to be ASCII 3) Any existing utf-8 data for these values is left alone and users are warned we do not support this, or we encode it in some way such that it works Is renaming environments really worth all this effort? If so, lets not sacrifice our usability at the client level just to support it. Mike From inecas at redhat.com Tue Aug 14 06:14:48 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Tue, 14 Aug 2012 08:14:48 +0200 Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <713002230.8961790.1344882634730.JavaMail.root@redhat.com> References: <713002230.8961790.1344882634730.JavaMail.root@redhat.com> Message-ID: <5029ECD8.8040203@redhat.com> On 08/13/2012 08:30 PM, James Labocki wrote: > > Last week a few of us were discussing the ability to import/export deployables within aeolus for sharing between differing implementations. > What does "differing implementations" mean in this context? -- Ivan From lzap at redhat.com Tue Aug 14 09:07:35 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 11:07:35 +0200 Subject: [katello-devel] Proposal: Breaking up Codebase In-Reply-To: <501FBC6E.2060601@redhat.com> References: <939291157.20377.1344043871149.JavaMail.root@redhat.com> <16990899.70983.1344045526288.JavaMail.root@redhat.com> <20120806120103.GA12368@dhcp-230-220.rdu.redhat.com> <501FBC6E.2060601@redhat.com> Message-ID: <20120814090735.GC2850@lzapx.brq.redhat.com> On Mon, Aug 06, 2012 at 08:45:34AM -0400, Bryan Kearney wrote: > If we decide to break up, I would suggest delaying until after 1.1. > First, it will not add any nutty risk tot he release and second, it > will allow us to stabilize the community builds before we switch > things up again. > I am also for delaying it. Overall, I don't have any issues with this breakup, but as Mirek noted it will not only bring advantages. For release engineering this is quite a complication. Also instead of Big Bang, I'd suggest slower change. Because to integrate those changes on the build side, it can be challenging. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Aug 14 09:11:55 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 11:11:55 +0200 Subject: [katello-devel] Blog and Site Accounts In-Reply-To: <50217930.1020603@redhat.com> References: <50217930.1020603@redhat.com> Message-ID: <20120814091155.GE2850@lzapx.brq.redhat.com> I still don't see the announcement in the blog, only testing post. Can we add one? ;-) Looks lice. LZ On Tue, Aug 07, 2012 at 04:23:12PM -0400, Eric Helms wrote: > Since the launch of the newer site is delayed due to DNS changes > (should be occurring this Friday which means hopefully rolled over > by Monday), I figure I can establish accounts ahead of time for > those interested. > > If you would like to be an Author on the blog (able to create and > write posts under your own name) please let me know on IRC or via an > email and I will set up and email you credentials. If you would > like to contribute by helping manage the site in other ways please > email me as well. > > If you have a blog of your own that you would like to linked to > either directly or to a feed that is related to Katello only posts, > please let me know as well and I will add to the community blog > aggregator. > > Again, full community update planning can be seen here: > > http://pad-katello.rhcloud.com/p/community-planning > > Don't forget if you make screencasts, please let us know so we can > upload to our project YouTube channel that will be visible both on > YouTube and our Website. > > Thanks, > Eric > > _______________________________________________ > 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 Aug 14 09:26:16 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 10:26:16 +0100 Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <713002230.8961790.1344882634730.JavaMail.root@redhat.com> References: <713002230.8961790.1344882634730.JavaMail.root@redhat.com> Message-ID: <502A19B8.5030909@redhat.com> On 13/08/12 07:30 PM, James Labocki wrote: > Sorry for posting across both lists, but this involves both aeolus and katello. > > Last week a few of us were discussing the ability to import/export deployables within aeolus for sharing between differing implementations. > > The attached photo 1.JPG provides a high level diagram of some of the problems we believe exist in achieving this today. Please note that I used enterprise nomenclature, so I think that: > > - System Engine = Katello > - Component Outline = Assembly > - Blueprint = Deployable > - AppForm = Deployment > > We found the following areas differ between implementations and would need to be accounted for. Note this this was not an exhaustive exercise and I'm sure we missed some areas. > > - Providers paths are different in katello > - Certificates are different in system templates > - Repositories are different in system templates > - Deployables and their services are tightly coupled (not shareable) > - Clouds, Cloud Resource Zones, and Catalogs are different in aeolus > > There seem to be a few approaches that we can use. > > #1 Create an import/export tool that prompts users for various implementation specific areas (repository names, certificate locations, etc). > > #2 Use the work Francesco has been doing on templates.aeolusproject.org to solve the problem by having it integrated into aeolus and contain the logic that would abstract environment differences from end users. > > #3 Allow users to import/export the corresponding images along with the blueprint (this does not help with ongoing management through katello). > > #4 Change the template/image/assembly/deployment model to allow for users to easily create an application blueprint from someone elses environment. > > #5 Create some consistency in implementation (share system templates via ACME_Corporation org in katello for example). > > I'm curious as to what approaches are being considered in both aeolus and katello to allow for users to share their system templates and deployables with minimal effort. I'm not sure if there were any conversations regarding sharing of templates between Katello and Aeolus. Personally, I think #5 looks the most interesting. Both projects could have different internal implementations of templates, but we should see if we can agree on exchange format at the very least. -d > > > _______________________________________________ > 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 Aug 14 09:29:15 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 11:29:15 +0200 Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <397591730.2828308.1344529541769.JavaMail.root@redhat.com> References: <5023E270.1060207@redhat.com> <397591730.2828308.1344529541769.JavaMail.root@redhat.com> Message-ID: <20120814092915.GF2850@lzapx.brq.redhat.com> On Thu, Aug 09, 2012 at 12:25:41PM -0400, Eric Sammons wrote: > Coming from GSS and having been a customer I can assure you that DEV == dev == Dev in a production world. Anything like Library->DEV->dev would be bad design within a company because in the real world dev is dev is dev regardless of how you type it. The same goes for usernames; in fact most web ui apps will convert for you the username entered to the case supported (for example I have seen, esammons at example.com get changed to ESAMMONS at EXAMPLE.COM, perhaps they have a Mainframe backend). > > So while I may not agree here that allowing Dev DEV and dev, I am more of the opinion that we either fix it or we document it because as is the current behavior could be dangerous. In particular, why having both DEV and dev is a bad thing? Personally, I like the possibility of having them, while I understand it can be pretty cluttered. In any case, we can expect UTF-8 issues (Ruby 1.8 vs Ruby 1.9), because there are many non-US characters that has uppercase and lowercase variants. External dependency will likely need to be introduced for Ruby 1.8. Does it really worth the change? -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Aug 14 10:27:47 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 12:27:47 +0200 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023B044.4010600@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B044.4010600@redhat.com> Message-ID: <20120814102747.GG2850@lzapx.brq.redhat.com> On Thu, Aug 09, 2012 at 01:42:44PM +0100, Dmitri Dolguikh wrote: > >The issue boils down to renaming of environments. If we are to use > >environment names for environment identification, we have to > >provide resolution for urls that are no longer valid (via 301). > >Doable, but additional work. > Additional work would include support for 301 responses on clients too. > But why would we need 301 responses? I mean, once you rename, the thing is done. Users are using CLI to interact with the backend, CLI takes care of translating labels/names to IDs. This is transparent to the users. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Aug 14 10:35:50 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 12:35:50 +0200 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023CB20.1050300@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023CB20.1050300@redhat.com> Message-ID: <20120814103550.GH2850@lzapx.brq.redhat.com> What Jesus describes here was already discussed some time ago on the list. In short: "Why not to introduce invariant labels and independent resource names". Like, for environment the HTML form would look like: New Environment Name: My Own Label I Can Change Label: my-own-label-i-can-change * Description: _____________ * - prefilled with javascript, lowercased, not changeable in future So users can change their "Name" but not "Label". But I am big fan of ID-whatever-you-want approach. Instead of using label, we would use simple numeric ID (there is no point of using UUIDs in Katello). Then we could use it everywhere: /environments/1234-my-environment/edit /api/environments/1234-my-environment/ /repos/9876-acme-corporation/1234-my-environment/packages/xyz.rpm There are few cases we need to use UUIDs directly (e.g. when we proxy to Candlepin), but these are rare. LZ On Thu, Aug 09, 2012 at 10:37:20AM -0400, Jesus Rodriguez wrote: > On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: > >On 09/08/12 01:20 PM, James Bowes wrote: > >>On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: > >>>Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for > >>>description of an issue with environment renaming. > >>> > >>>The immediate problems around environments: using of environment > >>>names and environment ids for identification of environments > >>>interchangeably. Using db ids for environment identification when > >>>not using environment names. > >>> > >>>To resolve these: > >>> - introduce environment uuids > >>> - update katello/katello cli to use uuids for environment identification > >>> - update repository naming to use environment uuids > >>> - update candlepin (this will include updates to schema, and > >>>resource controller) > >>> > >>-1 to UUIDs, for the same reason as has been discussed wrt pulp > >>repo labels. a url like: > >> > >>https://my-cdn.local/content/dev/rhel-server/i386/ > >> > >>is way more useful than: > >> > >>https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ > >> > >>not to mention, far more handsome! > >> > >>I'd rather see either immutable labels, or supporting renaming labels, > >>too. > >The issue boils down to renaming of environments. If we are to use > >environment names for environment identification, we have to provide > >resolution for urls that are no longer valid (via 301). Doable, but > >additional work. > > Labels are not necessarily environment names. Nothing says you have > to allow changing of the label. The label is just a human readable > identifier that is both easy to remember and use. > > While allowing renaming of labels is nice, I don't think it is > necessary. Even if you allow renaming the environment (the one shown > on the page). > > Think of the trac wiki url. If I create a new page I can call it > DesignLabelsEnvironments. But change the title on the page to be > 'Design of Labels for Environments'. Later I change the title to be: > 'Environment Label Design'. I don't have to change the page name. If > I want to I just create a new one. So if you want to allow label > renaming, then make it easy to create Environments. > > > >The idea of labels is interesting, but I don't think it would work out > >in the long-term: it would become stale after a rename or two > > The labels is what we used for RHN Satellite for Channels. It works > and a lot easier to remember. I can guarantee if you go with UUID > you *WILL* get someone asking why can't they pass in a name. And > using the actual name is bad because they will have spaces and might > have to be translated. Labels are again human readable. > > > > >With uuid's we won't need to support url redirection, they won't go > >stale. For user-friendliness we should provide querying by name with > >environment resource, smt. like: > > Nothing says you have to offer redirection with labels. If you make > them static and force users to create a new environment to get a new > label. > > So let's walk through the label rename then. You let a user change > the label of an environment. So now instead of being 'int-dev' it > becomes 'devel'. You could simply return 404 for anyone still using > 'int-dev' just like they were if they used the wrong uuid. > > If you *MUST* offer 301 'moved permanently' for the label then > you'll have to keep a list of labels. But I think that's going to be > more of a user issue. Because I know people will want to reuse label > names later. So I think most of them will be ok if you have a 404 > for a non existent label. > > IMO I don't think you need to offer label renames. Just allow > renaming of the environment for displaying on the UI. That way your > urls are easier to use, cli will be easier to use, and you'll get > less complaints. > > > > >GET > >http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper > > > >Less convenient, but easier to implement and maintain (from both user > >and developer perspective). > > I don't understand what your example is about. name should never be > used, it should be label: > > ../ACME_Corporation/environments?label=super-duper > > jesus > > -- > jesus m. rodriguez | jesusr at redhat.com > principal software engineer | irc: zeus > red hat systems management | 919.754.4413 (w) > rhce # 805008586930012 | 919.623.0080 (c) > +---------------------------------------------+ > | "Those who cannot remember the past | > | are condemned to repeat it." | > | -- George Santayana | > +---------------------------------------------+ > > _______________________________________________ > 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 Aug 14 10:46:43 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 12:46:43 +0200 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <5023D821.6080004@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B1D2.1010105@redhat.com> <5023B662.30105@redhat.com> <5023B704.6070602@redhat.com> <5023B9D1.6070207@redhat.com> <5023CEAF.6030701@redhat.com> <20120809151855.GA25069@bogey.xentower.nl> <5023D821.6080004@redhat.com> Message-ID: <20120814104642.GI2850@lzapx.brq.redhat.com> On Thu, Aug 09, 2012 at 04:32:49PM +0100, Dmitri Dolguikh wrote: > A published url *must* remain accessible, since you don't know where > and how it is being used. The only appropriate way to deal with this > situation is to provide a 301 redirect, which requires work > (including support on the client side). Says who? Can you show me a PRACTICAL reason for those 301 redirect? I think I am missing something. But I am still doing my e-mail backlock, ignore otherwise :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Tue Aug 14 10:47:36 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Tue, 14 Aug 2012 12:47:36 +0200 Subject: [katello-devel] Blog and Site Accounts In-Reply-To: <20120814091155.GE2850@lzapx.brq.redhat.com> References: <50217930.1020603@redhat.com> <20120814091155.GE2850@lzapx.brq.redhat.com> Message-ID: <502A2CC8.5040406@redhat.com> On 08/14/2012 11:11 AM, Lukas Zapletal wrote: > I still don't see the announcement in the blog, only testing post. Can > we add one?;-) Fixed. -- Miroslav Suchy Red Hat Systems Management Engineering From dmitri at redhat.com Tue Aug 14 10:49:45 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 11:49:45 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <20120814102747.GG2850@lzapx.brq.redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B044.4010600@redhat.com> <20120814102747.GG2850@lzapx.brq.redhat.com> Message-ID: <502A2D49.3030805@redhat.com> On 14/08/12 11:27 AM, Lukas Zapletal wrote: > On Thu, Aug 09, 2012 at 01:42:44PM +0100, Dmitri Dolguikh wrote: >>> The issue boils down to renaming of environments. If we are to use >>> environment names for environment identification, we have to >>> provide resolution for urls that are no longer valid (via 301). >>> Doable, but additional work. >> Additional work would include support for 301 responses on clients too. >> > But why would we need 301 responses? I mean, once you rename, the thing > is done. Users are using CLI to interact with the backend, CLI takes > care of translating labels/names to IDs. This is transparent to the > users. > The original resource still exists, only its location has changed. Since we cannot know how API clients use resource urls, how long they keep them around, etc, we either: have to return the resource, its new location, or notify the user that the resource in question has been deleted. That is the reason why http response codes differentiate between "not found" (404) and "permanently moved" (301). Think how many times you followed a link and got a 404, only to discover later that it still exists, but at a different URL? Let's not contribute to this problem. Katello cli is only one of the clients of our API. Please keep in mind that a generic Katello API client is a piece of software that may or may not interact with its users, or what information it persists locally. -d PS> on API design: (there was a video somewhere around too): http://www.infoq.com/articles/API-Design-Joshua-Bloch/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitri at redhat.com Tue Aug 14 10:53:32 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 11:53:32 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <20120814103550.GH2850@lzapx.brq.redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023CB20.1050300@redhat.com> <20120814103550.GH2850@lzapx.brq.redhat.com> Message-ID: <502A2E2C.5050106@redhat.com> On 14/08/12 11:35 AM, Lukas Zapletal wrote: > What Jesus describes here was already discussed some time ago on the > list. In short: "Why not to introduce invariant labels and independent > resource names". Like, for environment the HTML form would look like: > > New Environment > > Name: My Own Label I Can Change > Label: my-own-label-i-can-change * > Description: _____________ > > * - prefilled with javascript, lowercased, not changeable in future > > So users can change their "Name" but not "Label". > > But I am big fan of ID-whatever-you-want approach. Instead of using > label, we would use simple numeric ID (there is no point of using UUIDs > in Katello). Then we could use it everywhere: > > /environments/1234-my-environment/edit > /api/environments/1234-my-environment/ > /repos/9876-acme-corporation/1234-my-environment/packages/xyz.rpm > > There are few cases we need to use UUIDs directly (e.g. when we proxy to > Candlepin), but these are rare. UUID as in globally-unique-identifier. I assume that at some point more than one instance of Katello is going to be executed in parallel in a single environment? UUID's are much simpler and faster than state synchronization across multiple instances. -d > > LZ > > On Thu, Aug 09, 2012 at 10:37:20AM -0400, Jesus Rodriguez wrote: >> On 08/09/2012 08:39 AM, Dmitri Dolguikh wrote: >>> On 09/08/12 01:20 PM, James Bowes wrote: >>>> On Thu, Aug 09, 2012 at 12:34:57PM +0100, Dmitri Dolguikh wrote: >>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>> description of an issue with environment renaming. >>>>> >>>>> The immediate problems around environments: using of environment >>>>> names and environment ids for identification of environments >>>>> interchangeably. Using db ids for environment identification when >>>>> not using environment names. >>>>> >>>>> To resolve these: >>>>> - introduce environment uuids >>>>> - update katello/katello cli to use uuids for environment identification >>>>> - update repository naming to use environment uuids >>>>> - update candlepin (this will include updates to schema, and >>>>> resource controller) >>>>> >>>> -1 to UUIDs, for the same reason as has been discussed wrt pulp >>>> repo labels. a url like: >>>> >>>> https://my-cdn.local/content/dev/rhel-server/i386/ >>>> >>>> is way more useful than: >>>> >>>> https://my-cdn.local/content/abc123213-23423423-aaa123/rhel-server/i386/ >>>> >>>> not to mention, far more handsome! >>>> >>>> I'd rather see either immutable labels, or supporting renaming labels, >>>> too. >>> The issue boils down to renaming of environments. If we are to use >>> environment names for environment identification, we have to provide >>> resolution for urls that are no longer valid (via 301). Doable, but >>> additional work. >> Labels are not necessarily environment names. Nothing says you have >> to allow changing of the label. The label is just a human readable >> identifier that is both easy to remember and use. >> >> While allowing renaming of labels is nice, I don't think it is >> necessary. Even if you allow renaming the environment (the one shown >> on the page). >> >> Think of the trac wiki url. If I create a new page I can call it >> DesignLabelsEnvironments. But change the title on the page to be >> 'Design of Labels for Environments'. Later I change the title to be: >> 'Environment Label Design'. I don't have to change the page name. If >> I want to I just create a new one. So if you want to allow label >> renaming, then make it easy to create Environments. >> >> >>> The idea of labels is interesting, but I don't think it would work out >>> in the long-term: it would become stale after a rename or two >> The labels is what we used for RHN Satellite for Channels. It works >> and a lot easier to remember. I can guarantee if you go with UUID >> you *WILL* get someone asking why can't they pass in a name. And >> using the actual name is bad because they will have spaces and might >> have to be translated. Labels are again human readable. >> >>> With uuid's we won't need to support url redirection, they won't go >>> stale. For user-friendliness we should provide querying by name with >>> environment resource, smt. like: >> Nothing says you have to offer redirection with labels. If you make >> them static and force users to create a new environment to get a new >> label. >> >> So let's walk through the label rename then. You let a user change >> the label of an environment. So now instead of being 'int-dev' it >> becomes 'devel'. You could simply return 404 for anyone still using >> 'int-dev' just like they were if they used the wrong uuid. >> >> If you *MUST* offer 301 'moved permanently' for the label then >> you'll have to keep a list of labels. But I think that's going to be >> more of a user issue. Because I know people will want to reuse label >> names later. So I think most of them will be ok if you have a 404 >> for a non existent label. >> >> IMO I don't think you need to offer label renames. Just allow >> renaming of the environment for displaying on the UI. That way your >> urls are easier to use, cli will be easier to use, and you'll get >> less complaints. >> >>> GET >>> http://localhost/katello/api/organizations/ACME_Corporation/environments?name=super-duper >>> >>> Less convenient, but easier to implement and maintain (from both user >>> and developer perspective). >> I don't understand what your example is about. name should never be >> used, it should be label: >> >> ../ACME_Corporation/environments?label=super-duper >> >> jesus >> >> -- >> jesus m. rodriguez | jesusr at redhat.com >> principal software engineer | irc: zeus >> red hat systems management | 919.754.4413 (w) >> rhce # 805008586930012 | 919.623.0080 (c) >> +---------------------------------------------+ >> | "Those who cannot remember the past | >> | are condemned to repeat it." | >> | -- George Santayana | >> +---------------------------------------------+ >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From jpazdziora at redhat.com Tue Aug 14 11:05:11 2012 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 14 Aug 2012 13:05:11 +0200 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <502A2D49.3030805@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B044.4010600@redhat.com> <20120814102747.GG2850@lzapx.brq.redhat.com> <502A2D49.3030805@redhat.com> Message-ID: <20120814110511.GC11232@redhat.com> On Tue, Aug 14, 2012 at 11:49:45AM +0100, Dmitri Dolguikh wrote: > > The original resource still exists, only its location has changed. > Since we cannot know how API clients use resource urls, how long > they keep them around, etc, we either: have to return the resource, > its new location, or notify the user that the resource in question > has been deleted. That is the reason why http response codes > differentiate between "not found" (404) and "permanently moved" > (301). > Think how many times you followed a link and got a 404, only to > discover later that it still exists, but at a different URL? Let's > not contribute to this problem. How do you propose to solve situation when you have a resource prod and it gets renamed to prod-old and then the admin wants to create new resource named prod ? Will you allow them to create that resource with this name (breaking the expectation because the new prod content might be completely different), or will the (now) prod-old occupy the prod name forever? What is the difference between renaming prod to prod-old, and removing prod and creating prod-old with the same content? The labels are just a human readable names assigned to resources. If the admin on the server decides that the prod label should now point to different object, why stop them? By the way, why not use a dual addressing scheme -- you can have id/the-UUID-or-any-other-generated-non-semantic-id and label/prod point to the same resource? Here the first will likely be used internally and could be used by the super careful user who want to protect from any label manipulation, and the second one would be used by users who trust the admin and they always want to use their production environment, no matter if it was just created from scratch or renamed three times in the mean time. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat From lzap at redhat.com Tue Aug 14 11:07:56 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 13:07:56 +0200 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <50297C0C.2080501@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> Message-ID: <20120814110756.GJ2850@lzapx.brq.redhat.com> On Mon, Aug 13, 2012 at 03:13:32PM -0700, Michael McCune wrote: > I'd much rather do the following to ensure our yum config values on > the clients are readable and sacrifice i18n in order to do so: > > 1) use an ASCII label for reops if we are going to really implement > repo renaming > 2) force Org (possibly), Env and Repo names to be ASCII > 3) Any existing utf-8 data for these values is left alone and users > are warned we do not support this, or we encode it in some way such > that it works > > Is renaming environments really worth all this effort? If so, lets > not sacrifice our usability at the client level just to support it. > +1 I would not say Cliff's recommendation was defeated by UTF-8. The key for labels is to use ASCII there. Being Czech, I very often see websites "fixing" my content name into ASCII labels and using them in URLs. Some websites do this better automatically, some are worse. But the idea remains the same. Example for "?lu?ou?k? k??". Good translation: "zlutoucky kun". Bad one: "?lu?ou?k? k??" or "luouk-k" or variations :-) Unfortunately this can be applied only for characters with UNICODE normal forms. For example, Chinese can't be translated that easy way and user would need to put his alphanum label on his own. Penalty for renaming feature? No, even Chinese admins would like to have nice yum URLs and repo names. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Tue Aug 14 11:17:10 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 12:17:10 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <50297C0C.2080501@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> Message-ID: <502A33B6.5090606@redhat.com> On 13/08/12 11:13 PM, Mike McCune wrote: > On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote: >> On 13/08/12 03:57 PM, Justin Sherrill wrote: >>> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >>>> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>>>> This is a summary of the thread started at >>>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>>>> >>>>>> >>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>> details of the issue with environment renaming. >>>>>> >>>>>> Quite a few folks suggested using of an immutable label instead of >>>>>> environment name, but at the end the idea was defeated by a comment >>>>>> from Cliff Perry about users from locales using non-ascii-based >>>>>> character sets. >>>>>> Another issue that was discovered was the migration of already >>>>>> established environments from current version of Katello to the >>>>>> version containing the fix. My current thinking is to use >>>>>> environment name value as uuid for "legacy" environments. This >>>>>> would significantly simply upgrade, as there will be no need to >>>>>> regenerate entitlement certificates, etc. >>>>>> >>>>>> Katello: >>>>>> - introduce environment uuids (update db schema, model, etc) >>>>>> - update candlepin (this will include updates to schema, and >>>>>> resource controller) >>>>>> - update katello/katello cli to use uuids for environment >>>>>> identification >>>>>> - update repository-related functionality to use environment uuids >>>>>> - figure out/create migration from 1.0 to current >>>>>> >>>>>> Bryan, everything minus the migration bit is probably a couple days >>>>>> worth of work. Should I create a new story, or I can start on this >>>>>> right away? >>>>>> >>>>>> -d >>>>>> >>>>>> _______________________________________________ >>>>>> katello-devel mailing list >>>>>> katello-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>> Any idea what the redhat.repo file will look like with numerical >>>>> ids? Or yum repolist ? >>>> Same as now, but with environment uuids instead on environment names. >>>> -d >>> >> Apologies, I didn't understand the question. The latter. >> -d >>> So >>> >>> [123456] >>> name=123456 >>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>> >>> or >>> >>> [123456] >>> name=Red Hat Enterprise Linux Server 6 RPMS >>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>> >>> >>> ? >>> > > > and this really blows for our users, IMHO. You go from a relatively > readable and clear yum configuration file that a sysadmin can look at > quickly and understand: > > [ACME_Corporation_zoo_zoorepo] > name = zoorepo > baseurl = > https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo > enabled = 1 > gpgcheck = 1 > sslverify = 1 > sslcacert = /etc/rhsm/ca/candlepin-local.pem > sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem > sslclientcert = /etc/pki/entitlement/3783882558646362292.pem > > to: > > [313024c0-c7bd-012f-d852-1803734d16c4] > name = zoorepo > baseurl = > https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 > enabled = 1 > gpgcheck = 1 > sslverify = 1 > sslcacert = /etc/rhsm/ca/candlepin-local.pem > sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem > sslclientcert = /etc/pki/entitlement/3783882558646362292.pem That's not what I meant. I was thinking to use repo name in the section heading, but uuid in the url. So, using your example, it's going to be: [ACME_Corporation_zoo_zoorepo] name = zoorepo baseurl = https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 enabled = 1 gpgcheck = 1 sslverify = 1 sslcacert = /etc/rhsm/ca/candlepin-local.pem sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem sslclientcert = /etc/pki/entitlement/3783882558646362292.pem while url has to stay in ascii, I don't think there's the same requirement for yum repo config file? > > > now as a user you have no idea what env+repo you are really looking > at. You know it is the zoorepo in the locker for ACME_Corporation but > you would have to know what IDs the environments have to even begin to > figure out what content you are pointing at. > > we are taking something readable and turning it into a generated > configuration value that our sysadmins will *really* hate. I think > the changes outlined above while clear are a definite step backwards > in functionality for Katello. The price to pay to support Env > renaming is *not* worth it if we implement it as such. Lets not take > this decision likely because one of the primary touch points at the > client is the redhat.repo file that lists the content you are pulling > down. > > I'd much rather do the following to ensure our yum config values on > the clients are readable and sacrifice i18n in order to do so: > > 1) use an ASCII label for reops if we are going to really implement > repo renaming > 2) force Org (possibly), Env and Repo names to be ASCII > 3) Any existing utf-8 data for these values is left alone and users > are warned we do not support this, or we encode it in some way such > that it works Does my example above resolve the questions you had? > > > Is renaming environments really worth all this effort? If so, lets > not sacrifice our usability at the client level just to support it. Personally, I'm not convinced that it's worth it, since we could replicate renaming with create environment/move system[s] (although we need bulk moving). This doesn't resolve the issue with environment names in urls however. -d > > Mike > > > > > From dmitri at redhat.com Tue Aug 14 11:27:52 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 12:27:52 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <20120814110756.GJ2850@lzapx.brq.redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <20120814110756.GJ2850@lzapx.brq.redhat.com> Message-ID: <502A3638.7030607@redhat.com> On 14/08/12 12:07 PM, Lukas Zapletal wrote: > On Mon, Aug 13, 2012 at 03:13:32PM -0700, Michael McCune wrote: >> I'd much rather do the following to ensure our yum config values on >> the clients are readable and sacrifice i18n in order to do so: >> >> 1) use an ASCII label for reops if we are going to really implement >> repo renaming >> 2) force Org (possibly), Env and Repo names to be ASCII >> 3) Any existing utf-8 data for these values is left alone and users >> are warned we do not support this, or we encode it in some way such >> that it works >> >> Is renaming environments really worth all this effort? If so, lets >> not sacrifice our usability at the client level just to support it. >> > +1 > > I would not say Cliff's recommendation was defeated by UTF-8. The key > for labels is to use ASCII there. Being Czech, I very often see websites > "fixing" my content name into ASCII labels and using them in URLs. Some > websites do this better automatically, some are worse. But the idea > remains the same. > > Example for "?lu?ou?k? k??". > > Good translation: "zlutoucky kun". > > Bad one: "?lu?ou?k? k??" or "luouk-k" or variations :-) > > Unfortunately this can be applied only for characters with UNICODE > normal forms. For example, Chinese can't be translated that easy way and > user would need to put his alphanum label on his own. Penalty for > renaming feature? No, even Chinese admins would like to have nice yum > URLs and repo names. My understanding is that this only applies to urls, not yum-metadata. See my example in reply to Mike's email. Forcing ascii-only characters for user-input in a field that supposed to help users keep track of their stuff in an otherwise localized application, is a terrible, terrible choice (if not a slap in user's face). The bottom line for me is if " *You can't please everyone so aim to displease everyone equally*". -d > LZ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lzap at redhat.com Tue Aug 14 11:35:43 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 13:35:43 +0200 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <502A2D49.3030805@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B044.4010600@redhat.com> <20120814102747.GG2850@lzapx.brq.redhat.com> <502A2D49.3030805@redhat.com> Message-ID: <20120814113542.GL2850@lzapx.brq.redhat.com> > The original resource still exists, only its location has changed. > Since we cannot know how API clients use resource urls, how long > they keep them around, etc, we either: have to return the resource, > its new location, or notify the user that the resource in question > has been deleted. That is the reason why http response codes > differentiate between "not found" (404) and "permanently moved" > (301). > Think how many times you followed a link and got a 404, only to > discover later that it still exists, but at a different URL? Let's > not contribute to this problem. This plan has one little snag - 99 per cent of our API clients will be just some scripts that will totally ignore 301 or whatever. They just work or not. This is the reality. It's the REST that makes you feel you are doing something wrong, while everything is perfect. I could take your opinion and apply it on a regular API. As an example you can take any API from UNIX that has some kind of a get_value("value_name") function. Or Java for example is better, method like getOptionValue("name"). Good Java API designer introduces ValueNotFound exception which is thrown when value does not exist. Poor Java API programmer just return null. I agree with you having 404 is a good thing and we do that already. So far so good. But tell me, how many API designers introduce ValueRenamedException that is thrown when someone renamed option value? I have never seen this. In our case it should be unchecked exception, because forcing users to catch this would be suicide. Now, don't get me wrong, but this is what I call over-engineering. Taking one concept (from HTTP) and applying it somewhere else. I can imagine how 404/301 is annoying *on the web*, but not in case of API over HTTP. Resource was there, it is not. That's the simple fact API consumers will need to deal with. -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Tue Aug 14 11:37:06 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 12:37:06 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <20120814110511.GC11232@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B044.4010600@redhat.com> <20120814102747.GG2850@lzapx.brq.redhat.com> <502A2D49.3030805@redhat.com> <20120814110511.GC11232@redhat.com> Message-ID: <502A3862.7040703@redhat.com> On 14/08/12 12:05 PM, Jan Pazdziora wrote: > On Tue, Aug 14, 2012 at 11:49:45AM +0100, Dmitri Dolguikh wrote: >> The original resource still exists, only its location has changed. >> Since we cannot know how API clients use resource urls, how long >> they keep them around, etc, we either: have to return the resource, >> its new location, or notify the user that the resource in question >> has been deleted. That is the reason why http response codes >> differentiate between "not found" (404) and "permanently moved" >> (301). >> Think how many times you followed a link and got a 404, only to >> discover later that it still exists, but at a different URL? Let's >> not contribute to this problem. > How do you propose to solve situation when you have a resource > > prod > > and it gets renamed to > > prod-old > > and then the admin wants to create new resource named > > prod > > ? Will you allow them to create that resource with this name (breaking > the expectation because the new prod content might be completely > different), or will the (now) prod-old occupy the prod name forever? I would not allow the user to create new resource named 'prod', as it would introduce ambiguity. > > What is the difference between renaming prod to prod-old, and removing > prod and creating prod-old with the same content? > > The labels are just a human readable names assigned to resources. labels remain human-readable only in a subset of all locales. With a completely non-ascii based locale, the labels will be anything but human readable. Think Russian, Chinese, Japanese, Korean, etc. > If > the admin on the server decides that the > > prod > > label should now point to different object, why stop them? Because something, somewhere is possibly using the url before change to point to the original resource. Now it's pointing to a completely different resource, and there's no way to notify the user of the change. > > By the way, why not use a dual addressing scheme -- you can have > > id/the-UUID-or-any-other-generated-non-semantic-id > > and > > label/prod > > point to the same resource? Here the first will likely be used > internally and could be used by the super careful user who want to > protect from any label manipulation, and the second one would be used > by users who trust the admin and they always want to use their > production environment, no matter if it was just created from scratch > or renamed three times in the mean time. Why introduce TWO ways to identify a resource, one of them non-uniquely, if we can use a url + search for resource based on metadata (labels, names, what have you). -d > From lzap at redhat.com Tue Aug 14 11:42:16 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 13:42:16 +0200 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A3638.7030607@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <20120814110756.GJ2850@lzapx.brq.redhat.com> <502A3638.7030607@redhat.com> Message-ID: <20120814114216.GM2850@lzapx.brq.redhat.com> On Tue, Aug 14, 2012 at 12:27:52PM +0100, Dmitri Dolguikh wrote: > My understanding is that this only applies to urls, not > yum-metadata. See my example in reply to Mike's email. > What we need to deal with: - name of the repo file - repository name (the thing between brackets) - fancy repository name (name=xyz) - URL That means we somehow need a label. We are currently stripping out all non-ASCII characters in our codebase. So we already "generate" labels on our own. Therefore its logical to discuss this while we are discussing introduction of labels. That's the same thing. > Forcing ascii-only characters for user-input in a field that > supposed to help users keep track of their stuff in an otherwise > localized application, is a terrible, terrible choice (if not a slap > in user's face). The bottom line for me is if " *You can't please > everyone so aim to displease everyone equally*". What we recommend would be pretty seamless and automatic. Labels would be pre-defined from (UNICODE) resource names. No need to worry about usability, users could totally ignore label field if they are happy with the value. But those who do not use latin character set would be more than happy to define their own labels to customize (horribly generated) URLs in these cases. -- Later, Lukas "lzap" Zapletal #katello #systemengine From jpazdziora at redhat.com Tue Aug 14 11:57:25 2012 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 14 Aug 2012 13:57:25 +0200 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <502A3862.7040703@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B044.4010600@redhat.com> <20120814102747.GG2850@lzapx.brq.redhat.com> <502A2D49.3030805@redhat.com> <20120814110511.GC11232@redhat.com> <502A3862.7040703@redhat.com> Message-ID: <20120814115725.GE11232@redhat.com> On Tue, Aug 14, 2012 at 12:37:06PM +0100, Dmitri Dolguikh wrote: > On 14/08/12 12:05 PM, Jan Pazdziora wrote: > >How do you propose to solve situation when you have a resource > > > > prod > > > >and it gets renamed to > > > > prod-old > > > >and then the admin wants to create new resource named > > > > prod > > > >? Will you allow them to create that resource with this name (breaking > >the expectation because the new prod content might be completely > >different), or will the (now) prod-old occupy the prod name forever? > I would not allow the user to create new resource named 'prod', as > it would introduce ambiguity. What is the difference between renaming prod to prod-old, and removing prod and creating prod-old with the same content? > >The labels are just a human readable names assigned to resources. > labels remain human-readable only in a subset of all locales. With a > completely non-ascii based locale, the labels will be anything but > human readable. Think Russian, Chinese, Japanese, Korean, etc. It's still better for a Russion user to have environment called "prod" in US-ASCII than to be forced to spell "29f920a8ee9f829b8cdd8" everywhere. > >If > >the admin on the server decides that the > > > > prod > > > >label should now point to different object, why stop them? > Because something, somewhere is possibly using the url before change > to point to the original resource. Now it's pointing to a completely > different resource, and there's no way to notify the user of the > change. If the admin completely changes attributes / internals / content of that resource, it will also be pointing to different resource, semantics-wise. > >point to the same resource? Here the first will likely be used > >internally and could be used by the super careful user who want to > >protect from any label manipulation, and the second one would be used > >by users who trust the admin and they always want to use their > >production environment, no matter if it was just created from scratch > >or renamed three times in the mean time. > > Why introduce TWO ways to identify a resource, one of them > non-uniquely, if we can use a url + search for resource based on > metadata (labels, names, what have you). Well sure, /something/search?label=prod is just as good as /something/label/prod -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat From dmitri at redhat.com Tue Aug 14 11:58:32 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 12:58:32 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <20120814114216.GM2850@lzapx.brq.redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <20120814110756.GJ2850@lzapx.brq.redhat.com> <502A3638.7030607@redhat.com> <20120814114216.GM2850@lzapx.brq.redhat.com> Message-ID: <502A3D68.6030605@redhat.com> On 14/08/12 12:42 PM, Lukas Zapletal wrote: > On Tue, Aug 14, 2012 at 12:27:52PM +0100, Dmitri Dolguikh wrote: >> My understanding is that this only applies to urls, not >> yum-metadata. See my example in reply to Mike's email. >> > What we need to deal with: > > - name of the repo file > - repository name (the thing between brackets) > - fancy repository name (name=xyz) > - URL > > That means we somehow need a label. We are currently stripping out all > non-ASCII characters in our codebase. So we already "generate" labels on > our own. Therefore its logical to discuss this while we are discussing > introduction of labels. That's the same thing. This whole conversation is only about using human-readable piece of information in the url. Nothing else. > >> Forcing ascii-only characters for user-input in a field that >> supposed to help users keep track of their stuff in an otherwise >> localized application, is a terrible, terrible choice (if not a slap >> in user's face). The bottom line for me is if " *You can't please >> everyone so aim to displease everyone equally*". > What we recommend would be pretty seamless and automatic. Labels would > be pre-defined from (UNICODE) resource names. No need to worry about > usability, users could totally ignore label field if they are happy with > the value. But those who do not use latin character set would be more > than happy to define their own labels to customize (horribly generated) > URLs in these cases. What purpose does this serve? In a general case we cannot guarantee human-readability of the url. User-facing agents can handle the user-friendly bit by showing all kinds of meta-data. -d > From hbrock at redhat.com Tue Aug 14 12:00:53 2012 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 14 Aug 2012 08:00:53 -0400 Subject: [katello-devel] RFC: Notification system In-Reply-To: <502A1CEC.9050506@redhat.com> References: <20120813212655.GA21991@mawagner-desktop.usersys.redhat.com> <502A1CEC.9050506@redhat.com> Message-ID: <20120814120052.GG4597@redhat.com> (cc-ing katello-devel) On Tue, Aug 14, 2012 at 10:39:56AM +0100, Dmitri Dolguikh wrote: > On 13/08/12 10:26 PM, Matt Wagner wrote: > >Hi folks, > > > >I've been dwelling on user notifications a bit more. #3623 implies this > >functionality, and there are some comments visible here: > >https://www.aeolusproject.org/redmine/issues/3623 > > > >We have some licensing difference between our projects (grr!), > Not sure if this is a conversation for this mailing list, but was > there a conversation about licensing of projects and if we could all > use the same license? > > -d Yeah this is actually a good thing to bring up. Aeolus moved to the Apache license from GPL v2+about 18 months ago for various reasons -- Deltacloud is an Apache project, ASL seems more familiar/comfortable to the Ruby world, etc. If Katello upstream and associated projects are interested, I think it would be beneficial to have everyone on the Apache license (and obviously also make code sharing a bit simpler). Given that we can always ask Katello to dual-license code we want to share between projects, it's not that big of a deal either way. Take care, --Hugh > > >but it > >might make sense to see about borrowing the Katello implementation > >rather than reinventing this from the ground up. They already support > >persistent notifications which can be sent to multiple users, though > >we'd have to add email notifications and perhaps notification > >preferences. I added a couple of screenshots as well. > > > >Let me know what you think -- does this seem like a good approach for us > >to follow? > > > >-- Matt > > -- == 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 Tue Aug 14 12:12:15 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 08:12:15 -0400 Subject: [katello-devel] RFC: Notification system In-Reply-To: <20120814120052.GG4597@redhat.com> References: <20120813212655.GA21991@mawagner-desktop.usersys.redhat.com> <502A1CEC.9050506@redhat.com> <20120814120052.GG4597@redhat.com> Message-ID: <502A409F.5090001@redhat.com> On 08/14/2012 08:00 AM, Hugh Brock wrote: > (cc-ing katello-devel) > > On Tue, Aug 14, 2012 at 10:39:56AM +0100, Dmitri Dolguikh wrote: >> On 13/08/12 10:26 PM, Matt Wagner wrote: >>> Hi folks, >>> >>> I've been dwelling on user notifications a bit more. #3623 implies this >>> functionality, and there are some comments visible here: >>> https://www.aeolusproject.org/redmine/issues/3623 >>> >>> We have some licensing difference between our projects (grr!), >> Not sure if this is a conversation for this mailing list, but was >> there a conversation about licensing of projects and if we could all >> use the same license? >> >> -d > > Yeah this is actually a good thing to bring up. > > Aeolus moved to the Apache license from GPL v2+about 18 months ago for various > reasons -- Deltacloud is an Apache project, ASL seems more > familiar/comfortable to the Ruby world, etc. > > If Katello upstream and associated projects are interested, I think it > would be beneficial to have everyone on the Apache license (and > obviously also make code sharing a bit simpler). Given that we can > always ask Katello to dual-license code we want to share between > projects, it's not that big of a deal either way. > > Take care, > --Hugh > Will talk about licensing. Is there a definitive "Why ASL is better? Or is it just because Apache are bullies? Perhaps katello should just go MIT? On notifications, the other thing I would like to see (ideally a shared service) is the ability to send email notificaitons out to one or more users based on events. I would assume templating, batching, and some sort of data injection. We have that on the errata side (jomara is looking at it). Perhaps we can have folks co-develop that part too. -- bk From hbrock at redhat.com Tue Aug 14 12:16:34 2012 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 14 Aug 2012 08:16:34 -0400 Subject: [katello-devel] RFC: Notification system In-Reply-To: <502A409F.5090001@redhat.com> References: <20120813212655.GA21991@mawagner-desktop.usersys.redhat.com> <502A1CEC.9050506@redhat.com> <20120814120052.GG4597@redhat.com> <502A409F.5090001@redhat.com> Message-ID: <20120814121634.GJ4597@redhat.com> On Tue, Aug 14, 2012 at 08:12:15AM -0400, Bryan Kearney wrote: > On 08/14/2012 08:00 AM, Hugh Brock wrote: > >(cc-ing katello-devel) > > > >On Tue, Aug 14, 2012 at 10:39:56AM +0100, Dmitri Dolguikh wrote: > >>On 13/08/12 10:26 PM, Matt Wagner wrote: > >>>Hi folks, > >>> > >>>I've been dwelling on user notifications a bit more. #3623 implies this > >>>functionality, and there are some comments visible here: > >>>https://www.aeolusproject.org/redmine/issues/3623 > >>> > >>>We have some licensing difference between our projects (grr!), > >>Not sure if this is a conversation for this mailing list, but was > >>there a conversation about licensing of projects and if we could all > >>use the same license? > >> > >>-d > > > >Yeah this is actually a good thing to bring up. > > > >Aeolus moved to the Apache license from GPL v2+about 18 months ago for various > >reasons -- Deltacloud is an Apache project, ASL seems more > >familiar/comfortable to the Ruby world, etc. > > > >If Katello upstream and associated projects are interested, I think it > >would be beneficial to have everyone on the Apache license (and > >obviously also make code sharing a bit simpler). Given that we can > >always ask Katello to dual-license code we want to share between > >projects, it's not that big of a deal either way. > > > >Take care, > >--Hugh > > > > Will talk about licensing. Is there a definitive "Why ASL is better? > Or is it just because Apache are bullies? Perhaps katello should > just go MIT? IIUC ASL and MIT are ~ compatible so I think you could do either. The main benefits we were chasing with ASL were 1. fewer restrictions on re-use of 3rd party contributions, and 2. no requirement to release the source for the product. > On notifications, the other thing I would like to see (ideally a > shared service) is the ability to send email notificaitons out to > one or more users based on events. I would assume templating, > batching, and some sort of data injection. We have that on the > errata side (jomara is looking at it). Perhaps we can have folks > co-develop that part too. Yeah this is a very good idea I think. --H -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From dmitri at redhat.com Tue Aug 14 12:19:10 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 13:19:10 +0100 Subject: [katello-devel] Modelling of environments, products, etc in Katello (related to renaming of environments) In-Reply-To: <20120814115725.GE11232@redhat.com> References: <5023A061.40507@redhat.com> <20120809122055.GH46364@pipboy.redhat.com> <5023AF9C.3030400@redhat.com> <5023B044.4010600@redhat.com> <20120814102747.GG2850@lzapx.brq.redhat.com> <502A2D49.3030805@redhat.com> <20120814110511.GC11232@redhat.com> <502A3862.7040703@redhat.com> <20120814115725.GE11232@redhat.com> Message-ID: <502A423E.2050004@redhat.com> On 14/08/12 12:57 PM, Jan Pazdziora wrote: > On Tue, Aug 14, 2012 at 12:37:06PM +0100, Dmitri Dolguikh wrote: >> On 14/08/12 12:05 PM, Jan Pazdziora wrote: >>> How do you propose to solve situation when you have a resource >>> >>> prod >>> >>> and it gets renamed to >>> >>> prod-old >>> >>> and then the admin wants to create new resource named >>> >>> prod >>> >>> ? Will you allow them to create that resource with this name (breaking >>> the expectation because the new prod content might be completely >>> different), or will the (now) prod-old occupy the prod name forever? >> I would not allow the user to create new resource named 'prod', as >> it would introduce ambiguity. > What is the difference between renaming prod to prod-old, and removing > prod and creating prod-old with the same content? the difference is going to be subtle. In a general case you can't create a resource that's identical to another one, some things are going to differ - id's for example. In that light: moving, semantically assumes continuation. Deletion and re-creation does not. -d > >>> The labels are just a human readable names assigned to resources. >> labels remain human-readable only in a subset of all locales. With a >> completely non-ascii based locale, the labels will be anything but >> human readable. Think Russian, Chinese, Japanese, Korean, etc. > It's still better for a Russion user to have environment called > "prod" in US-ASCII than to be forced to spell "29f920a8ee9f829b8cdd8" > everywhere. Where's everywhere? What if the language doesn't translate to latin ascii as easily as Russian? > >>> If >>> the admin on the server decides that the >>> >>> prod >>> >>> label should now point to different object, why stop them? >> Because something, somewhere is possibly using the url before change >> to point to the original resource. Now it's pointing to a completely >> different resource, and there's no way to notify the user of the >> change. > If the admin completely changes attributes / internals / content > of that resource, it will also be pointing to different resource, > semantics-wise. I'd argue no matter how extensively changed, some attributes are going to stay constant (we use them for identification) - there's a continuity in resource's life. One can potentially track all the changes of a given resource by looking at its audit trail. > >>> point to the same resource? Here the first will likely be used >>> internally and could be used by the super careful user who want to >>> protect from any label manipulation, and the second one would be used >>> by users who trust the admin and they always want to use their >>> production environment, no matter if it was just created from scratch >>> or renamed three times in the mean time. >> Why introduce TWO ways to identify a resource, one of them >> non-uniquely, if we can use a url + search for resource based on >> metadata (labels, names, what have you). > Well sure, > > /something/search?label=prod > > is just as good as > > /something/label/prod I can't judge if those are equally good, but semantically they are different: the former doesn't provide any guarantees as to uniqueness or availability of a resource matching the query. The latter states that there is one. -d From bkearney at redhat.com Tue Aug 14 12:23:29 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 08:23:29 -0400 Subject: [katello-devel] Licensing? Message-ID: <502A4341.2000107@redhat.com> OK... Katello is GPLV2, and Aeolus is ASL. It would be nice to make it easy to share code, and we know Apache is kinda a big bully around their fancy license. We can not move to GPLV3 (like Foreman) since that is no better [1]. Couple of options: 1) Katello can switch to either ASL, or MIT. 2) Katello could dual license current and ASL/MIT 3) Do nothing I dont think we need to worry about any of the backend projects, just the rails parts. -- bk [1] http://www.apache.org/licenses/GPL-compatibility.html From jbowes at redhat.com Tue Aug 14 12:29:31 2012 From: jbowes at redhat.com (James Bowes) Date: Tue, 14 Aug 2012 09:29:31 -0300 Subject: [katello-devel] Licensing? In-Reply-To: <502A4341.2000107@redhat.com> References: <502A4341.2000107@redhat.com> Message-ID: <20120814122930.GH3696@pipboy.redhat.com> On Tue, Aug 14, 2012 at 08:23:29AM -0400, Bryan Kearney wrote: > OK... > > Katello is GPLV2, and Aeolus is ASL. It would be nice to make it > easy to share code, and we know Apache is kinda a big bully around > their fancy license. We can not move to GPLV3 (like Foreman) since > that is no better [1]. Couple of options: > > 1) Katello can switch to either ASL, or MIT. > 2) Katello could dual license current and ASL/MIT > 3) Do nothing > If you are considering dual licensing, I would say while you're at it, move the code to be GPLv2 or any later version, at the user's option. > I dont think we need to worry about any of the backend projects, > just the rails parts. > > -- bk > > > > [1] http://www.apache.org/licenses/GPL-compatibility.html > > _______________________________________________ > 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 jesusr at redhat.com Tue Aug 14 12:33:51 2012 From: jesusr at redhat.com (jesus m. rodriguez) Date: Tue, 14 Aug 2012 08:33:51 -0400 Subject: [katello-devel] Licensing? In-Reply-To: <502A4341.2000107@redhat.com> References: <502A4341.2000107@redhat.com> Message-ID: <502A45AF.8030500@redhat.com> On 08/14/2012 08:23 AM, Bryan Kearney wrote: > OK... > > Katello is GPLV2, and Aeolus is ASL. It would be nice to make it easy to > share code, and we know Apache is kinda a big bully around their fancy > license. We can not move to GPLV3 (like Foreman) since that is no better > [1]. Couple of options: > > 1) Katello can switch to either ASL, or MIT. > 2) Katello could dual license current and ASL/MIT > 3) Do nothing > > I dont think we need to worry about any of the backend projects, just > the rails parts. -1 to 1 0 to 2 +1 to 3 jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ From jsherril at redhat.com Tue Aug 14 12:41:46 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 14 Aug 2012 08:41:46 -0400 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A33B6.5090606@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> Message-ID: <502A478A.8030100@redhat.com> On 08/14/2012 07:17 AM, Dmitri Dolguikh wrote: > On 13/08/12 11:13 PM, Mike McCune wrote: >> On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote: >>> On 13/08/12 03:57 PM, Justin Sherrill wrote: >>>> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >>>>> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>>>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>>>>> This is a summary of the thread started at >>>>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>>>>> >>>>>>> >>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>> details of the issue with environment renaming. >>>>>>> >>>>>>> Quite a few folks suggested using of an immutable label instead of >>>>>>> environment name, but at the end the idea was defeated by a comment >>>>>>> from Cliff Perry about users from locales using non-ascii-based >>>>>>> character sets. >>>>>>> Another issue that was discovered was the migration of already >>>>>>> established environments from current version of Katello to the >>>>>>> version containing the fix. My current thinking is to use >>>>>>> environment name value as uuid for "legacy" environments. This >>>>>>> would significantly simply upgrade, as there will be no need to >>>>>>> regenerate entitlement certificates, etc. >>>>>>> >>>>>>> Katello: >>>>>>> - introduce environment uuids (update db schema, model, etc) >>>>>>> - update candlepin (this will include updates to schema, and >>>>>>> resource controller) >>>>>>> - update katello/katello cli to use uuids for environment >>>>>>> identification >>>>>>> - update repository-related functionality to use environment >>>>>>> uuids >>>>>>> - figure out/create migration from 1.0 to current >>>>>>> >>>>>>> Bryan, everything minus the migration bit is probably a couple days >>>>>>> worth of work. Should I create a new story, or I can start on this >>>>>>> right away? >>>>>>> >>>>>>> -d >>>>>>> >>>>>>> _______________________________________________ >>>>>>> katello-devel mailing list >>>>>>> katello-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>> Any idea what the redhat.repo file will look like with numerical >>>>>> ids? Or yum repolist ? >>>>> Same as now, but with environment uuids instead on environment names. >>>>> -d >>>> >>> Apologies, I didn't understand the question. The latter. >>> -d >>>> So >>>> >>>> [123456] >>>> name=123456 >>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>> >>>> or >>>> >>>> [123456] >>>> name=Red Hat Enterprise Linux Server 6 RPMS >>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>> >>>> >>>> ? >>>> >> >> >> and this really blows for our users, IMHO. You go from a relatively >> readable and clear yum configuration file that a sysadmin can look at >> quickly and understand: >> >> [ACME_Corporation_zoo_zoorepo] >> name = zoorepo >> baseurl = >> https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo >> enabled = 1 >> gpgcheck = 1 >> sslverify = 1 >> sslcacert = /etc/rhsm/ca/candlepin-local.pem >> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >> >> to: >> >> [313024c0-c7bd-012f-d852-1803734d16c4] >> name = zoorepo >> baseurl = >> https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 >> enabled = 1 >> gpgcheck = 1 >> sslverify = 1 >> sslcacert = /etc/rhsm/ca/candlepin-local.pem >> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem > > That's not what I meant. I was thinking to use repo name in the > section heading, but uuid in the url. So, using your example, it's > going to be: > > [ACME_Corporation_zoo_zoorepo] > name = zoorepo > baseurl = > https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 > > enabled = 1 > gpgcheck = 1 > sslverify = 1 > sslcacert = /etc/rhsm/ca/candlepin-local.pem > sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem > sslclientcert = /etc/pki/entitlement/3783882558646362292.pem > > while url has to stay in ascii, I don't think there's the same > requirement for yum repo config file? I believe (and someone please correct me if I'm wrong) that the only thing that can contain non-ascii characters is the name. The url & Id (ACME_Corporation_zoo_zoorepo in the above example) has to be ascii as well. The name itself can contain any crazy kind of letter you want. I'm basing this on recent discussion with pulp, but someone please correct me if I'm wrong, as I could have misunderstood that discussion. -Justin >> >> >> now as a user you have no idea what env+repo you are really looking >> at. You know it is the zoorepo in the locker for ACME_Corporation >> but you would have to know what IDs the environments have to even >> begin to figure out what content you are pointing at. >> >> we are taking something readable and turning it into a generated >> configuration value that our sysadmins will *really* hate. I think >> the changes outlined above while clear are a definite step backwards >> in functionality for Katello. The price to pay to support Env >> renaming is *not* worth it if we implement it as such. Lets not take >> this decision likely because one of the primary touch points at the >> client is the redhat.repo file that lists the content you are pulling >> down. >> >> I'd much rather do the following to ensure our yum config values on >> the clients are readable and sacrifice i18n in order to do so: >> >> 1) use an ASCII label for reops if we are going to really implement >> repo renaming >> 2) force Org (possibly), Env and Repo names to be ASCII >> 3) Any existing utf-8 data for these values is left alone and users >> are warned we do not support this, or we encode it in some way such >> that it works > Does my example above resolve the questions you had? >> >> >> Is renaming environments really worth all this effort? If so, lets >> not sacrifice our usability at the client level just to support it. > Personally, I'm not convinced that it's worth it, since we could > replicate renaming with create environment/move system[s] (although we > need bulk moving). This doesn't resolve the issue with environment > names in urls however. > > -d >> >> Mike >> >> >> >> >> > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Tue Aug 14 12:50:39 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 08:50:39 -0400 Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <502A19B8.5030909@redhat.com> References: <713002230.8961790.1344882634730.JavaMail.root@redhat.com> <502A19B8.5030909@redhat.com> Message-ID: <502A499F.9050409@redhat.com> On 08/14/2012 05:26 AM, Dmitri Dolguikh wrote: > On 13/08/12 07:30 PM, James Labocki wrote: >> Sorry for posting across both lists, but this involves both aeolus and katello. >> >> Last week a few of us were discussing the ability to import/export deployables within aeolus for sharing between differing implementations. >> >> The attached photo 1.JPG provides a high level diagram of some of the problems we believe exist in achieving this today. Please note that I used enterprise nomenclature, so I think that: >> >> - System Engine = Katello >> - Component Outline = Assembly >> - Blueprint = Deployable >> - AppForm = Deployment With Foreman Integration, the goal is to kill templates and model component outlines off of Foreman Host Groups. >> >> We found the following areas differ between implementations and would need to be accounted for. Note this this was not an exhaustive exercise and I'm sure we missed some areas. >> >> - Providers paths are different in katello >> - Certificates are different in system templates >> - Repositories are different in system templates >> - Deployables and their services are tightly coupled (not shareable) >> - Clouds, Cloud Resource Zones, and Catalogs are different in aeolus >> Can you give examples of these issues? I would assume the TDL we are generating is valid. -- bk From dmitri at redhat.com Tue Aug 14 12:56:29 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 13:56:29 +0100 Subject: [katello-devel] moving of systems between environments Message-ID: <502A4AFD.9060700@redhat.com> Hey all, the above functionality is in master as of yesterday. To move the system using web ui: on system detail screen, change the environment name to the one you intend to move the system to. Once completed, the system will reside in the new environment. To move the system via cli: katello system update --org=Blah --name=My_system --new_environment= To verify that the system has been moved successfully: pull entitlement certificate and verify that the content urls have been updated to use the new environment. Please note that if the content that the system has been subscribed to is not available in the new environment, the entitlement certificate is not going to have it either. Please let me know if you have questions/comments, -d From bkearney at redhat.com Tue Aug 14 13:01:01 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 09:01:01 -0400 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A33B6.5090606@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> Message-ID: <502A4C0D.6060609@redhat.com> On 08/14/2012 07:17 AM, Dmitri Dolguikh wrote: > On 13/08/12 11:13 PM, Mike McCune wrote: >> On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote: >>> On 13/08/12 03:57 PM, Justin Sherrill wrote: >>>> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >>>>> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>>>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>>>>> This is a summary of the thread started at >>>>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>>>>> >>>>>>> >>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>> details of the issue with environment renaming. >>>>>>> >>>>>>> Quite a few folks suggested using of an immutable label instead of >>>>>>> environment name, but at the end the idea was defeated by a comment >>>>>>> from Cliff Perry about users from locales using non-ascii-based >>>>>>> character sets. >>>>>>> Another issue that was discovered was the migration of already >>>>>>> established environments from current version of Katello to the >>>>>>> version containing the fix. My current thinking is to use >>>>>>> environment name value as uuid for "legacy" environments. This >>>>>>> would significantly simply upgrade, as there will be no need to >>>>>>> regenerate entitlement certificates, etc. >>>>>>> >>>>>>> Katello: >>>>>>> - introduce environment uuids (update db schema, model, etc) >>>>>>> - update candlepin (this will include updates to schema, and >>>>>>> resource controller) >>>>>>> - update katello/katello cli to use uuids for environment >>>>>>> identification >>>>>>> - update repository-related functionality to use environment uuids >>>>>>> - figure out/create migration from 1.0 to current >>>>>>> >>>>>>> Bryan, everything minus the migration bit is probably a couple days >>>>>>> worth of work. Should I create a new story, or I can start on this >>>>>>> right away? >>>>>>> >>>>>>> -d >>>>>>> >>>>>>> _______________________________________________ >>>>>>> katello-devel mailing list >>>>>>> katello-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>> Any idea what the redhat.repo file will look like with numerical >>>>>> ids? Or yum repolist ? >>>>> Same as now, but with environment uuids instead on environment names. >>>>> -d >>>> >>> Apologies, I didn't understand the question. The latter. >>> -d >>>> So >>>> >>>> [123456] >>>> name=123456 >>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>> >>>> or >>>> >>>> [123456] >>>> name=Red Hat Enterprise Linux Server 6 RPMS >>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>> >>>> >>>> ? >>>> >> >> >> and this really blows for our users, IMHO. You go from a relatively >> readable and clear yum configuration file that a sysadmin can look at >> quickly and understand: >> >> [ACME_Corporation_zoo_zoorepo] >> name = zoorepo >> baseurl = >> https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo >> >> enabled = 1 >> gpgcheck = 1 >> sslverify = 1 >> sslcacert = /etc/rhsm/ca/candlepin-local.pem >> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >> >> to: >> >> [313024c0-c7bd-012f-d852-1803734d16c4] >> name = zoorepo >> baseurl = >> https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 >> >> enabled = 1 >> gpgcheck = 1 >> sslverify = 1 >> sslcacert = /etc/rhsm/ca/candlepin-local.pem >> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem So, this pains me.. especially since tools like packagekit need to enable and disable repos. If there is a solution where the name and the id are Human Readable and "As close to locale as possible" then I am fine. Image how ugly this screen would look with UUIDS. -- bk -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2012-08-14 09:00:20.png Type: image/png Size: 39717 bytes Desc: not available URL: From jlabocki at redhat.com Tue Aug 14 13:03:01 2012 From: jlabocki at redhat.com (James Labocki) Date: Tue, 14 Aug 2012 09:03:01 -0400 (EDT) Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <5029ECD8.8040203@redhat.com> Message-ID: <1747420251.9370175.1344949381541.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ivan Ne?as" > To: "James Labocki" > Cc: "aeolus-devel" , "katello-devel" , "Steven Reichard" > , "Francesco Vollero" > Sent: Tuesday, August 14, 2012 2:14:48 AM > Subject: Re: [katello-devel] Deployable and System Template Portability > > On 08/13/2012 08:30 PM, James Labocki wrote: > > > > Last week a few of us were discussing the ability to import/export > > deployables within aeolus for sharing between differing > > implementations. > > > What does "differing implementations" mean in this context? Customer A installs System Engine and creates Custom ProviderX with ProductY and RepoZ Customer B installs System Engine and creates Custom ProviderA with ProductB and RepoC Customer A creates system template which references RepoZ, hands system template to Customer B. Customer B takes system template and imports it into his/her cloud engine. The custom provider is does not exist in his system engine (assuming he changes the path the system engine host in the template) and the certs don't match. That is what I mean by differing implementations. Does that help? > > -- Ivan > From dmitri at redhat.com Tue Aug 14 13:04:01 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 14:04:01 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A4C0D.6060609@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A4C0D.6060609@redhat.com> Message-ID: <502A4CC1.4070107@redhat.com> On 14/08/12 02:01 PM, Bryan Kearney wrote: > On 08/14/2012 07:17 AM, Dmitri Dolguikh wrote: >> On 13/08/12 11:13 PM, Mike McCune wrote: >>> On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote: >>>> On 13/08/12 03:57 PM, Justin Sherrill wrote: >>>>> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >>>>>> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>>>>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>>>>>> This is a summary of the thread started at >>>>>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>>> details of the issue with environment renaming. >>>>>>>> >>>>>>>> Quite a few folks suggested using of an immutable label instead of >>>>>>>> environment name, but at the end the idea was defeated by a >>>>>>>> comment >>>>>>>> from Cliff Perry about users from locales using non-ascii-based >>>>>>>> character sets. >>>>>>>> Another issue that was discovered was the migration of already >>>>>>>> established environments from current version of Katello to the >>>>>>>> version containing the fix. My current thinking is to use >>>>>>>> environment name value as uuid for "legacy" environments. This >>>>>>>> would significantly simply upgrade, as there will be no need to >>>>>>>> regenerate entitlement certificates, etc. >>>>>>>> >>>>>>>> Katello: >>>>>>>> - introduce environment uuids (update db schema, model, etc) >>>>>>>> - update candlepin (this will include updates to schema, and >>>>>>>> resource controller) >>>>>>>> - update katello/katello cli to use uuids for environment >>>>>>>> identification >>>>>>>> - update repository-related functionality to use environment >>>>>>>> uuids >>>>>>>> - figure out/create migration from 1.0 to current >>>>>>>> >>>>>>>> Bryan, everything minus the migration bit is probably a couple >>>>>>>> days >>>>>>>> worth of work. Should I create a new story, or I can start on this >>>>>>>> right away? >>>>>>>> >>>>>>>> -d >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> katello-devel mailing list >>>>>>>> katello-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>>> Any idea what the redhat.repo file will look like with numerical >>>>>>> ids? Or yum repolist ? >>>>>> Same as now, but with environment uuids instead on environment >>>>>> names. >>>>>> -d >>>>> >>>> Apologies, I didn't understand the question. The latter. >>>> -d >>>>> So >>>>> >>>>> [123456] >>>>> name=123456 >>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>> >>>>> or >>>>> >>>>> [123456] >>>>> name=Red Hat Enterprise Linux Server 6 RPMS >>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>> >>>>> >>>>> ? >>>>> >>> >>> >>> and this really blows for our users, IMHO. You go from a relatively >>> readable and clear yum configuration file that a sysadmin can look at >>> quickly and understand: >>> >>> [ACME_Corporation_zoo_zoorepo] >>> name = zoorepo >>> baseurl = >>> https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo >>> >>> >>> enabled = 1 >>> gpgcheck = 1 >>> sslverify = 1 >>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >>> >>> to: >>> >>> [313024c0-c7bd-012f-d852-1803734d16c4] >>> name = zoorepo >>> baseurl = >>> https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 >>> >>> >>> enabled = 1 >>> gpgcheck = 1 >>> sslverify = 1 >>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem > > So, this pains me.. especially since tools like packagekit need to > enable and disable repos. If there is a solution where the name and > the id are Human Readable and "As close to locale as possible" then I > am fine. Image how ugly this screen would look with UUIDS. My understanding is that the name does not have any constraints on what characters can be used. We could generate repository label (or w/e is used in the repo url using Product name, etc?) -d > > -- 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 Tue Aug 14 13:05:37 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 09:05:37 -0400 Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <1747420251.9370175.1344949381541.JavaMail.root@redhat.com> References: <1747420251.9370175.1344949381541.JavaMail.root@redhat.com> Message-ID: <502A4D21.6050402@redhat.com> On 08/14/2012 09:03 AM, James Labocki wrote: > > > ----- Original Message ----- >> From: "Ivan Ne?as" >> To: "James Labocki" >> Cc: "aeolus-devel" , "katello-devel" , "Steven Reichard" >> , "Francesco Vollero" >> Sent: Tuesday, August 14, 2012 2:14:48 AM >> Subject: Re: [katello-devel] Deployable and System Template Portability >> >> On 08/13/2012 08:30 PM, James Labocki wrote: >>> >>> Last week a few of us were discussing the ability to import/export >>> deployables within aeolus for sharing between differing >>> implementations. >>> >> What does "differing implementations" mean in this context? > > Customer A installs System Engine and creates Custom ProviderX with ProductY and RepoZ > Customer B installs System Engine and creates Custom ProviderA with ProductB and RepoC > > Customer A creates system template which references RepoZ, hands system template to Customer B. > Customer B takes system template and imports it into his/her cloud engine. The custom provider is does not exist in his system engine (assuming he changes the path the system engine host in the template) and the certs don't match. > > That is what I mean by differing implementations. Does that help? > yes, but I do not see this as a bug. What is the real use case for crossing customers like this? -- bk From bkearney at redhat.com Tue Aug 14 13:07:26 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 09:07:26 -0400 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A4CC1.4070107@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> Message-ID: <502A4D8E.8030602@redhat.com> On 08/14/2012 09:04 AM, Dmitri Dolguikh wrote: > On 14/08/12 02:01 PM, Bryan Kearney wrote: >> On 08/14/2012 07:17 AM, Dmitri Dolguikh wrote: >>> On 13/08/12 11:13 PM, Mike McCune wrote: >>>> On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote: >>>>> On 13/08/12 03:57 PM, Justin Sherrill wrote: >>>>>> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >>>>>>> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>>>>>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>>>>>>> This is a summary of the thread started at >>>>>>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>>>> details of the issue with environment renaming. >>>>>>>>> >>>>>>>>> Quite a few folks suggested using of an immutable label instead of >>>>>>>>> environment name, but at the end the idea was defeated by a >>>>>>>>> comment >>>>>>>>> from Cliff Perry about users from locales using non-ascii-based >>>>>>>>> character sets. >>>>>>>>> Another issue that was discovered was the migration of already >>>>>>>>> established environments from current version of Katello to the >>>>>>>>> version containing the fix. My current thinking is to use >>>>>>>>> environment name value as uuid for "legacy" environments. This >>>>>>>>> would significantly simply upgrade, as there will be no need to >>>>>>>>> regenerate entitlement certificates, etc. >>>>>>>>> >>>>>>>>> Katello: >>>>>>>>> - introduce environment uuids (update db schema, model, etc) >>>>>>>>> - update candlepin (this will include updates to schema, and >>>>>>>>> resource controller) >>>>>>>>> - update katello/katello cli to use uuids for environment >>>>>>>>> identification >>>>>>>>> - update repository-related functionality to use environment >>>>>>>>> uuids >>>>>>>>> - figure out/create migration from 1.0 to current >>>>>>>>> >>>>>>>>> Bryan, everything minus the migration bit is probably a couple >>>>>>>>> days >>>>>>>>> worth of work. Should I create a new story, or I can start on this >>>>>>>>> right away? >>>>>>>>> >>>>>>>>> -d >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> katello-devel mailing list >>>>>>>>> katello-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>>>> Any idea what the redhat.repo file will look like with numerical >>>>>>>> ids? Or yum repolist ? >>>>>>> Same as now, but with environment uuids instead on environment >>>>>>> names. >>>>>>> -d >>>>>> >>>>> Apologies, I didn't understand the question. The latter. >>>>> -d >>>>>> So >>>>>> >>>>>> [123456] >>>>>> name=123456 >>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>>> >>>>>> or >>>>>> >>>>>> [123456] >>>>>> name=Red Hat Enterprise Linux Server 6 RPMS >>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>>> >>>>>> >>>>>> ? >>>>>> >>>> >>>> >>>> and this really blows for our users, IMHO. You go from a relatively >>>> readable and clear yum configuration file that a sysadmin can look at >>>> quickly and understand: >>>> >>>> [ACME_Corporation_zoo_zoorepo] >>>> name = zoorepo >>>> baseurl = >>>> https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo >>>> >>>> >>>> enabled = 1 >>>> gpgcheck = 1 >>>> sslverify = 1 >>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >>>> >>>> to: >>>> >>>> [313024c0-c7bd-012f-d852-1803734d16c4] >>>> name = zoorepo >>>> baseurl = >>>> https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 >>>> >>>> >>>> enabled = 1 >>>> gpgcheck = 1 >>>> sslverify = 1 >>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >> >> So, this pains me.. especially since tools like packagekit need to >> enable and disable repos. If there is a solution where the name and >> the id are Human Readable and "As close to locale as possible" then I >> am fine. Image how ugly this screen would look with UUIDS. > My understanding is that the name does not have any constraints on what > characters can be used. We could generate repository label (or w/e is > used in the repo url using Product name, etc?) > > -d I would prefer the URl to be friendly, but I see how UUIDS will make it easier. So, give me a path where the IDs and names are as human readable as possible and I will be relent. -- bk From jlabocki at redhat.com Tue Aug 14 13:12:51 2012 From: jlabocki at redhat.com (James Labocki) Date: Tue, 14 Aug 2012 09:12:51 -0400 (EDT) Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <502A499F.9050409@redhat.com> Message-ID: <1637699023.9372537.1344949971111.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Bryan Kearney" > To: aeolus-devel at lists.fedorahosted.org, katello-devel at redhat.com > Sent: Tuesday, August 14, 2012 8:50:39 AM > Subject: Re: [katello-devel] Deployable and System Template Portability > > On 08/14/2012 05:26 AM, Dmitri Dolguikh wrote: > > On 13/08/12 07:30 PM, James Labocki wrote: > >> Sorry for posting across both lists, but this involves both aeolus > >> and katello. > >> > >> Last week a few of us were discussing the ability to import/export > >> deployables within aeolus for sharing between differing > >> implementations. > >> > >> The attached photo 1.JPG provides a high level diagram of some of > >> the problems we believe exist in achieving this today. Please > >> note that I used enterprise nomenclature, so I think that: > >> > >> - System Engine = Katello > >> - Component Outline = Assembly > >> - Blueprint = Deployable > >> - AppForm = Deployment > > With Foreman Integration, the goal is to kill templates and model > component outlines off of Foreman Host Groups. I'd like to see both these models supported in the future, is this the thinking behind using host groups or will it only support one of the scenarios? Description + Host Group ==> Build ==> Configured Image ==> Push to Provider Configured Image at Provider ==> Launch ==> Connect back to Katello and make further changes to Host Group OR Description ==> Build ==> Unconfigured Image ==> Push to Provider Unconfigured Image at Provider ==> Launch ==> Connect back to Katello and make all changes based on Host Group > > >> > >> We found the following areas differ between implementations and > >> would need to be accounted for. Note this this was not an > >> exhaustive exercise and I'm sure we missed some areas. > >> > >> - Providers paths are different in katello > >> - Certificates are different in system templates > >> - Repositories are different in system templates > >> - Deployables and their services are tightly coupled (not > >> shareable) > >> - Clouds, Cloud Resource Zones, and Catalogs are different in > >> aeolus > >> > > Can you give examples of these issues? I would assume the TDL we are > generating is valid. >From reply to Ivan earlier plus more information. Customer A installs katello and creates Custom ProviderX with ProductY and RepoZ Customer B installs katello and creates Custom ProviderA with ProductB and RepoC Customer A creates system template which references RepoZ, hands system template to Customer B. Customer B takes system template and imports it into his/her aeolus. The custom provider is does not exist in his system engine (assuming he changes the path the system engine host in the template) and the certs don't match. On the Aeolus side: Image ID's don't match in the application blueprint that Customer A would share with Customer B which would contain the multiple images that make up an application. Also, services in the application blueprint will likely call environment specific variables which are not abstracted from the service. > > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jlabocki at redhat.com Tue Aug 14 13:15:55 2012 From: jlabocki at redhat.com (James Labocki) Date: Tue, 14 Aug 2012 09:15:55 -0400 (EDT) Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <502A4D21.6050402@redhat.com> Message-ID: <255891999.9374564.1344950155779.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Bryan Kearney" > To: aeolus-devel at lists.fedorahosted.org, katello-devel at redhat.com > Sent: Tuesday, August 14, 2012 9:05:37 AM > Subject: Re: [katello-devel] Deployable and System Template Portability > > On 08/14/2012 09:03 AM, James Labocki wrote: > > > > > > ----- Original Message ----- > >> From: "Ivan Ne?as" > >> To: "James Labocki" > >> Cc: "aeolus-devel" , > >> "katello-devel" , "Steven Reichard" > >> , "Francesco Vollero" > >> Sent: Tuesday, August 14, 2012 2:14:48 AM > >> Subject: Re: [katello-devel] Deployable and System Template > >> Portability > >> > >> On 08/13/2012 08:30 PM, James Labocki wrote: > >>> > >>> Last week a few of us were discussing the ability to > >>> import/export > >>> deployables within aeolus for sharing between differing > >>> implementations. > >>> > >> What does "differing implementations" mean in this context? > > > > Customer A installs System Engine and creates Custom ProviderX with > > ProductY and RepoZ > > Customer B installs System Engine and creates Custom ProviderA with > > ProductB and RepoC > > > > Customer A creates system template which references RepoZ, hands > > system template to Customer B. > > Customer B takes system template and imports it into his/her cloud > > engine. The custom provider is does not exist in his system engine > > (assuming he changes the path the system engine host in the > > template) and the certs don't match. > > > > That is what I mean by differing implementations. Does that help? > > > > > yes, but I do not see this as a bug. What is the real use case for > crossing customers like this? I create an application blueprint that I can share with anyone who has katello+aeolus and they can easily run that application blueprint in their environment. End users care about the applications and creating an easy way for users to share application stacks would create increased demand for katello+aeolus. I wonder if we should figure out a way to own the delivery channel of users custom content a bit more. In other words, figure out a way to standardize even custom content providers that users want to use so Red Hat becomes more of a delivered service. This last part may just be me thinking out loud. :) > > -- bk > > > From jesusr at redhat.com Tue Aug 14 13:25:16 2012 From: jesusr at redhat.com (jesus m. rodriguez) Date: Tue, 14 Aug 2012 09:25:16 -0400 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <20120814110756.GJ2850@lzapx.brq.redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <20120814110756.GJ2850@lzapx.brq.redhat.com> Message-ID: <502A51BC.7040005@redhat.com> On 08/14/2012 07:07 AM, Lukas Zapletal wrote: > On Mon, Aug 13, 2012 at 03:13:32PM -0700, Michael McCune wrote: >> I'd much rather do the following to ensure our yum config values on >> the clients are readable and sacrifice i18n in order to do so: >> >> 1) use an ASCII label for reops if we are going to really implement >> repo renaming >> 2) force Org (possibly), Env and Repo names to be ASCII >> 3) Any existing utf-8 data for these values is left alone and users >> are warned we do not support this, or we encode it in some way such >> that it works >> >> Is renaming environments really worth all this effort? If so, lets >> not sacrifice our usability at the client level just to support it. >> > > +1 > > I would not say Cliff's recommendation was defeated by UTF-8. The key > for labels is to use ASCII there. Being Czech, I very often see websites > "fixing" my content name into ASCII labels and using them in URLs. Some > websites do this better automatically, some are worse. But the idea > remains the same. > > Example for "?lu?ou?k? k??". > > Good translation: "zlutoucky kun". > > Bad one: "?lu?ou?k? k??" or "luouk-k" or variations :-) > > Unfortunately this can be applied only for characters with UNICODE > normal forms. For example, Chinese can't be translated that easy way and > user would need to put his alphanum label on his own. Penalty for > renaming feature? No, even Chinese admins would like to have nice yum > URLs and repo names. > I agree that the labels are still a better approach. Environment names should be UTF-8 and handle double byte characters, but the labels can be alphanumeric ASCII. I don't see anything wrong with that. And it will help with the repo files, urls, and other places we need human readable id. Again, if renaming environments causes pain, then add support for copy / delete of environments. That is effectively what a rename is anyway. jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ From dmitri at redhat.com Tue Aug 14 13:26:22 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 14:26:22 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A4D8E.8030602@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> <502A4D8E.8030602@redhat.com> Message-ID: <502A51FE.7010008@redhat.com> On 14/08/12 02:07 PM, Bryan Kearney wrote: > On 08/14/2012 09:04 AM, Dmitri Dolguikh wrote: >> On 14/08/12 02:01 PM, Bryan Kearney wrote: >>> On 08/14/2012 07:17 AM, Dmitri Dolguikh wrote: >>>> On 13/08/12 11:13 PM, Mike McCune wrote: >>>>> On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote: >>>>>> On 13/08/12 03:57 PM, Justin Sherrill wrote: >>>>>>> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >>>>>>>> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>>>>>>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>>>>>>>> This is a summary of the thread started at >>>>>>>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 >>>>>>>>>> for >>>>>>>>>> details of the issue with environment renaming. >>>>>>>>>> >>>>>>>>>> Quite a few folks suggested using of an immutable label >>>>>>>>>> instead of >>>>>>>>>> environment name, but at the end the idea was defeated by a >>>>>>>>>> comment >>>>>>>>>> from Cliff Perry about users from locales using non-ascii-based >>>>>>>>>> character sets. >>>>>>>>>> Another issue that was discovered was the migration of already >>>>>>>>>> established environments from current version of Katello to the >>>>>>>>>> version containing the fix. My current thinking is to use >>>>>>>>>> environment name value as uuid for "legacy" environments. This >>>>>>>>>> would significantly simply upgrade, as there will be no need to >>>>>>>>>> regenerate entitlement certificates, etc. >>>>>>>>>> >>>>>>>>>> Katello: >>>>>>>>>> - introduce environment uuids (update db schema, model, etc) >>>>>>>>>> - update candlepin (this will include updates to schema, and >>>>>>>>>> resource controller) >>>>>>>>>> - update katello/katello cli to use uuids for environment >>>>>>>>>> identification >>>>>>>>>> - update repository-related functionality to use environment >>>>>>>>>> uuids >>>>>>>>>> - figure out/create migration from 1.0 to current >>>>>>>>>> >>>>>>>>>> Bryan, everything minus the migration bit is probably a couple >>>>>>>>>> days >>>>>>>>>> worth of work. Should I create a new story, or I can start on >>>>>>>>>> this >>>>>>>>>> right away? >>>>>>>>>> >>>>>>>>>> -d >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> katello-devel mailing list >>>>>>>>>> katello-devel at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>>>>> Any idea what the redhat.repo file will look like with numerical >>>>>>>>> ids? Or yum repolist ? >>>>>>>> Same as now, but with environment uuids instead on environment >>>>>>>> names. >>>>>>>> -d >>>>>>> >>>>>> Apologies, I didn't understand the question. The latter. >>>>>> -d >>>>>>> So >>>>>>> >>>>>>> [123456] >>>>>>> name=123456 >>>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>>>> >>>>>>> or >>>>>>> >>>>>>> [123456] >>>>>>> name=Red Hat Enterprise Linux Server 6 RPMS >>>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>>>> >>>>>>> >>>>>>> ? >>>>>>> >>>>> >>>>> >>>>> and this really blows for our users, IMHO. You go from a relatively >>>>> readable and clear yum configuration file that a sysadmin can look at >>>>> quickly and understand: >>>>> >>>>> [ACME_Corporation_zoo_zoorepo] >>>>> name = zoorepo >>>>> baseurl = >>>>> https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo >>>>> >>>>> >>>>> >>>>> enabled = 1 >>>>> gpgcheck = 1 >>>>> sslverify = 1 >>>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >>>>> >>>>> to: >>>>> >>>>> [313024c0-c7bd-012f-d852-1803734d16c4] >>>>> name = zoorepo >>>>> baseurl = >>>>> https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 >>>>> >>>>> >>>>> >>>>> enabled = 1 >>>>> gpgcheck = 1 >>>>> sslverify = 1 >>>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >>> >>> So, this pains me.. especially since tools like packagekit need to >>> enable and disable repos. If there is a solution where the name and >>> the id are Human Readable and "As close to locale as possible" then I >>> am fine. Image how ugly this screen would look with UUIDS. >> My understanding is that the name does not have any constraints on what >> characters can be used. We could generate repository label (or w/e is >> used in the repo url using Product name, etc?) >> >> -d > > I would prefer the URl to be friendly, but I see how UUIDS will make > it easier. So, give me a path where the IDs and names are as human > readable as possible and I will be relent. Hmm. how about automatically generate labels in spirit of http://world.std.com/~reinhold/diceware.html ? The trick would be guarantee uniqueness, I'll have to think about that... -d > > -- 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 matt.wagner at redhat.com Tue Aug 14 13:43:39 2012 From: matt.wagner at redhat.com (Matt Wagner) Date: Tue, 14 Aug 2012 09:43:39 -0400 Subject: [katello-devel] RFC: Notification system In-Reply-To: <502A409F.5090001@redhat.com> References: <20120813212655.GA21991@mawagner-desktop.usersys.redhat.com> <502A1CEC.9050506@redhat.com> <20120814120052.GG4597@redhat.com> <502A409F.5090001@redhat.com> Message-ID: <20120814134339.GB1868@mawagner-desktop.usersys.redhat.com> On Tue, Aug 14, 2012 at 08:12:15AM -0400, Bryan Kearney wrote: > > On notifications, the other thing I would like to see (ideally a > shared service) is the ability to send email notificaitons out to one > or more users based on events. I would assume templating, batching, > and some sort of data injection. We have that on the errata side > (jomara is looking at it). Perhaps we can have folks co-develop that > part too. I think extending the notifications system to support sending emails should be pretty simple. (Famous last words?) But it sounds like what you're describing is a little more involved -- what I'm thinking could almost be a quick after_create hook on a person's notification to send them an email if they hadn't opted out. It sounds like what you're describing is a good bit different -- a shared service that (watches for | is informed of) various events, stores them in a queue, and sends out periodic batch emails, while allowing admins to create custom criteria for notifications. (I assume this is what you mean by templating, versus using the equivalent of a view with ActiveMailer or whatever it's called this year.) I'm not sure if that's something Conductor needs right now. (But maybe we do and I just don't see it yet.) -- Matt From ehelms at redhat.com Tue Aug 14 13:44:00 2012 From: ehelms at redhat.com (Eric Helms) Date: Tue, 14 Aug 2012 09:44:00 -0400 Subject: [katello-devel] It's Alive: New Katello Site and Blog Message-ID: <502A5620.1080308@redhat.com> On the back of the release of Katello 1.0 and as part of our increased community efforts, the Katello team has launched a new site and blog. The site will continue to grow and add new content so make sure you check back often. http://www.katello.org/ The Katello blog is a new feature to the Katello site and will encompass posts from community members geared towards how to use and develop Katello features. Look here first for new announcements! http://www.katello.org/blog/ *Did I hear you say Katello 1.0 was released?* Read about the official announcement here http://www.katello.org/katello-1-0-released/ *Want to get involved?* Whether you are a user or a developer, visit our community page to find out how to get started working with Katello: http://www.katello.org/get-involved/ *Looking for videos on how to use Katello?* Check back frequently to our YouTube channel http://www.youtube.com/user/KatelloProject or watch directly on the site http://www.katello.org/videos/ *Want to know what else we are up to? * Follow us on Twitter http://twitter.com/Katello_Project and Google+ https://plus.google.com/106761937932528197228/posts *Have questions?* Start here http://www.katello.org/faq/ and come find us on Freenode IRC at #katello or directly from the site at http://www.katello.org/irc/. Users are also encouraged to send questions to the official users mailing list - katello at lists.fedorahosted.org *I just want to get to the code! *Visit our official code repository hosted on Github: https://github.com/Katello/katello If you would like to contribute, please send an email requesting as much. The Katello website was created using WordPress and harnessing the awesome hosting powers of OpenShift. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuchy at redhat.com Tue Aug 14 13:51:39 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Tue, 14 Aug 2012 15:51:39 +0200 Subject: [katello-devel] Licensing? In-Reply-To: <502A4341.2000107@redhat.com> References: <502A4341.2000107@redhat.com> Message-ID: <502A57EB.1040605@redhat.com> On 08/14/2012 02:23 PM, Bryan Kearney wrote: > OK... > > Katello is GPLV2, and Aeolus is ASL. It would be nice to make it easy to > share code, and we know Apache is kinda a big bully around their fancy > license. We can not move to GPLV3 (like Foreman) since that is no better > [1]. Couple of options: > > 1) Katello can switch to either ASL, or MIT. > 2) Katello could dual license current and ASL/MIT > 3) Do nothing > > I dont think we need to worry about any of the backend projects, just > the rails parts. There has been history of other companies, which built upon Red Hat projects. And I'm afraid some of them are not open-source companies by heart and they may to hesitate to contribute back or even release source code. GPLv2 forces you to release source code, while neither MIT nor ASL do not forces you to release (modified) source code. For this reason I vote for 3) - do nothing and stay on GPLv2. -- Miroslav Suchy Red Hat Systems Management Engineering From bkearney at redhat.com Tue Aug 14 13:53:55 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 09:53:55 -0400 Subject: [katello-devel] RFC: Notification system In-Reply-To: <20120814134339.GB1868@mawagner-desktop.usersys.redhat.com> References: <20120813212655.GA21991@mawagner-desktop.usersys.redhat.com> <502A1CEC.9050506@redhat.com> <20120814120052.GG4597@redhat.com> <502A409F.5090001@redhat.com> <20120814134339.GB1868@mawagner-desktop.usersys.redhat.com> Message-ID: <502A5873.8010007@redhat.com> On 08/14/2012 09:43 AM, Matt Wagner wrote: > On Tue, Aug 14, 2012 at 08:12:15AM -0400, Bryan Kearney wrote: >> >> On notifications, the other thing I would like to see (ideally a >> shared service) is the ability to send email notificaitons out to one >> or more users based on events. I would assume templating, batching, >> and some sort of data injection. We have that on the errata side >> (jomara is looking at it). Perhaps we can have folks co-develop that >> part too. > > I think extending the notifications system to support sending emails > should be pretty simple. (Famous last words?) But it sounds like what > you're describing is a little more involved -- what I'm thinking could > almost be a quick after_create hook on a person's notification to send > them an email if they hadn't opted out. > > It sounds like what you're describing is a good bit different -- a > shared service that (watches for | is informed of) various events, > stores them in a queue, and sends out periodic batch emails, while > allowing admins to create custom criteria for notifications. (I assume > this is what you mean by templating, versus using the equivalent of a > view with ActiveMailer or whatever it's called this year.) I'm not sure > if that's something Conductor needs right now. (But maybe we do and I > just don't see it yet.) > I see a couple of stages. First would be Engine X (Perhaps not in ruby) publishes an event which a usr can register to. Data from the event is used to create a text email which goes out. Second, fancier CEP (if I get 10 events in 2 minutes, send out an email). Third, engine can query data stores to create their own events. -- bk From bkearney at redhat.com Tue Aug 14 13:56:10 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 09:56:10 -0400 Subject: [katello-devel] Licensing? In-Reply-To: <502A57EB.1040605@redhat.com> References: <502A4341.2000107@redhat.com> <502A57EB.1040605@redhat.com> Message-ID: <502A58FA.7010001@redhat.com> On 08/14/2012 09:51 AM, Miroslav Such? wrote: > On 08/14/2012 02:23 PM, Bryan Kearney wrote: >> OK... >> >> Katello is GPLV2, and Aeolus is ASL. It would be nice to make it easy to >> share code, and we know Apache is kinda a big bully around their fancy >> license. We can not move to GPLV3 (like Foreman) since that is no better >> [1]. Couple of options: >> >> 1) Katello can switch to either ASL, or MIT. >> 2) Katello could dual license current and ASL/MIT >> 3) Do nothing >> >> I dont think we need to worry about any of the backend projects, just >> the rails parts. > > There has been history of other companies, which built upon Red Hat > projects. And I'm afraid some of them are not open-source companies by > heart and they may to hesitate to contribute back or even release source > code. > GPLv2 forces you to release source code, while neither MIT nor ASL do > not forces you to release (modified) source code. > > For this reason I vote for 3) - do nothing and stay on GPLv2. > > I guess a third option is to break out common code to gems or other rails engines type reusable concepts, and then license those MIT. -- bk From jesusr at redhat.com Tue Aug 14 13:58:06 2012 From: jesusr at redhat.com (jesus m. rodriguez) Date: Tue, 14 Aug 2012 09:58:06 -0400 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A51FE.7010008@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> <502A4D8E.8030602@redhat.com> <502A51FE.7010008@redhat.com> Message-ID: <502A596E.5060504@redhat.com> On 08/14/2012 09:26 AM, Dmitri Dolguikh wrote: > On 14/08/12 02:07 PM, Bryan Kearney wrote: >> On 08/14/2012 09:04 AM, Dmitri Dolguikh wrote: >>> On 14/08/12 02:01 PM, Bryan Kearney wrote: >>>> On 08/14/2012 07:17 AM, Dmitri Dolguikh wrote: >>>>> On 13/08/12 11:13 PM, Mike McCune wrote: >>>>>> On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote: >>>>>>> On 13/08/12 03:57 PM, Justin Sherrill wrote: >>>>>>>> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >>>>>>>>> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>>>>>>>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>>>>>>>>> This is a summary of the thread started at >>>>>>>>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 >>>>>>>>>>> for >>>>>>>>>>> details of the issue with environment renaming. >>>>>>>>>>> >>>>>>>>>>> Quite a few folks suggested using of an immutable label >>>>>>>>>>> instead of >>>>>>>>>>> environment name, but at the end the idea was defeated by a >>>>>>>>>>> comment >>>>>>>>>>> from Cliff Perry about users from locales using non-ascii-based >>>>>>>>>>> character sets. >>>>>>>>>>> Another issue that was discovered was the migration of already >>>>>>>>>>> established environments from current version of Katello to the >>>>>>>>>>> version containing the fix. My current thinking is to use >>>>>>>>>>> environment name value as uuid for "legacy" environments. This >>>>>>>>>>> would significantly simply upgrade, as there will be no need to >>>>>>>>>>> regenerate entitlement certificates, etc. >>>>>>>>>>> >>>>>>>>>>> Katello: >>>>>>>>>>> - introduce environment uuids (update db schema, model, etc) >>>>>>>>>>> - update candlepin (this will include updates to schema, and >>>>>>>>>>> resource controller) >>>>>>>>>>> - update katello/katello cli to use uuids for environment >>>>>>>>>>> identification >>>>>>>>>>> - update repository-related functionality to use environment >>>>>>>>>>> uuids >>>>>>>>>>> - figure out/create migration from 1.0 to current >>>>>>>>>>> >>>>>>>>>>> Bryan, everything minus the migration bit is probably a couple >>>>>>>>>>> days >>>>>>>>>>> worth of work. Should I create a new story, or I can start on >>>>>>>>>>> this >>>>>>>>>>> right away? >>>>>>>>>>> >>>>>>>>>>> -d >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> katello-devel mailing list >>>>>>>>>>> katello-devel at redhat.com >>>>>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>>>>>> Any idea what the redhat.repo file will look like with numerical >>>>>>>>>> ids? Or yum repolist ? >>>>>>>>> Same as now, but with environment uuids instead on environment >>>>>>>>> names. >>>>>>>>> -d >>>>>>>> >>>>>>> Apologies, I didn't understand the question. The latter. >>>>>>> -d >>>>>>>> So >>>>>>>> >>>>>>>> [123456] >>>>>>>> name=123456 >>>>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>>>>> >>>>>>>> or >>>>>>>> >>>>>>>> [123456] >>>>>>>> name=Red Hat Enterprise Linux Server 6 RPMS >>>>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>>>>> >>>>>>>> >>>>>>>> ? >>>>>>>> >>>>>> >>>>>> >>>>>> and this really blows for our users, IMHO. You go from a relatively >>>>>> readable and clear yum configuration file that a sysadmin can look at >>>>>> quickly and understand: >>>>>> >>>>>> [ACME_Corporation_zoo_zoorepo] >>>>>> name = zoorepo >>>>>> baseurl = >>>>>> https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo >>>>>> >>>>>> >>>>>> >>>>>> enabled = 1 >>>>>> gpgcheck = 1 >>>>>> sslverify = 1 >>>>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>>>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>>>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >>>>>> >>>>>> to: >>>>>> >>>>>> [313024c0-c7bd-012f-d852-1803734d16c4] >>>>>> name = zoorepo >>>>>> baseurl = >>>>>> https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 >>>>>> >>>>>> >>>>>> >>>>>> enabled = 1 >>>>>> gpgcheck = 1 >>>>>> sslverify = 1 >>>>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>>>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>>>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >>>> >>>> So, this pains me.. especially since tools like packagekit need to >>>> enable and disable repos. If there is a solution where the name and >>>> the id are Human Readable and "As close to locale as possible" then I >>>> am fine. Image how ugly this screen would look with UUIDS. >>> My understanding is that the name does not have any constraints on what >>> characters can be used. We could generate repository label (or w/e is >>> used in the repo url using Product name, etc?) >>> >>> -d >> >> I would prefer the URl to be friendly, but I see how UUIDS will make >> it easier. So, give me a path where the IDs and names are as human >> readable as possible and I will be relent. > > Hmm. how about automatically generate labels in spirit of > http://world.std.com/~reinhold/diceware.html > ? The trick would be > guarantee uniqueness, I'll have to think about that... That's clever, but is it really necessary? I'm not opposed to using it as a way to generate labels. But you'll still want to allow a user to enter their own label at creation time. They may not want the autogenerated one. jesus -- jesus m. rodriguez | jesusr at redhat.com principal software engineer | irc: zeus red hat systems management | 919.754.4413 (w) rhce # 805008586930012 | 919.623.0080 (c) +---------------------------------------------+ | "Those who cannot remember the past | | are condemned to repeat it." | | -- George Santayana | +---------------------------------------------+ From msuchy at redhat.com Tue Aug 14 13:59:14 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Tue, 14 Aug 2012 15:59:14 +0200 Subject: [katello-devel] Licensing? In-Reply-To: <502A58FA.7010001@redhat.com> References: <502A4341.2000107@redhat.com> <502A57EB.1040605@redhat.com> <502A58FA.7010001@redhat.com> Message-ID: <502A59B2.8050500@redhat.com> On 08/14/2012 03:56 PM, Bryan Kearney wrote: > I guess a third option is to break out common code to gems or other > rails engines type reusable concepts, and then license those MIT. +1 And we done that with e.g. rubygem-forman-api. I.e. interfaces helpers can be MIT or ASF, but server and clients parts itself should IMO stay GPLv2. -- Miroslav Suchy Red Hat Systems Management Engineering From msuchy at redhat.com Tue Aug 14 14:06:34 2012 From: msuchy at redhat.com (=?ISO-8859-2?Q?Miroslav_Such=FD?=) Date: Tue, 14 Aug 2012 16:06:34 +0200 Subject: [katello-devel] Nightly builds from HEAD Message-ID: <502A5B6A.4070203@redhat.com> Strating today, we are going to build nightly from HEAD. I'm running rel-eng/build-missing-builds-in-koji.sh at 4:30 CET (22:30 EDT), which is night in both Europe and US. And it is 3 hours before next mashing, so plenty of time for building. Yum repositories are still build at: 01:30, 07:30, 13:30 and 15:30 EDT which gives you the chance, in case of broken nightly, to commit fix in morning, run: tito release koji-head and have working yum repo after lunch. -- Miroslav Suchy Red Hat Systems Management Engineering From dmitri at redhat.com Tue Aug 14 14:13:37 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 15:13:37 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A596E.5060504@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> <502A4D8E.8030602@redhat.com> <502A51FE.7010008@redhat.com> <502A596E.5060504@redhat.com> Message-ID: <502A5D11.3060809@redhat.com> On 14/08/12 02:58 PM, jesus m. rodriguez wrote: > On 08/14/2012 09:26 AM, Dmitri Dolguikh wrote: >> On 14/08/12 02:07 PM, Bryan Kearney wrote: >>> On 08/14/2012 09:04 AM, Dmitri Dolguikh wrote: >>>> On 14/08/12 02:01 PM, Bryan Kearney wrote: >>>>> On 08/14/2012 07:17 AM, Dmitri Dolguikh wrote: >>>>>> On 13/08/12 11:13 PM, Mike McCune wrote: >>>>>>> On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote: >>>>>>>> On 13/08/12 03:57 PM, Justin Sherrill wrote: >>>>>>>>> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >>>>>>>>>> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>>>>>>>>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>>>>>>>>>> This is a summary of the thread started at >>>>>>>>>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=795928 >>>>>>>>>>>> for >>>>>>>>>>>> details of the issue with environment renaming. >>>>>>>>>>>> >>>>>>>>>>>> Quite a few folks suggested using of an immutable label >>>>>>>>>>>> instead of >>>>>>>>>>>> environment name, but at the end the idea was defeated by a >>>>>>>>>>>> comment >>>>>>>>>>>> from Cliff Perry about users from locales using >>>>>>>>>>>> non-ascii-based >>>>>>>>>>>> character sets. >>>>>>>>>>>> Another issue that was discovered was the migration of already >>>>>>>>>>>> established environments from current version of Katello to >>>>>>>>>>>> the >>>>>>>>>>>> version containing the fix. My current thinking is to use >>>>>>>>>>>> environment name value as uuid for "legacy" environments. This >>>>>>>>>>>> would significantly simply upgrade, as there will be no >>>>>>>>>>>> need to >>>>>>>>>>>> regenerate entitlement certificates, etc. >>>>>>>>>>>> >>>>>>>>>>>> Katello: >>>>>>>>>>>> - introduce environment uuids (update db schema, model, >>>>>>>>>>>> etc) >>>>>>>>>>>> - update candlepin (this will include updates to schema, >>>>>>>>>>>> and >>>>>>>>>>>> resource controller) >>>>>>>>>>>> - update katello/katello cli to use uuids for environment >>>>>>>>>>>> identification >>>>>>>>>>>> - update repository-related functionality to use >>>>>>>>>>>> environment >>>>>>>>>>>> uuids >>>>>>>>>>>> - figure out/create migration from 1.0 to current >>>>>>>>>>>> >>>>>>>>>>>> Bryan, everything minus the migration bit is probably a couple >>>>>>>>>>>> days >>>>>>>>>>>> worth of work. Should I create a new story, or I can start on >>>>>>>>>>>> this >>>>>>>>>>>> right away? >>>>>>>>>>>> >>>>>>>>>>>> -d >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> katello-devel mailing list >>>>>>>>>>>> katello-devel at redhat.com >>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>>>>>>> Any idea what the redhat.repo file will look like with >>>>>>>>>>> numerical >>>>>>>>>>> ids? Or yum repolist ? >>>>>>>>>> Same as now, but with environment uuids instead on environment >>>>>>>>>> names. >>>>>>>>>> -d >>>>>>>>> >>>>>>>> Apologies, I didn't understand the question. The latter. >>>>>>>> -d >>>>>>>>> So >>>>>>>>> >>>>>>>>> [123456] >>>>>>>>> name=123456 >>>>>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>>>>>> >>>>>>>>> or >>>>>>>>> >>>>>>>>> [123456] >>>>>>>>> name=Red Hat Enterprise Linux Server 6 RPMS >>>>>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>>>>>> >>>>>>>>> >>>>>>>>> ? >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> and this really blows for our users, IMHO. You go from a >>>>>>> relatively >>>>>>> readable and clear yum configuration file that a sysadmin can >>>>>>> look at >>>>>>> quickly and understand: >>>>>>> >>>>>>> [ACME_Corporation_zoo_zoorepo] >>>>>>> name = zoorepo >>>>>>> baseurl = >>>>>>> https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> enabled = 1 >>>>>>> gpgcheck = 1 >>>>>>> sslverify = 1 >>>>>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>>>>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>>>>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >>>>>>> >>>>>>> to: >>>>>>> >>>>>>> [313024c0-c7bd-012f-d852-1803734d16c4] >>>>>>> name = zoorepo >>>>>>> baseurl = >>>>>>> https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> enabled = 1 >>>>>>> gpgcheck = 1 >>>>>>> sslverify = 1 >>>>>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>>>>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>>>>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >>>>> >>>>> So, this pains me.. especially since tools like packagekit need to >>>>> enable and disable repos. If there is a solution where the name and >>>>> the id are Human Readable and "As close to locale as possible" then I >>>>> am fine. Image how ugly this screen would look with UUIDS. >>>> My understanding is that the name does not have any constraints on >>>> what >>>> characters can be used. We could generate repository label (or w/e is >>>> used in the repo url using Product name, etc?) >>>> >>>> -d >>> >>> I would prefer the URl to be friendly, but I see how UUIDS will make >>> it easier. So, give me a path where the IDs and names are as human >>> readable as possible and I will be relent. >> >> Hmm. how about automatically generate labels in spirit of >> http://world.std.com/~reinhold/diceware.html >> ? The trick would be >> guarantee uniqueness, I'll have to think about that... > > That's clever, but is it really necessary? I'm not opposed to using it > as a way to generate labels. But you'll still want to allow a user to > enter their own label at creation time. They may not want the > autogenerated one. > we are back to discussing discrimination against users not using ascii-based character sets. Another point of contention - the resource id has to be unique, so something like this works and stays valid after w/e changes users make to the resource: http://blah.org/environments// In our case url of the resource is also its uri, and I'll put emphasis on unique here. No human can generate random enough information, and repeatedly asking the user to re-enter a bit of information is bad ui too. Much easier is to generate the bit automatically, leads to a better user interaction too. -d > jesus > > From lzap at redhat.com Tue Aug 14 14:25:19 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 16:25:19 +0200 Subject: [katello-devel] moving of systems between environments In-Reply-To: <502A4AFD.9060700@redhat.com> References: <502A4AFD.9060700@redhat.com> Message-ID: <20120814142519.GO2850@lzapx.brq.redhat.com> On Tue, Aug 14, 2012 at 01:56:29PM +0100, Dmitri Dolguikh wrote: > Hey all, > > the above functionality is in master as of yesterday. > > To move the system using web ui: on system detail screen, change the > environment name to the one you intend to move the system to. Once > completed, the system will reside in the new environment. > To move the system via cli: katello system update --org=Blah > --name=My_system --new_environment= > > To verify that the system has been moved successfully: pull > entitlement certificate and verify that the content urls have been > updated to use the new environment. Please note that if the content > that the system has been subscribed to is not available in the new > environment, the entitlement certificate is not going to have it > either. > Great. And how does a real-world scenario look like? I mean, does rhsm automatically pull entitlement certs every X hours? Or do I need to take some explicit action on the client? -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Aug 14 14:31:29 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 14 Aug 2012 16:31:29 +0200 Subject: [katello-devel] Licensing? In-Reply-To: <502A4341.2000107@redhat.com> References: <502A4341.2000107@redhat.com> Message-ID: <20120814143129.GP2850@lzapx.brq.redhat.com> I'd rather stick with GNU GPL. Do we know the reason why Aeolus have chosen non-GPL licence? Was this intentional or are they using some big bunch of ASL licenced code (therefore it was forced)? Just asking, if Aeolus was forced, we have no issues with staing on the GNU GPL. LZ On Tue, Aug 14, 2012 at 08:23:29AM -0400, Bryan Kearney wrote: > OK... > > Katello is GPLV2, and Aeolus is ASL. It would be nice to make it > easy to share code, and we know Apache is kinda a big bully around > their fancy license. We can not move to GPLV3 (like Foreman) since > that is no better [1]. Couple of options: > > 1) Katello can switch to either ASL, or MIT. > 2) Katello could dual license current and ASL/MIT > 3) Do nothing > > I dont think we need to worry about any of the backend projects, > just the rails parts. > > -- bk > > > > [1] http://www.apache.org/licenses/GPL-compatibility.html > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From jrist at redhat.com Tue Aug 14 14:32:44 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 14 Aug 2012 08:32:44 -0600 Subject: [katello-devel] Licensing? In-Reply-To: <502A59B2.8050500@redhat.com> References: <502A4341.2000107@redhat.com> <502A57EB.1040605@redhat.com> <502A58FA.7010001@redhat.com> <502A59B2.8050500@redhat.com> Message-ID: <502A618C.8080104@redhat.com> On 08/14/2012 07:59 AM, Miroslav Such? wrote: > On 08/14/2012 03:56 PM, Bryan Kearney wrote: >> I guess a third option is to break out common code to gems or other >> rails engines type reusable concepts, and then license those MIT. > > +1 And we done that with e.g. rubygem-forman-api. > I.e. interfaces helpers can be MIT or ASF, but server and clients parts > itself should IMO stay GPLv2. > +1 -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jpazdziora at redhat.com Tue Aug 14 14:32:36 2012 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 14 Aug 2012 16:32:36 +0200 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A5D11.3060809@redhat.com> References: <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> <502A4D8E.8030602@redhat.com> <502A51FE.7010008@redhat.com> <502A596E.5060504@redhat.com> <502A5D11.3060809@redhat.com> Message-ID: <20120814143236.GJ11232@redhat.com> On Tue, Aug 14, 2012 at 03:13:37PM +0100, Dmitri Dolguikh wrote: > > > >That's clever, but is it really necessary? I'm not opposed to > >using it as a way to generate labels. But you'll still want to > >allow a user to enter their own label at creation time. They may > >not want the autogenerated one. > > we are back to discussing discrimination against users not using > ascii-based character sets. Many parts of the computer systems have restrictions on the character sets. > In our case url of the resource is also its uri, and I'll put > emphasis on unique here. No human can generate random enough > information, and repeatedly asking the user to re-enter a bit of > information is bad ui too. Much easier is to generate the bit > automatically, leads to a better user interaction too. So the solution is to do an equivalent of iconv -f utf8 -t us-ascii//TRANSLIT plus change spaces and unprintable characters to underscores or dashes, possibly in lowercase, to come up with some default. Then check if the result is US-ASCII and if not, pre-fill some generated string (UUID, possibly) there instead. And let the user either accept the pre-filled default, or change it. You get the best of both worlds -- label resembling the name where possible, and something that the user cannot possibly remember but still generated for them in case the Kanji cannot be transliterated easily. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat From matt.wagner at redhat.com Tue Aug 14 14:34:15 2012 From: matt.wagner at redhat.com (Matt Wagner) Date: Tue, 14 Aug 2012 10:34:15 -0400 Subject: [katello-devel] RFC: Notification system In-Reply-To: <502A5873.8010007@redhat.com> References: <20120813212655.GA21991@mawagner-desktop.usersys.redhat.com> <502A1CEC.9050506@redhat.com> <20120814120052.GG4597@redhat.com> <502A409F.5090001@redhat.com> <20120814134339.GB1868@mawagner-desktop.usersys.redhat.com> <502A5873.8010007@redhat.com> Message-ID: <20120814143415.GD1868@mawagner-desktop.usersys.redhat.com> On Tue, Aug 14, 2012 at 09:53:55AM -0400, Bryan Kearney wrote: > I see a couple of stages. > > First would be Engine X (Perhaps not in ruby) publishes an event > which a usr can register to. Data from the event is used to create a > text email which goes out. > > Second, fancier CEP (if I get 10 events in 2 minutes, send out an email). > > Third, engine can query data stores to create their own events. Ah, this is actually not so far off from something we've kicked around as an idea in the past, pertaining to logging and event notification. We liked the idea of a sort of central event daemon people can write to, and various applications can register webhooks or something of the sort to receive a notification of events matching various criteria -- so that Component X can ask to be notified any time an instance launches, and Component Y could ask to be notified of authentication failures. Adding email to that should be pretty easy. Bonus points for somehow integrating https://github.com/paulasmuth/fnordmetric/ with this. Though I'm still worried about making this too complicated. I think this is a good end goal, but I don't want us to be delayed from implementing notifications at all while we design a complex system. -- Matt From hbrock at redhat.com Tue Aug 14 14:37:09 2012 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 14 Aug 2012 10:37:09 -0400 Subject: [katello-devel] Licensing? In-Reply-To: <20120814143129.GP2850@lzapx.brq.redhat.com> References: <502A4341.2000107@redhat.com> <20120814143129.GP2850@lzapx.brq.redhat.com> Message-ID: <20120814143709.GC9380@redhat.com> On Tue, Aug 14, 2012 at 04:31:29PM +0200, Lukas Zapletal wrote: > I'd rather stick with GNU GPL. > > Do we know the reason why Aeolus have chosen non-GPL licence? Was this > intentional or are they using some big bunch of ASL licenced code > (therefore it was forced)? Just asking, if Aeolus was forced, we have no > issues with staing on the GNU GPL. It was intentional. We felt the Apache license was much closer to what the rest of the Ruby world was doing upstream, and also that it served our product goals better. --Hugh > > On Tue, Aug 14, 2012 at 08:23:29AM -0400, Bryan Kearney wrote: > > OK... > > > > Katello is GPLV2, and Aeolus is ASL. It would be nice to make it > > easy to share code, and we know Apache is kinda a big bully around > > their fancy license. We can not move to GPLV3 (like Foreman) since > > that is no better [1]. Couple of options: > > > > 1) Katello can switch to either ASL, or MIT. > > 2) Katello could dual license current and ASL/MIT > > 3) Do nothing > > > > I dont think we need to worry about any of the backend projects, > > just the rails parts. > > > > -- bk > > > > > > > > [1] http://www.apache.org/licenses/GPL-compatibility.html > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine -- == 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 paji at redhat.com Tue Aug 14 14:50:11 2012 From: paji at redhat.com (Partha Aji) Date: Tue, 14 Aug 2012 10:50:11 -0400 (EDT) Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A5D11.3060809@redhat.com> Message-ID: <124689829.5364739.1344955811813.JavaMail.root@redhat.com> > we are back to discussing discrimination against users not using > ascii-based character sets. Another point of contention - the > resource > id has to be unique, so something like this works and stays valid > after > w/e changes users make to the resource: > http://blah.org/environments// > > In our case url of the resource is also its uri, and I'll put > emphasis > on unique here. No human can generate random enough information, and > repeatedly asking the user to re-enter a bit of information is bad ui > too. Much easier is to generate the bit automatically, leads to a > better > user interaction too. > > -d Not sure I agree with "repeatedly asking the user to re-enter a bit of information is bad ui", I mean I 'd think complaining on duplicate labels and have em re-enter is not that much out of the norm is it? May be we can somehow indicate if the label is already taken as its being typed, if this ends up being a serious pain point. That being said, I am ok with auto-generated UUIDish labels IF the user leaves the label field blank at the time of creation. Partha From dmitri at redhat.com Tue Aug 14 14:59:53 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 15:59:53 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <20120814143236.GJ11232@redhat.com> References: <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> <502A4D8E.8030602@redhat.com> <502A51FE.7010008@redhat.com> <502A596E.5060504@redhat.com> <502A5D11.3060809@redhat.com> <20120814143236.GJ11232@redhat.com> Message-ID: <502A67E9.7080704@redhat.com> On 14/08/12 03:32 PM, Jan Pazdziora wrote: > On Tue, Aug 14, 2012 at 03:13:37PM +0100, Dmitri Dolguikh wrote: >>> That's clever, but is it really necessary? I'm not opposed to >>> using it as a way to generate labels. But you'll still want to >>> allow a user to enter their own label at creation time. They may >>> not want the autogenerated one. >> we are back to discussing discrimination against users not using >> ascii-based character sets. > Many parts of the computer systems have restrictions on the character > sets. > >> In our case url of the resource is also its uri, and I'll put >> emphasis on unique here. No human can generate random enough >> information, and repeatedly asking the user to re-enter a bit of >> information is bad ui too. Much easier is to generate the bit >> automatically, leads to a better user interaction too. > So the solution is to do an equivalent of > > iconv -f utf8 -t us-ascii//TRANSLIT > > plus change spaces and unprintable characters to underscores or > dashes, possibly in lowercase, to come up with some default. Then > check if the result is US-ASCII and if not, pre-fill some > generated string (UUID, possibly) there instead. And let the user > either accept the pre-filled default, or change it. > > You get the best of both worlds -- label resembling the name where > possible, and something that the user cannot possibly remember but > still generated for them in case the Kanji cannot be transliterated > easily. > I kept forgetting another bit, which is uniqueness of the identifier we put in the url. The issue with human-generated one is, obviously, lack of randomness, and thus handling of things like removed-created with the same id. I'm not sure why this is such a controversial point, but perhaps the fact that Katello is part of CloudForms which is going to have a rather large audience and therefore we can't quite predict how and by whom our API is going to be used, so it's important to maintain correctness would explain my points? All I'm trying to do by these discussions is to maintain the principle of least surprise on the API level. -d From omaciel at redhat.com Tue Aug 14 15:27:52 2012 From: omaciel at redhat.com (Og Maciel) Date: Tue, 14 Aug 2012 11:27:52 -0400 (EDT) Subject: [katello-devel] Experience contributing a new feature as a user In-Reply-To: <598284290.5131413.1344957016716.JavaMail.root@redhat.com> Message-ID: <2036058174.5152198.1344958072417.JavaMail.root@redhat.com> A couple of weeks ago I decided to implement a new feature to the user create cli method: provide a default locale for the user being created. The use case is: as an administrator I want to create multiple user accounts from the cli and specify their default locale for the web interface. The pull request went in (https://github.com/Katello/katello/pull/436) and after a couple of very useful comments, I made the necessary changes based on this feedback. So far so good. Then I was asked to write tests for my changes... sure, why not? After spending some time learning how cli tests are performed and getting some pointers from someone, I took a stab at adding to the minimalistic cli tests we currently have for user creation.Great, right? Another round of feedback, and this time I was asked to write rspec tests... oy! So I brushed up my rspec (I'm a python guy mind you) and wrote a very quick and dirty "proof of concept" test and tried to run it... but was stuck with several dependency errors... bundle install should bail me out, right? No! At the end of a very painful cycle of gem install this, try again, fail, repeat, I got stuck with a dependency (pg gem btw) which would not install cleanly. I turned for help on #katello and to make a long story short, was told that it would be easier to do this if I had katello installed! Ok, I decided to take a few hours break and returned to this task again today... here's what I did: # git clone https://github.com/Katello/katello.git # cd katello/src/ # bundle install Fetching source index for http://repos.fedorapeople.org/repos/katello/gems/ Could not find gem 'apipie-rails (>= 0)' in any of the gem sources listed in your Gemfile. Oh... I remember Ivan sent an email about this... I should be able to gem install it... # gem install redcarpet Fetching: redcarpet-2.1.1.gem (100%) Building native extensions. This could take a while... ERROR: Error installing redcarpet: ERROR: Failed to build gem native extension. /usr/bin/ruby extconf.rb mkmf.rb can't find header files for ruby at /usr/lib/ruby/ruby.h Ohhh I need ruby-devel too # yum -y install ruby-devel # gem install redcarpet Building native extensions. This could take a while... .. ERROR: Error installing redcarpet: ERROR: Failed to build gem native extension. /usr/bin/ruby extconf.rb creating Makefile make gcc -I. -I/usr/lib64/ruby/1.8/x86_64-linux -I/usr/lib64/ruby/1.8/x86_64-linux -I. -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 buffer.c make: gcc: Command not found make: *** [buffer.o] Error 127 Sigh... # yum -y install gcc # gem install redcarpet # bundle install Fetching source index for http://repos.fedorapeople.org/repos/katello/gems/ Could not find gem 'apipie-rails (>= 0)' in any of the gem sources listed in your Gemfile. Back to square 1! My point for this email is not to blame anyone but to ask the following question: how can we make it easier for people to contribute to katello without having to jump through endless hoops??? Cheers, -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From jsherril at redhat.com Tue Aug 14 15:42:16 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 14 Aug 2012 11:42:16 -0400 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A67E9.7080704@redhat.com> References: <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> <502A4D8E.8030602@redhat.com> <502A51FE.7010008@redhat.com> <502A596E.5060504@redhat.com> <502A5D11.3060809@redhat.com> <20120814143236.GJ11232@redhat.com> <502A67E9.7080704@redhat.com> Message-ID: <502A71D8.4010609@redhat.com> On 08/14/2012 10:59 AM, Dmitri Dolguikh wrote: > On 14/08/12 03:32 PM, Jan Pazdziora wrote: >> On Tue, Aug 14, 2012 at 03:13:37PM +0100, Dmitri Dolguikh wrote: >>>> That's clever, but is it really necessary? I'm not opposed to >>>> using it as a way to generate labels. But you'll still want to >>>> allow a user to enter their own label at creation time. They may >>>> not want the autogenerated one. >>> we are back to discussing discrimination against users not using >>> ascii-based character sets. >> Many parts of the computer systems have restrictions on the character >> sets. >> >>> In our case url of the resource is also its uri, and I'll put >>> emphasis on unique here. No human can generate random enough >>> information, and repeatedly asking the user to re-enter a bit of >>> information is bad ui too. Much easier is to generate the bit >>> automatically, leads to a better user interaction too. >> So the solution is to do an equivalent of >> >> iconv -f utf8 -t us-ascii//TRANSLIT >> >> plus change spaces and unprintable characters to underscores or >> dashes, possibly in lowercase, to come up with some default. Then >> check if the result is US-ASCII and if not, pre-fill some >> generated string (UUID, possibly) there instead. And let the user >> either accept the pre-filled default, or change it. >> >> You get the best of both worlds -- label resembling the name where >> possible, and something that the user cannot possibly remember but >> still generated for them in case the Kanji cannot be transliterated >> easily. >> > I kept forgetting another bit, which is uniqueness of the identifier > we put in the url. The issue with human-generated one is, obviously, > lack of randomness, and thus handling of things like removed-created > with the same id. > I'm not sure why this is an issue. If the user is creating an environment in an org and the label already exists, throw an error, otherwise don't? > I'm not sure why this is such a controversial point, but perhaps the > fact that Katello is part of CloudForms which is going to have a > rather large audience and therefore we can't quite predict how and by > whom our API is going to be used, so it's important to maintain > correctness would explain my points? > > All I'm trying to do by these discussions is to maintain the principle > of least surprise on the API level. > -d > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Tue Aug 14 15:45:58 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 11:45:58 -0400 Subject: [katello-devel] moving of systems between environments In-Reply-To: <20120814142519.GO2850@lzapx.brq.redhat.com> References: <502A4AFD.9060700@redhat.com> <20120814142519.GO2850@lzapx.brq.redhat.com> Message-ID: <502A72B6.3040307@redhat.com> On 08/14/2012 10:25 AM, Lukas Zapletal wrote: > On Tue, Aug 14, 2012 at 01:56:29PM +0100, Dmitri Dolguikh wrote: >> Hey all, >> >> the above functionality is in master as of yesterday. >> >> To move the system using web ui: on system detail screen, change the >> environment name to the one you intend to move the system to. Once >> completed, the system will reside in the new environment. >> To move the system via cli: katello system update --org=Blah >> --name=My_system --new_environment= >> >> To verify that the system has been moved successfully: pull >> entitlement certificate and verify that the content urls have been >> updated to use the new environment. Please note that if the content >> that the system has been subscribed to is not available in the new >> environment, the entitlement certificate is not going to have it >> either. >> > > Great. And how does a real-world scenario look like? I mean, does rhsm > automatically pull entitlement certs every X hours? Or do I need to take > some explicit action on the client? > > It pulls every 4 hours or when you run yum the next time. -- bk From bkearney at redhat.com Tue Aug 14 16:10:45 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 12:10:45 -0400 Subject: [katello-devel] RFC: Notification system In-Reply-To: <20120814143415.GD1868@mawagner-desktop.usersys.redhat.com> References: <20120813212655.GA21991@mawagner-desktop.usersys.redhat.com> <502A1CEC.9050506@redhat.com> <20120814120052.GG4597@redhat.com> <502A409F.5090001@redhat.com> <20120814134339.GB1868@mawagner-desktop.usersys.redhat.com> <502A5873.8010007@redhat.com> <20120814143415.GD1868@mawagner-desktop.usersys.redhat.com> Message-ID: <502A7885.3070503@redhat.com> On 08/14/2012 10:34 AM, Matt Wagner wrote: > On Tue, Aug 14, 2012 at 09:53:55AM -0400, Bryan Kearney wrote: >> I see a couple of stages. >> >> First would be Engine X (Perhaps not in ruby) publishes an event >> which a usr can register to. Data from the event is used to create a >> text email which goes out. >> >> Second, fancier CEP (if I get 10 events in 2 minutes, send out an email). >> >> Third, engine can query data stores to create their own events. > > Ah, this is actually not so far off from something we've kicked around > as an idea in the past, pertaining to logging and event notification. We > liked the idea of a sort of central event daemon people can write to, > and various applications can register webhooks or something of the sort > to receive a notification of events matching various criteria -- so that > Component X can ask to be notified any time an instance launches, and > Component Y could ask to be notified of authentication failures. Adding > email to that should be pretty easy. > > Bonus points for somehow integrating > https://github.com/paulasmuth/fnordmetric/ with this. > > Though I'm still worried about making this too complicated. I think this > is a good end goal, but I don't want us to be delayed from implementing > notifications at all while we design a complex system. > > -- Matt > ACK..this is overkill for what you need, but something to keep in mind. -- bk From bkearney at redhat.com Tue Aug 14 16:11:49 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 12:11:49 -0400 Subject: [katello-devel] It's Alive: New Katello Site and Blog In-Reply-To: <502A5620.1080308@redhat.com> References: <502A5620.1080308@redhat.com> Message-ID: <502A78C5.80606@redhat.com> I can not wait see screencasts up there :) -- bk On 08/14/2012 09:44 AM, Eric Helms wrote: > On the back of the release of Katello 1.0 and as part of our increased > community efforts, the Katello team has launched a new site and blog. > The site will continue to grow and add new content so make sure you > check back often. > > http://www.katello.org/ > > The Katello blog is a new feature to the Katello site and will encompass > posts from community members geared towards how to use and develop > Katello features. Look here first for new announcements! > > http://www.katello.org/blog/ > > > *Did I hear you say Katello 1.0 was released?* > Read about the official announcement here > http://www.katello.org/katello-1-0-released/ > > *Want to get involved?* > Whether you are a user or a developer, visit our community page to find > out how to get started working with Katello: > > http://www.katello.org/get-involved/ > > *Looking for videos on how to use Katello?* > Check back frequently to our YouTube channel > http://www.youtube.com/user/KatelloProject or watch directly on the site > http://www.katello.org/videos/ > > *Want to know what else we are up to? * > Follow us on Twitter http://twitter.com/Katello_Project and Google+ > https://plus.google.com/106761937932528197228/posts > > *Have questions?* > Start here http://www.katello.org/faq/ and come find us on Freenode IRC > at #katello or directly from the site at http://www.katello.org/irc/. > Users are also encouraged to send questions to the official users > mailing list - katello at lists.fedorahosted.org > > *I just want to get to the code! > *Visit our official code repository hosted on Github: > https://github.com/Katello/katello > > If you would like to contribute, please send an email requesting as much. > > > > The Katello website was created using WordPress and harnessing the > awesome hosting powers of OpenShift. > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From dmitri at redhat.com Tue Aug 14 16:15:58 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 17:15:58 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A71D8.4010609@redhat.com> References: <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> <502A4D8E.8030602@redhat.com> <502A51FE.7010008@redhat.com> <502A596E.5060504@redhat.com> <502A5D11.3060809@redhat.com> <20120814143236.GJ11232@redhat.com> <502A67E9.7080704@redhat.com> <502A71D8.4010609@redhat.com> Message-ID: <502A79BE.8070403@redhat.com> On 14/08/12 04:42 PM, Justin Sherrill wrote: > On 08/14/2012 10:59 AM, Dmitri Dolguikh wrote: >> On 14/08/12 03:32 PM, Jan Pazdziora wrote: >>> On Tue, Aug 14, 2012 at 03:13:37PM +0100, Dmitri Dolguikh wrote: >>>>> That's clever, but is it really necessary? I'm not opposed to >>>>> using it as a way to generate labels. But you'll still want to >>>>> allow a user to enter their own label at creation time. They may >>>>> not want the autogenerated one. >>>> we are back to discussing discrimination against users not using >>>> ascii-based character sets. >>> Many parts of the computer systems have restrictions on the character >>> sets. >>> >>>> In our case url of the resource is also its uri, and I'll put >>>> emphasis on unique here. No human can generate random enough >>>> information, and repeatedly asking the user to re-enter a bit of >>>> information is bad ui too. Much easier is to generate the bit >>>> automatically, leads to a better user interaction too. >>> So the solution is to do an equivalent of >>> >>> iconv -f utf8 -t us-ascii//TRANSLIT >>> >>> plus change spaces and unprintable characters to underscores or >>> dashes, possibly in lowercase, to come up with some default. Then >>> check if the result is US-ASCII and if not, pre-fill some >>> generated string (UUID, possibly) there instead. And let the user >>> either accept the pre-filled default, or change it. >>> >>> You get the best of both worlds -- label resembling the name where >>> possible, and something that the user cannot possibly remember but >>> still generated for them in case the Kanji cannot be transliterated >>> easily. >>> >> I kept forgetting another bit, which is uniqueness of the identifier >> we put in the url. The issue with human-generated one is, obviously, >> lack of randomness, and thus handling of things like removed-created >> with the same id. >> > > I'm not sure why this is an issue. If the user is creating an > environment in an org and the label already exists, throw an error, > otherwise don't? We are going to have a problem distinguishing between a deleted environment and a just created environment with the same label then. This is a problem because the url's are out of our hands once we generate a given resource. Since we can't control how a given url is being used, and can't notify the user that it has changed, we need to make sure that either points to the original resource, or returns a 404. We are part of CloudForms, I don't think we can predict how our API is going to be used. As an example look at what Heroku did with Amazon WS, and how people use Heroku. In this light: some piece of code on the client side uses API to enumerate available environments. Some time passes. Some admin deletes one of the environments. Some time passes. Some admin creates an environment with the same label. The original client re-syncs environments. Instead of detecting a deleted environment, it sees that the environment is there and alive. The resulting issues are going to be a living hell to debug. We could keep track of labels that have been used in a given Katello install. But that would mean some sort of synchronization between individual instances of Katello in a given install, something I'd rather avoid if possible. -d > >> I'm not sure why this is such a controversial point, but perhaps the >> fact that Katello is part of CloudForms which is going to have a >> rather large audience and therefore we can't quite predict how and by >> whom our API is going to be used, so it's important to maintain >> correctness would explain my points? >> >> All I'm trying to do by these discussions is to maintain the >> principle of least surprise on the API level. >> -d >> >> >> >> _______________________________________________ >> 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 Aug 14 16:28:33 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 14 Aug 2012 12:28:33 -0400 Subject: [katello-devel] Fwd: Re: Design of Forms In-Reply-To: <20120814162608.GF9380@redhat.com> References: <20120814162608.GF9380@redhat.com> Message-ID: <502A7CB1.9010907@redhat.com> I like it..although I fear we do not have enough space in tupane. -- bk -------- Original Message -------- Subject: Re: Design of Forms Date: Tue, 14 Aug 2012 12:26:09 -0400 From: Hugh Brock Reply-To: Hugh O. Brock To: Jarom?r Coufal CC: aeolus-devel On Tue, Aug 14, 2012 at 05:32:19PM +0200, Jarom?r Coufal wrote: > One more "hello" :) > > another thing I have designed is a layout and behavior of forms - > you can check it here: > > http://codepen.io/coufalj/pen/qiEkH > > Still working on responsive, but it is not that important in this > stage. What do you think about this concept of forms used across our > whole application? > > -- Jarda Love it Jarda. I'll leave it to those with better eyes than mine to critique, but I think the consistency of the controls is great. --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 jrist at redhat.com Tue Aug 14 16:45:29 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 14 Aug 2012 10:45:29 -0600 Subject: [katello-devel] Fwd: Re: Design of Forms In-Reply-To: <502A7CB1.9010907@redhat.com> References: <20120814162608.GF9380@redhat.com> <502A7CB1.9010907@redhat.com> Message-ID: <502A80A9.5080004@redhat.com> On 08/14/2012 10:28 AM, Bryan Kearney wrote: > I like it..although I fear we do not have enough space in tupane. > > -- bk > > > > -------- Original Message -------- > Subject: Re: Design of Forms > Date: Tue, 14 Aug 2012 12:26:09 -0400 > From: Hugh Brock > Reply-To: Hugh O. Brock > To: Jarom?r Coufal > CC: aeolus-devel > > On Tue, Aug 14, 2012 at 05:32:19PM +0200, Jarom?r Coufal wrote: >> One more "hello" :) >> >> another thing I have designed is a layout and behavior of forms - >> you can check it here: >> >> http://codepen.io/coufalj/pen/qiEkH >> >> Still working on responsive, but it is not that important in this >> stage. What do you think about this concept of forms used across our >> whole application? >> >> -- Jarda > > Love it Jarda. I'll leave it to those with better eyes than mine to > critique, but I think the consistency of the controls is great. > > --Hugh > I disagree. We can bring the labels above the forms and save a ton of left to right space in the pane. Will bring up next week. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jsherril at redhat.com Tue Aug 14 16:47:31 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 14 Aug 2012 12:47:31 -0400 Subject: [katello-devel] Fwd: Re: Design of Forms In-Reply-To: <502A80A9.5080004@redhat.com> References: <20120814162608.GF9380@redhat.com> <502A7CB1.9010907@redhat.com> <502A80A9.5080004@redhat.com> Message-ID: <502A8123.9090809@redhat.com> On 08/14/2012 12:45 PM, Jason Rist wrote: > On 08/14/2012 10:28 AM, Bryan Kearney wrote: >> I like it..although I fear we do not have enough space in tupane. >> >> -- bk >> >> >> >> -------- Original Message -------- >> Subject: Re: Design of Forms >> Date: Tue, 14 Aug 2012 12:26:09 -0400 >> From: Hugh Brock >> Reply-To: Hugh O. Brock >> To: Jarom?r Coufal >> CC: aeolus-devel >> >> On Tue, Aug 14, 2012 at 05:32:19PM +0200, Jarom?r Coufal wrote: >>> One more "hello" :) >>> >>> another thing I have designed is a layout and behavior of forms - >>> you can check it here: >>> >>> http://codepen.io/coufalj/pen/qiEkH >>> >>> Still working on responsive, but it is not that important in this >>> stage. What do you think about this concept of forms used across our >>> whole application? >>> >>> -- Jarda >> Love it Jarda. I'll leave it to those with better eyes than mine to >> critique, but I think the consistency of the controls is great. >> >> --Hugh >> > I disagree. We can bring the labels above the forms and save a ton of > left to right space in the pane. Will bring up next week. > > -J > I would be a tad more interesting with jeditable, but imagine it could function the same, just when you click to edit vs when you hover over. -Justin From mmccune at redhat.com Tue Aug 14 16:50:59 2012 From: mmccune at redhat.com (Mike McCune) Date: Tue, 14 Aug 2012 09:50:59 -0700 Subject: [katello-devel] Fwd: Re: Design of Forms In-Reply-To: <502A80A9.5080004@redhat.com> References: <20120814162608.GF9380@redhat.com> <502A7CB1.9010907@redhat.com> <502A80A9.5080004@redhat.com> Message-ID: <502A81F3.2050607@redhat.com> On 08/14/2012 09:45 AM, Jason Rist wrote: > On 08/14/2012 10:28 AM, Bryan Kearney wrote: >> I like it..although I fear we do not have enough space in tupane. >> >> -- bk >> >> >> >> -------- Original Message -------- >> Subject: Re: Design of Forms >> Date: Tue, 14 Aug 2012 12:26:09 -0400 >> From: Hugh Brock >> Reply-To: Hugh O. Brock >> To: Jarom?r Coufal >> CC: aeolus-devel >> >> On Tue, Aug 14, 2012 at 05:32:19PM +0200, Jarom?r Coufal wrote: >>> One more "hello" :) >>> >>> another thing I have designed is a layout and behavior of forms - >>> you can check it here: >>> >>> http://codepen.io/coufalj/pen/qiEkH >>> >>> Still working on responsive, but it is not that important in this >>> stage. What do you think about this concept of forms used across our >>> whole application? >>> >>> -- Jarda >> >> Love it Jarda. I'll leave it to those with better eyes than mine to >> critique, but I think the consistency of the controls is great. >> >> --Hugh >> > > I disagree. We can bring the labels above the forms and save a ton of > left to right space in the pane. Will bring up next week. > > -J > agreed, plenty of space to work with. Mike From jrist at redhat.com Tue Aug 14 16:51:16 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 14 Aug 2012 10:51:16 -0600 Subject: [katello-devel] Breaking Good Habits Message-ID: <502A8204.2050306@redhat.com> Fascinating talk on "breaking good habits". What does that mean? Watch. http://vimeo.com/44773888 -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From dmitri at redhat.com Tue Aug 14 16:56:20 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 14 Aug 2012 17:56:20 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A51FE.7010008@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> <502A4D8E.8030602@redhat.com> <502A51FE.7010008@redhat.com> Message-ID: <502A8334.10109@redhat.com> On 14/08/12 02:26 PM, Dmitri Dolguikh wrote: > On 14/08/12 02:07 PM, Bryan Kearney wrote: >> On 08/14/2012 09:04 AM, Dmitri Dolguikh wrote: >>> On 14/08/12 02:01 PM, Bryan Kearney wrote: >>>> On 08/14/2012 07:17 AM, Dmitri Dolguikh wrote: >>>>> On 13/08/12 11:13 PM, Mike McCune wrote: >>>>>> On 08/13/2012 08:00 AM, Dmitri Dolguikh wrote: >>>>>>> On 13/08/12 03:57 PM, Justin Sherrill wrote: >>>>>>>> On 08/13/2012 10:55 AM, Dmitri Dolguikh wrote: >>>>>>>>> On 13/08/12 03:52 PM, Justin Sherrill wrote: >>>>>>>>>> On 08/13/2012 10:45 AM, Dmitri Dolguikh wrote: >>>>>>>>>>> This is a summary of the thread started at >>>>>>>>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please see >>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=795928 for >>>>>>>>>>> details of the issue with environment renaming. >>>>>>>>>>> >>>>>>>>>>> Quite a few folks suggested using of an immutable label >>>>>>>>>>> instead of >>>>>>>>>>> environment name, but at the end the idea was defeated by a >>>>>>>>>>> comment >>>>>>>>>>> from Cliff Perry about users from locales using non-ascii-based >>>>>>>>>>> character sets. >>>>>>>>>>> Another issue that was discovered was the migration of already >>>>>>>>>>> established environments from current version of Katello to the >>>>>>>>>>> version containing the fix. My current thinking is to use >>>>>>>>>>> environment name value as uuid for "legacy" environments. This >>>>>>>>>>> would significantly simply upgrade, as there will be no need to >>>>>>>>>>> regenerate entitlement certificates, etc. >>>>>>>>>>> >>>>>>>>>>> Katello: >>>>>>>>>>> - introduce environment uuids (update db schema, model, etc) >>>>>>>>>>> - update candlepin (this will include updates to schema, and >>>>>>>>>>> resource controller) >>>>>>>>>>> - update katello/katello cli to use uuids for environment >>>>>>>>>>> identification >>>>>>>>>>> - update repository-related functionality to use environment >>>>>>>>>>> uuids >>>>>>>>>>> - figure out/create migration from 1.0 to current >>>>>>>>>>> >>>>>>>>>>> Bryan, everything minus the migration bit is probably a couple >>>>>>>>>>> days >>>>>>>>>>> worth of work. Should I create a new story, or I can start >>>>>>>>>>> on this >>>>>>>>>>> right away? >>>>>>>>>>> >>>>>>>>>>> -d >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> katello-devel mailing list >>>>>>>>>>> katello-devel at redhat.com >>>>>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>>>>>> Any idea what the redhat.repo file will look like with numerical >>>>>>>>>> ids? Or yum repolist ? >>>>>>>>> Same as now, but with environment uuids instead on environment >>>>>>>>> names. >>>>>>>>> -d >>>>>>>> >>>>>>> Apologies, I didn't understand the question. The latter. >>>>>>> -d >>>>>>>> So >>>>>>>> >>>>>>>> [123456] >>>>>>>> name=123456 >>>>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>>>>> >>>>>>>> or >>>>>>>> >>>>>>>> [123456] >>>>>>>> name=Red Hat Enterprise Linux Server 6 RPMS >>>>>>>> baseurl=http://hostname/pulp/ACME_Corporation/123456/repo/ >>>>>>>> >>>>>>>> >>>>>>>> ? >>>>>>>> >>>>>> >>>>>> >>>>>> and this really blows for our users, IMHO. You go from a relatively >>>>>> readable and clear yum configuration file that a sysadmin can >>>>>> look at >>>>>> quickly and understand: >>>>>> >>>>>> [ACME_Corporation_zoo_zoorepo] >>>>>> name = zoorepo >>>>>> baseurl = >>>>>> https://katello.example.com/pulp/repos/ACME_Corporation/dev//custom/zoo/zoorepo >>>>>> >>>>>> >>>>>> >>>>>> enabled = 1 >>>>>> gpgcheck = 1 >>>>>> sslverify = 1 >>>>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>>>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>>>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >>>>>> >>>>>> to: >>>>>> >>>>>> [313024c0-c7bd-012f-d852-1803734d16c4] >>>>>> name = zoorepo >>>>>> baseurl = >>>>>> https://katello.example.com/pulp/repos/ACME_Corporation/83ef9ef0-c7bd-012f-d852-1803734d16c4//custom/zoo/313024c0-c7bd-012f-d852-1803734d16c4 >>>>>> >>>>>> >>>>>> >>>>>> enabled = 1 >>>>>> gpgcheck = 1 >>>>>> sslverify = 1 >>>>>> sslcacert = /etc/rhsm/ca/candlepin-local.pem >>>>>> sslclientkey = /etc/pki/entitlement/3783882558646362292-key.pem >>>>>> sslclientcert = /etc/pki/entitlement/3783882558646362292.pem >>>> >>>> So, this pains me.. especially since tools like packagekit need to >>>> enable and disable repos. If there is a solution where the name and >>>> the id are Human Readable and "As close to locale as possible" then I >>>> am fine. Image how ugly this screen would look with UUIDS. >>> My understanding is that the name does not have any constraints on what >>> characters can be used. We could generate repository label (or w/e is >>> used in the repo url using Product name, etc?) >>> >>> -d >> >> I would prefer the URl to be friendly, but I see how UUIDS will make >> it easier. So, give me a path where the IDs and names are as human >> readable as possible and I will be relent. > > Hmm. how about automatically generate labels in spirit of > http://world.std.com/~reinhold/diceware.html > ? The trick would be > guarantee uniqueness, I'll have to think about that... Looking at pulp docs, I see that the base url in yum repository configuration file, and the url used to access repositories via pulp API are completely different. As long the urls used in yum configuration file are not being used to access resources managed directly by Katello, and as long as Pulp doesn't enforce uniqueness of those urls, I think we can make them as human readable as we'd like. Alternatively, we could use a couple approaches to make uuids more human readable, but at the expense of length. One approach would be to break up uuid into eight 16-bit groups, and then use each group as an index in the common dictionary. Yet another approach would be to use Bubble Babble encoding ( http://wiki.yak.net/589/Bubble_Babble_Encoding.txt) on uuid. In that case, 83ef9ef0-c7bd-012f-d852-1803734d16c4 will be converted to xobov-zyloz-byxox-xucor-toxax-xebed-zyxox-xukah-doxix-xekab-fosig-tuhes-guxix. I don't think either of those are worth the effort, however. -d > > -d >> >> -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrao at redhat.com Tue Aug 14 17:47:44 2012 From: mrao at redhat.com (Malini Rao) Date: Tue, 14 Aug 2012 13:47:44 -0400 (EDT) Subject: [katello-devel] Fwd: Re: Design of Forms In-Reply-To: <502A81F3.2050607@redhat.com> Message-ID: <871416745.9460894.1344966464348.JavaMail.root@redhat.com> There are several great ideas here to consider and we definitely need to see if it works within the tu-pane but also all other major paradigms where forms are in use. UXD team has also begun an exercise around forms and lists ( initial focus was more on display/ visual than changing any existing interactions) but this can easily be drawn together to take the best of each. We will also be happy to bring that work in for any discussions next week around this topic. Thanks Malini ----- Original Message ----- From: "Mike McCune" To: jrist at redhat.com Cc: katello-devel at redhat.com Sent: Tuesday, August 14, 2012 12:50:59 PM Subject: Re: [katello-devel] Fwd: Re: Design of Forms On 08/14/2012 09:45 AM, Jason Rist wrote: > On 08/14/2012 10:28 AM, Bryan Kearney wrote: >> I like it..although I fear we do not have enough space in tupane. >> >> -- bk >> >> >> >> -------- Original Message -------- >> Subject: Re: Design of Forms >> Date: Tue, 14 Aug 2012 12:26:09 -0400 >> From: Hugh Brock >> Reply-To: Hugh O. Brock >> To: Jarom?r Coufal >> CC: aeolus-devel >> >> On Tue, Aug 14, 2012 at 05:32:19PM +0200, Jarom?r Coufal wrote: >>> One more "hello" :) >>> >>> another thing I have designed is a layout and behavior of forms - >>> you can check it here: >>> >>> http://codepen.io/coufalj/pen/qiEkH >>> >>> Still working on responsive, but it is not that important in this >>> stage. What do you think about this concept of forms used across our >>> whole application? >>> >>> -- Jarda >> >> Love it Jarda. I'll leave it to those with better eyes than mine to >> critique, but I think the consistency of the controls is great. >> >> --Hugh >> > > I disagree. We can bring the labels above the forms and save a ton of > left to right space in the pane. Will bring up next week. > > -J > agreed, plenty of space to work with. Mike _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Wed Aug 15 00:35:39 2012 From: mmccune at redhat.com (Mike McCune) Date: Tue, 14 Aug 2012 17:35:39 -0700 Subject: [katello-devel] moving of systems between environments In-Reply-To: <20120814142519.GO2850@lzapx.brq.redhat.com> References: <502A4AFD.9060700@redhat.com> <20120814142519.GO2850@lzapx.brq.redhat.com> Message-ID: <502AEEDB.3070709@redhat.com> On 08/14/2012 07:25 AM, Lukas Zapletal wrote: > On Tue, Aug 14, 2012 at 01:56:29PM +0100, Dmitri Dolguikh wrote: >> Hey all, >> >> the above functionality is in master as of yesterday. >> >> To move the system using web ui: on system detail screen, change the >> environment name to the one you intend to move the system to. Once >> completed, the system will reside in the new environment. >> To move the system via cli: katello system update --org=Blah >> --name=My_system --new_environment= >> >> To verify that the system has been moved successfully: pull >> entitlement certificate and verify that the content urls have been >> updated to use the new environment. Please note that if the content >> that the system has been subscribed to is not available in the new >> environment, the entitlement certificate is not going to have it >> either. >> > > Great. And how does a real-world scenario look like? I mean, does rhsm > automatically pull entitlement certs every X hours? Or do I need to take > some explicit action on the client? > > I would imagine a 'subscription-manager refresh' would do it... that said, I tried out the above with an install of the latest from git. Some notes: * The webUI worked fine, the system shows up in the next environment I moved it to * Tried a 'subscription-manager refresh' and took a look at the redhat.repos file and it still pointed at /dev/ but I had moved the system to test * tried 'yum repolist', same thing did I miss something? Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From omaciel at redhat.com Wed Aug 15 00:56:09 2012 From: omaciel at redhat.com (Og Maciel) Date: Tue, 14 Aug 2012 20:56:09 -0400 (EDT) Subject: [katello-devel] moving of systems between environments In-Reply-To: <502AEEDB.3070709@redhat.com> Message-ID: <970407779.5582514.1344992169403.JavaMail.root@redhat.com> > I would imagine a 'subscription-manager refresh' would do it... that > said, I tried out the above with an install of the latest from git. > Some notes: > > * The webUI worked fine, the system shows up in the next environment > I > moved it to Same here > * Tried a 'subscription-manager refresh' and took a look at the > redhat.repos file and it still pointed at /dev/ but I had moved the > system to test > > * tried 'yum repolist', same thing Ditto. FWIW, here's what my client's (moved from Development to QA) rhsm.log shows: 2012-08-14 20:24:56,402 [INFO] @connection.py:350 - Using certificate authentication: key = /etc/pki/consumer/key.pem, cert = /etc/pki/consumer/cert.pem, ca = /etc/rhsm/ca/, insecure = False 2012-08-14 20:24:56,403 [DEBUG] @connection.py:188 - Loading CA PEM certificates from: /etc/rhsm/ca/ 2012-08-14 20:24:56,403 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/redhat-uep.pem' 2012-08-14 20:24:56,404 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-stage.pem' 2012-08-14 20:24:56,404 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-local.pem' 2012-08-14 20:24:56,405 [DEBUG] @connection.py:209 - Making request: GET /katello/api/ 2012-08-14 20:24:56,461 [DEBUG] @connection.py:218 - Response status: 200 2012-08-14 20:24:56,462 [DEBUG] @connection.py:379 - Server supports the following resources: 2012-08-14 20:24:56,462 [DEBUG] @connection.py:380 - {'templates': '/api/templates/', 'organizations': '/api/organizations/', 'tasks': '/api/tasks/', 'users': '/api/users/', 'roles': '/api/roles/', 'changesets': '/api/changesets/', 'providers': '/api/providers/', 'repositories': '/api/repositories/', 'environments': '/api/environments/', 'entitlements': '/api/entitlements/', 'systems': '/api/systems/', 'gpg_keys': '/api/gpg_keys/', 'activation_keys': '/api/activation_keys/', 'packages': '/api/packages/', 'consumers': '/api/consumers/'} 2012-08-14 20:24:56,463 [INFO] @connection.py:362 - Connection Established: host: qetello02.usersys.redhat.com, port: 443, handler: /katello/api 2012-08-14 20:24:56,653 [DEBUG] @cert_sorter.py:89 - Sorting product and entitlement cert status for: 2012-08-15 00:24:56.653666+00:00 2012-08-14 20:24:56,655 [DEBUG] @cert_sorter.py:176 - Installed product IDs: ['69'] 2012-08-14 20:24:56,671 [DEBUG] @cert_sorter.py:93 - valid entitled products: ['69'] 2012-08-14 20:24:56,671 [DEBUG] @cert_sorter.py:94 - expired entitled products: [] 2012-08-14 20:24:56,671 [DEBUG] @cert_sorter.py:95 - partially entitled products: [] 2012-08-14 20:24:56,671 [DEBUG] @cert_sorter.py:96 - unentitled products: [] 2012-08-14 20:24:56,672 [DEBUG] @cert_sorter.py:97 - future products: [] 2012-08-14 20:24:56,674 [DEBUG] @connection.py:188 - Loading CA PEM certificates from: /etc/rhsm/ca/ 2012-08-14 20:24:56,674 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/redhat-uep.pem' 2012-08-14 20:24:56,675 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-stage.pem' 2012-08-14 20:24:56,675 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-local.pem' 2012-08-14 20:24:56,676 [DEBUG] @connection.py:209 - Making request: GET /katello/api/consumers/8ac5fb6a-6258-41e6-9e4e-656a57da3934 2012-08-14 20:24:57,085 [DEBUG] @connection.py:218 - Response status: 200 2012-08-14 20:24:57,094 [INFO] @certlib.py:111 - Checking if system requires healing. 2012-08-14 20:24:57,095 [DEBUG] @cert_sorter.py:89 - Sorting product and entitlement cert status for: 2012-08-15 00:24:57.095333+00:00 2012-08-14 20:24:57,097 [DEBUG] @cert_sorter.py:176 - Installed product IDs: ['69'] 2012-08-14 20:24:57,108 [DEBUG] @cert_sorter.py:93 - valid entitled products: ['69'] 2012-08-14 20:24:57,108 [DEBUG] @cert_sorter.py:94 - expired entitled products: [] 2012-08-14 20:24:57,108 [DEBUG] @cert_sorter.py:95 - partially entitled products: [] 2012-08-14 20:24:57,108 [DEBUG] @cert_sorter.py:96 - unentitled products: [] 2012-08-14 20:24:57,108 [DEBUG] @cert_sorter.py:97 - future products: [] 2012-08-14 20:24:57,109 [INFO] @certlib.py:130 - Entitlements are valid for today: 2012-08-15 00:24:57.095333+00:00 2012-08-14 20:24:57,109 [DEBUG] @cert_sorter.py:89 - Sorting product and entitlement cert status for: 2012-08-16 00:24:57.095333+00:00 2012-08-14 20:24:57,111 [DEBUG] @cert_sorter.py:176 - Installed product IDs: ['69'] 2012-08-14 20:24:57,120 [DEBUG] @cert_sorter.py:93 - valid entitled products: ['69'] 2012-08-14 20:24:57,120 [DEBUG] @cert_sorter.py:94 - expired entitled products: [] 2012-08-14 20:24:57,121 [DEBUG] @cert_sorter.py:95 - partially entitled products: [] 2012-08-14 20:24:57,121 [DEBUG] @cert_sorter.py:96 - unentitled products: [] 2012-08-14 20:24:57,121 [DEBUG] @cert_sorter.py:97 - future products: [] 2012-08-14 20:24:57,122 [INFO] @certlib.py:140 - Entitlements are valid for tomorrow: 2012-08-16 00:24:57.095333+00:00 2012-08-14 20:24:57,122 [INFO] @certlib.py:147 - Auto-heal check complete. 2012-08-14 20:24:57,122 [DEBUG] @cert_sorter.py:89 - Sorting product and entitlement cert status for: 2012-08-15 00:24:57.122648+00:00 2012-08-14 20:24:57,124 [DEBUG] @cert_sorter.py:176 - Installed product IDs: ['69'] 2012-08-14 20:24:57,134 [DEBUG] @cert_sorter.py:93 - valid entitled products: ['69'] 2012-08-14 20:24:57,134 [DEBUG] @cert_sorter.py:94 - expired entitled products: [] 2012-08-14 20:24:57,134 [DEBUG] @cert_sorter.py:95 - partially entitled products: [] 2012-08-14 20:24:57,135 [DEBUG] @cert_sorter.py:96 - unentitled products: [] 2012-08-14 20:24:57,135 [DEBUG] @cert_sorter.py:97 - future products: [] 2012-08-14 20:24:57,151 [INFO] @certlib.py:151 - Current installed product status: 2012-08-14 20:24:57,151 [INFO] @certlib.py:154 - ProductName: Red Hat Enterprise Linux Server Status: 6.2 2012-08-14 20:24:57,155 [DEBUG] @connection.py:188 - Loading CA PEM certificates from: /etc/rhsm/ca/ 2012-08-14 20:24:57,156 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/redhat-uep.pem' 2012-08-14 20:24:57,156 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-stage.pem' 2012-08-14 20:24:57,157 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-local.pem' 2012-08-14 20:24:57,157 [DEBUG] @connection.py:209 - Making request: GET /katello/api/consumers/8ac5fb6a-6258-41e6-9e4e-656a57da3934/certificates/serials 2012-08-14 20:24:57,288 [DEBUG] @connection.py:218 - Response status: 200 2012-08-14 20:24:57,292 [INFO] @certlib.py:201 - certs updated: Total updates: 0 Found (local) serial# [1305231365247380612L] Expected (UEP) serial# [1305231365247380612] Added (new) Deleted (rogue): Expired (not deleted): Expired (deleted): -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From lzap at redhat.com Wed Aug 15 04:13:11 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 15 Aug 2012 06:13:11 +0200 Subject: [katello-devel] Experience contributing a new feature as a user In-Reply-To: <2036058174.5152198.1344958072417.JavaMail.root@redhat.com> References: <598284290.5131413.1344957016716.JavaMail.root@redhat.com> <2036058174.5152198.1344958072417.JavaMail.root@redhat.com> Message-ID: <20120815041311.GA2818@lzapx.brq.redhat.com> On Tue, Aug 14, 2012 at 11:27:52AM -0400, Og Maciel wrote: > My point for this email is not to blame anyone but to ask the following question: how can we make it easier for people to contribute to katello without having to jump through endless hoops??? You either need all developer dependencies to be delivered as precompiled RPMs, or you need to undergo this compilation process every time you install those gems. This is how rubygems work - they are basically source packages which is fine for pure-ruby packages, but for gems with extensions its more tough. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Aug 15 04:26:21 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 15 Aug 2012 06:26:21 +0200 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A79BE.8070403@redhat.com> References: <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> <502A4D8E.8030602@redhat.com> <502A51FE.7010008@redhat.com> <502A596E.5060504@redhat.com> <502A5D11.3060809@redhat.com> <20120814143236.GJ11232@redhat.com> <502A67E9.7080704@redhat.com> <502A71D8.4010609@redhat.com> <502A79BE.8070403@redhat.com> Message-ID: <20120815042621.GB2818@lzapx.brq.redhat.com> On Tue, Aug 14, 2012 at 05:15:58PM +0100, Dmitri Dolguikh wrote: > In this light: some piece of code on the client side uses API to > enumerate available environments. Some time passes. Some admin > deletes one of the environments. Some time passes. Some admin > creates an environment with the same label. The original client > re-syncs environments. Instead of detecting a deleted environment, > it sees that the environment is there and alive. The resulting > issues are going to be a living hell to debug. I don't see any issues in this scenario. Created, deleted, created again, re-synced. Everything is fine, clients are not able to connect to the original environment via yum (it has different certificate). CLI also works, you can re-sync without any problems. What is the issue again? Having labels does not mean we are resigning from primary keys. Every resource should have it's own primary key as we have it today. Anybody will be able to notice the change. Theoretically numeric id could be re-assigned by sql server, but that is another story... -- Later, Lukas "lzap" Zapletal #katello #systemengine From inecas at redhat.com Wed Aug 15 06:39:18 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 15 Aug 2012 08:39:18 +0200 Subject: [katello-devel] Experience contributing a new feature as a user In-Reply-To: <20120815041311.GA2818@lzapx.brq.redhat.com> References: <598284290.5131413.1344957016716.JavaMail.root@redhat.com> <2036058174.5152198.1344958072417.JavaMail.root@redhat.com> <20120815041311.GA2818@lzapx.brq.redhat.com> Message-ID: <502B4416.4060306@redhat.com> On 08/15/2012 06:13 AM, Lukas Zapletal wrote: > On Tue, Aug 14, 2012 at 11:27:52AM -0400, Og Maciel wrote: >> My point for this email is not to blame anyone but to ask the following question: how can we make it easier for people to contribute to katello without having to jump through endless hoops??? > You either need all developer dependencies to be delivered as > precompiled RPMs, or you need to undergo this compilation process > every time you install those gems. This is how rubygems work - they are > basically source packages which is fine for pure-ruby packages, but for > gems with extensions its more tough. > The problem with apipie not being installed right with bundle install is our gem repo preparation script is failing for some time (hopefully will be fixed soon, nothing else is holding us back to have it there). If you're lucky enough, you use some yum-backed distro and you can enjoy all the advantages it has: yum install rubygem-redcarpet (available in Fedora and EPEL), yum install rubygem-apipie-rails (in our nightly repo [1] since tonight). bundle install: problem solved :) One improvement I could see is to distribute all the development packages (including test frameworks etc) as RPMs and provide katello-devel package, that would install all the dependencies so that the developer is ready to go with one command. That would also allow us to get rid of our rubygem repo and make the "source :rubygems" optional. All we can do for other rubygem users is to document it somewhere. Oh wait, we did [2] :). Ruby developers are quite used to have the ruby-devel (and other development packages) installed on the machine. [1] - http://koji-katello.lab.eng.brq.redhat.com/releases/yum/nightly/RHEL/6Server/x86_64/ [2] - https://fedorahosted.org/katello/wiki/AdvancedInstallation#SetUpDevelopmentusingGit -- Ivan From inecas at redhat.com Wed Aug 15 06:40:19 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 15 Aug 2012 08:40:19 +0200 Subject: [katello-devel] Experience contributing a new feature as a user In-Reply-To: <502B4416.4060306@redhat.com> References: <598284290.5131413.1344957016716.JavaMail.root@redhat.com> <2036058174.5152198.1344958072417.JavaMail.root@redhat.com> <20120815041311.GA2818@lzapx.brq.redhat.com> <502B4416.4060306@redhat.com> Message-ID: <502B4453.708@redhat.com> On 08/15/2012 08:39 AM, Ivan Ne?as wrote: > On 08/15/2012 06:13 AM, Lukas Zapletal wrote: >> On Tue, Aug 14, 2012 at 11:27:52AM -0400, Og Maciel wrote: >>> My point for this email is not to blame anyone but to ask the >>> following question: how can we make it easier for people to >>> contribute to katello without having to jump through endless hoops??? >> You either need all developer dependencies to be delivered as >> precompiled RPMs, or you need to undergo this compilation process >> every time you install those gems. This is how rubygems work - they are >> basically source packages which is fine for pure-ruby packages, but for >> gems with extensions its more tough. >> > The problem with apipie not being installed right with bundle install > is our gem repo preparation script is failing for some time (hopefully > will be fixed soon, nothing else is holding us back to have it there). > > If you're lucky enough, you use some yum-backed distro and you can > enjoy all the advantages it has: yum install rubygem-redcarpet > (available in Fedora and EPEL), yum install rubygem-apipie-rails (in > our nightly repo [1] since tonight). bundle install: problem solved :) > > One improvement I could see is to distribute all the development > packages (including test frameworks etc) as RPMs and provide > katello-devel package, that would install all the dependencies so that > the developer is ready to go with one command. That would also allow > us to get rid of our rubygem repo and make the "source :rubygems" > optional. > > All we can do for other rubygem users is to document it somewhere. Oh > wait, we did [2] :). Ruby developers are quite used to have the > ruby-devel (and other development packages) installed on the machine. > > [1] - > http://koji-katello.lab.eng.brq.redhat.com/releases/yum/nightly/RHEL/6Server/x86_64/ and the external link to ^^^ is http://fedorapeople.org/groups/katello/releases/yum/nightly/RHEL/6Server/x86_64/ > [2] - > https://fedorahosted.org/katello/wiki/AdvancedInstallation#SetUpDevelopmentusingGit > > -- Ivan From msuchy at redhat.com Wed Aug 15 08:50:00 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 15 Aug 2012 10:50:00 +0200 Subject: [katello-devel] Experience contributing a new feature as a user In-Reply-To: <2036058174.5152198.1344958072417.JavaMail.root@redhat.com> References: <2036058174.5152198.1344958072417.JavaMail.root@redhat.com> Message-ID: <502B62B8.2000600@redhat.com> On 08/14/2012 05:27 PM, Og Maciel wrote: > My point for this email is not to blame anyone but to ask the following question: how can we make it easier for people to contribute to katello without having to jump through endless hoops??? This is exactly the reason, why you should use native packaging system - in our case rpm. Where all this requirements (including gcc) are addressed. I know that we do not have developers dependencies packaged yet (we just finished with run time). But you can help us. You can package it and submit to Fedora for review. Or you can build it in our Koji and put in comps file in katello-server-devel group. While the Fedora Review is long term goal, building in Koji is fast. And you should be able at the end to do: yum groupinstall 'Katello Server Development' and have all developer dependencies installed. -- Miroslav Suchy Red Hat Systems Management Engineering From msuchy at redhat.com Wed Aug 15 11:27:30 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Wed, 15 Aug 2012 13:27:30 +0200 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <502A478A.8030100@redhat.com> References: <5029131A.7030405@redhat.com> <5029149C.4030509@redhat.com> <5029155F.5040100@redhat.com> <502915F5.8060403@redhat.com> <50291693.9080001@redhat.com> <50297C0C.2080501@redhat.com> <502A33B6.5090606@redhat.com> <502A478A.8030100@redhat.com> Message-ID: <502B87A2.3060207@redhat.com> On 08/14/2012 02:41 PM, Justin Sherrill wrote: > > I believe (and someone please correct me if I'm wrong) that the only > thing that can contain non-ascii characters is the name Even hostname - and therefore url can contain UTF-8 character. I have one such machine: # host ?ufu??k.lab.eng.brq.redhat.com ?ufu??k.lab.eng.brq.redhat.com has address XXXX-masked ?ufu??k.lab.eng.brq.redhat.com has IPv6 address XXXXXX-masked For more info see: http://en.wikipedia.org/wiki/Internationalized_domain_name Such names are encoded in Punycode: http://en.wikipedia.org/wiki/Punycode And ?ufu??k.lab.eng.brq.redhat.com should be translated by application to: xn--ufuk-xpa16d5h.lab.eng.brq.redhat.com Ascii only names are are identical in Punycode. You can test it here: http://www.charset.org/punycode.php Punycode is standard and widely used. Libraries for every language available. Why not use Punycode for repository names as well? BTW, do we support IDN domains in Katello? I'm afraid that the answer is negative. Can someone test it? -- Miroslav Suchy Red Hat Systems Management Engineering From ohadlevy at redhat.com Wed Aug 15 12:10:21 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 15 Aug 2012 15:10:21 +0300 Subject: [katello-devel] Fwd: Re: Design of Forms In-Reply-To: <502A7CB1.9010907@redhat.com> References: <20120814162608.GF9380@redhat.com> <502A7CB1.9010907@redhat.com> Message-ID: <502B91AD.6060101@redhat.com> On 08/14/2012 07:28 PM, Bryan Kearney wrote: > I like it..although I fear we do not have enough space in tupane. I like it, but not so much the fact that when you hover over a field with error imho the animation should either pop up only when focused or not be animated at all. Ohad > > -- bk > > > > -------- Original Message -------- > Subject: Re: Design of Forms > Date: Tue, 14 Aug 2012 12:26:09 -0400 > From: Hugh Brock > Reply-To: Hugh O. Brock > To: Jarom?r Coufal > CC: aeolus-devel > > On Tue, Aug 14, 2012 at 05:32:19PM +0200, Jarom?r Coufal wrote: >> One more "hello" :) >> >> another thing I have designed is a layout and behavior of forms - >> you can check it here: >> >> http://codepen.io/coufalj/pen/qiEkH >> >> Still working on responsive, but it is not that important in this >> stage. What do you think about this concept of forms used across our >> whole application? >> >> -- Jarda > > Love it Jarda. I'll leave it to those with better eyes than mine to > critique, but I think the consistency of the controls is great. > > --Hugh > From ohadlevy at redhat.com Wed Aug 15 12:11:49 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 15 Aug 2012 15:11:49 +0300 Subject: [katello-devel] Licensing? In-Reply-To: <502A59B2.8050500@redhat.com> References: <502A4341.2000107@redhat.com> <502A57EB.1040605@redhat.com> <502A58FA.7010001@redhat.com> <502A59B2.8050500@redhat.com> Message-ID: <502B9205.8010205@redhat.com> On 08/14/2012 04:59 PM, Miroslav Such? wrote: > On 08/14/2012 03:56 PM, Bryan Kearney wrote: >> I guess a third option is to break out common code to gems or other >> rails engines type reusable concepts, and then license those MIT. > > +1 And we done that with e.g. rubygem-forman-api. +1 we actually already did that exactly with Aeolus with the ruby ovirt binding. From inecas at redhat.com Wed Aug 15 12:55:15 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 15 Aug 2012 14:55:15 +0200 Subject: [katello-devel] Experience contributing a new feature as a user In-Reply-To: <502B4453.708@redhat.com> References: <598284290.5131413.1344957016716.JavaMail.root@redhat.com> <2036058174.5152198.1344958072417.JavaMail.root@redhat.com> <20120815041311.GA2818@lzapx.brq.redhat.com> <502B4416.4060306@redhat.com> <502B4453.708@redhat.com> Message-ID: <502B9C33.2000602@redhat.com> On 08/15/2012 08:40 AM, Ivan Ne?as wrote: > On 08/15/2012 08:39 AM, Ivan Ne?as wrote: >> On 08/15/2012 06:13 AM, Lukas Zapletal wrote: >>> On Tue, Aug 14, 2012 at 11:27:52AM -0400, Og Maciel wrote: >>>> My point for this email is not to blame anyone but to ask the >>>> following question: how can we make it easier for people to >>>> contribute to katello without having to jump through endless hoops??? >>> You either need all developer dependencies to be delivered as >>> precompiled RPMs, or you need to undergo this compilation process >>> every time you install those gems. This is how rubygems work - they are >>> basically source packages which is fine for pure-ruby packages, but for >>> gems with extensions its more tough. >>> >> The problem with apipie not being installed right with bundle install >> is our gem repo preparation script is failing for some time >> (hopefully will be fixed soon, nothing else is holding us back to >> have it there). >> >> If you're lucky enough, you use some yum-backed distro and you can >> enjoy all the advantages it has: yum install rubygem-redcarpet >> (available in Fedora and EPEL), yum install rubygem-apipie-rails (in >> our nightly repo [1] since tonight). bundle install: problem solved :) One more thing I can do is to publish a script that I use to turn a machine configured with katello-configure into a development machine. I use puppet manifests for that, but it will be more effective to publish it as simple bash script. The pull-request should appear soon. -- Ivan >> >> One improvement I could see is to distribute all the development >> packages (including test frameworks etc) as RPMs and provide >> katello-devel package, that would install all the dependencies so >> that the developer is ready to go with one command. That would also >> allow us to get rid of our rubygem repo and make the "source >> :rubygems" optional. >> >> All we can do for other rubygem users is to document it somewhere. Oh >> wait, we did [2] :). Ruby developers are quite used to have the >> ruby-devel (and other development packages) installed on the machine. >> >> [1] - >> http://koji-katello.lab.eng.brq.redhat.com/releases/yum/nightly/RHEL/6Server/x86_64/ > and the external link to ^^^ is > http://fedorapeople.org/groups/katello/releases/yum/nightly/RHEL/6Server/x86_64/ >> [2] - >> https://fedorahosted.org/katello/wiki/AdvancedInstallation#SetUpDevelopmentusingGit >> >> > > -- Ivan From thomasmckay at redhat.com Wed Aug 15 13:26:37 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 15 Aug 2012 09:26:37 -0400 (EDT) Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <765630095.9855132.1345037080923.JavaMail.root@redhat.com> Message-ID: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> One of the design tasks for this sprint is to come up with a way to associate key-value pairs to systems and subscriptions. This would be similar to the system facts that exist. It would be nice to allow these pairs to exist on other objects now or in the future as well (eg. activation keys). Question: What is the best way to model this in the katello db? Joins or something? From ohadlevy at redhat.com Wed Aug 15 13:32:24 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 15 Aug 2012 16:32:24 +0300 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> Message-ID: <502BA4E8.3030801@redhat.com> On 08/15/2012 04:26 PM, Tom McKay wrote: > > One of the design tasks for this sprint is to come up with a way to associate key-value pairs to systems and subscriptions. This would be similar to the system facts that exist. It would be nice to allow these pairs to exist on other objects now or in the future as well (eg. activation keys). > > Question: What is the best way to model this in the katello db? Joins or something? in foreman, we have 3 tables hosts fact name fact value and fact value is basically the join fact_value id, host_id, fact_name_id, value you could easily turn this into a polymorphic relationship (so instead of host_id you have obj_id and obj_type) however, I think that fact_name table might have created a performance degradation and if I'll do it again, i might just put the key next to the value. Ohad > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From inecas at redhat.com Wed Aug 15 13:34:00 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 15 Aug 2012 15:34:00 +0200 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> Message-ID: <502BA548.1030300@redhat.com> On 08/15/2012 03:26 PM, Tom McKay wrote: > One of the design tasks for this sprint is to come up with a way to associate key-value pairs to systems and subscriptions. This would be similar to the system facts that exist. It would be nice to allow these pairs to exist on other objects now or in the future as well (eg. activation keys). > > Question: What is the best way to model this in the katello db? Joins or something? We have already this in User model: see serialize :preferences this serializes this parameters into blob transparently. -- Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From omaciel at redhat.com Wed Aug 15 13:37:37 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 15 Aug 2012 09:37:37 -0400 (EDT) Subject: [katello-devel] Experience contributing a new feature as a user In-Reply-To: <502B4416.4060306@redhat.com> Message-ID: <162222688.5838124.1345037857934.JavaMail.root@redhat.com> Hey Ivan, thanks for the reply. I am actually running Fedora (and RHEL 6.3) and have tried a mix of yum and gem install commands to get to a point where I can try to run a simple rspec test... Though having a script that does what you mentioned, which is, turn a katello system that was installed and configured into a devel environment would help me right now, imvho it does not solve what may be the bigger issue here: why do I need to install the application in order to run a test? In the rails world all you need is a test db as you don't actually want to touch the real db. Also, why can't we just use bundle install like most rails apps? Sure, you don't have to get all the other moving parts with this command, such as pulp, candlepin, etc, but at least get enough dependencies so that one can run tests against it? As a contributing user I'd like to checkout the source code, run bundle install, and be able to write and run rpsec tests :) -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From msuchy at redhat.com Wed Aug 15 13:51:40 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 15 Aug 2012 15:51:40 +0200 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <502BA4E8.3030801@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> <502BA4E8.3030801@redhat.com> Message-ID: <502BA96C.5020104@redhat.com> On 08/15/2012 03:32 PM, Ohad Levy wrote: > in foreman, we have 3 tables > > hosts > fact name > fact value > > and fact value is basically the join > > fact_value > id, host_id, fact_name_id, value > > you could easily turn this into a polymorphic relationship (so instead > of host_id you have obj_id and obj_type) > > however, I think that fact_name table might have created a performance > degradation and if I'll do it again, i might just put the key next to > the value. +1 -- Miroslav Suchy Red Hat Systems Management Engineering From ohadlevy at redhat.com Wed Aug 15 14:03:07 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 15 Aug 2012 17:03:07 +0300 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <502BA548.1030300@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> <502BA548.1030300@redhat.com> Message-ID: <502BAC1B.4070600@redhat.com> On 08/15/2012 04:34 PM, Ivan Ne?as wrote: > On 08/15/2012 03:26 PM, Tom McKay wrote: >> One of the design tasks for this sprint is to come up with a way to >> associate key-value pairs to systems and subscriptions. This would be >> similar to the system facts that exist. It would be nice to allow >> these pairs to exist on other objects now or in the future as well >> (eg. activation keys). >> >> Question: What is the best way to model this in the katello db? Joins >> or something? > We have already this in User model: see > > serialize :preferences > > this serializes this parameters into blob transparently. > when you serialize you lose a few things 1. the ability to join 2. the ability to filter in sql (you have to load it all, decode it and do in memory search).. Ohad > -- Ivan >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > From ehelms at redhat.com Wed Aug 15 14:11:04 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 15 Aug 2012 10:11:04 -0400 Subject: [katello-devel] Summary: Breaking up Codebase Message-ID: <502BADF8.4050407@redhat.com> This is a summary of the proposal "Breaking up Codebase" originally started here [1] and continued here [2]. The following is broken up such that Section I contains the original proposal, Section II contains a general summary and thoughts post-discussion and lastly Section III provides a more in-depth summary of the conversation thus far. Section I: Original Proposal Prior to using Github for source control management, the project had one logical repository available that made sense for keeping the various components of Katello contained within. As the project has grown, and as our community efforts increase I propose we break out code base elements from our mainline repository for the following reasons: 1) Reduces the overall size of the project repository. 2) Provides smaller, logical components that users and developers can work from and on. This makes it easier for the community to contribute as they can work on components that are important to them, that they are more comfortable working on and are smaller (a.k.a less imposing due to size). 3) Decreases "tag-mania" on the mainline repository and lets the tags and the packages they are associated with live on their own. Provides direct connection between package and repository (e.g. katello-cli.rpm is derived from katello-cli git repository) 4) Some components just have no logical reason to be contained within the same repository. (e.g. I don't need the CLI code to run and work on Katello) 5) The Github Organization concept with multiple repositories makes it easy to manage multiple applications and pull requests associated with each. Components I currently see that could be stand-alone repositories: cli/ agent/ certs-tools/ puppet/ repos/ src/ (a.k.a Katello) Section II: General Summary There is an even mix of +1 and apprehensive -1's around this topic. The general feel of the points against is how it affects the ability to build the Katello RPMs and keep proper versions in check. The general feel for points for is that it would make components more logical, mimic the seeming successes other projects have seen with broken out components with regards to community, and make viewing of component progress easier with regards to development. Thoughts: * Broken out packages would allow each to have a more cohesive development focused around the package, pull requests, and tags are specific to the repository/package contained within. And would reduce the number of PRs and potentially the time to accept sitting in our central Katello repository and let those focused on certain areas focus on the areas they want to focus on. * Feels natural that I should be able to checkout or install the CLI without having to setup a Katello server myself. * While Git repository currently is not large in bytes, it is large in layout which can be overwhelming or confusing and will only grow from here on out. Questions: * Pardon any ignorance on how building is done here, do all packages, rel-eng, tags and spec files get managed centrally in the current layout? Or does each require its own editing, maintenance and tagging? * How would broken out components affect ability to build cohesive set of packages? * Does working on Katello really required knowledge about katello-configure? I have never worked on katello-configure but manage to work on Katello everyday. The same was true with regards to the CLI. * Does this break-up really make contribution easier? * Would this break-up of the codebase feel weird if it had been done from the start or are we just accepting the status quo? Other Thoughts: * Breaking out components could allow for language-specific packaging install for those who prefer it. For example, allowing CLI to stand-alone and be installed via python-disutils or being able to install Katello via a gem. * We should consider the idea of not only breaking out logical package based components but potentially other areas of code (e.g. api, ui, backend layer, APIs down to backend services) Section III: Summary of points for and against. Points For: * Previously listed ones above * Since we use Github, easier to offer different repository permissions, easier to browse and see progress of each component * This is how Foreman community works and it seems it made it easier for people to contribute * OpenStack takes similar approach to proposal and works well for them * Layout of source tree currently, and the way each is packaged lends themselves to individual package per repo Points Against: * Git repository is currently not large * Working on Katello requires knowledge of katello-configure and working on katello-configure requires knowledge of Katello * One package per git repository means managing more /rel-eng/ directories and keeping them in sync * When we deliver Katello, we deliver all components * Does breaking it up really make it easier to contribute? * If we eventually build on EC2, more repositories could mean getting charged more for increased internet traffic * Feeling that it would be harder to ensure correct version in all repositories General Notes: * Delay until current build setup is stable * Break out each component one-by-one instead of "big bang" approach * Could we go a step further and think about other re-usable chunks that can be broken out into gems, helpers, generators, engines? * Adding a README to describe project layout - Eric [1] https://www.redhat.com/archives/katello-devel/2012-August/msg00071.html [2] https://github.com/Katello/katello/issues/450 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitri at redhat.com Wed Aug 15 14:11:49 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 15 Aug 2012 15:11:49 +0100 Subject: [katello-devel] Renaming of environments: summary In-Reply-To: <20120815042621.GB2818@lzapx.brq.redhat.com> References: <502A4C0D.6060609@redhat.com> <502A4CC1.4070107@redhat.com> <502A4D8E.8030602@redhat.com> <502A51FE.7010008@redhat.com> <502A596E.5060504@redhat.com> <502A5D11.3060809@redhat.com> <20120814143236.GJ11232@redhat.com> <502A67E9.7080704@redhat.com> <502A71D8.4010609@redhat.com> <502A79BE.8070403@redhat.com> <20120815042621.GB2818@lzapx.brq.redhat.com> Message-ID: <502BAE25.8030101@redhat.com> The discussion here covers Katello API. A big point that I keep failing to communicate is that we, Katello developers, can't know all possible clients of Katello REST API. Yes, Katello cli is going to be fine, since it doesn't (at least presently) cache/persist locally any information it receives. Yes, yum is going to be fine too. The hypothetical customer/3rd party system in the example I made is utterly fubared however. When accessing data at the url it persisted, it receives completely different data. We just violated someone else's data integrity. Why doesn't this bother anyone? Imagine some piece of code violated Katello internal data integrity the same way - what would your reaction be then? -d On 15/08/12 05:26 AM, Lukas Zapletal wrote: > On Tue, Aug 14, 2012 at 05:15:58PM +0100, Dmitri Dolguikh wrote: >> In this light: some piece of code on the client side uses API to >> enumerate available environments. Some time passes. Some admin >> deletes one of the environments. Some time passes. Some admin >> creates an environment with the same label. The original client >> re-syncs environments. Instead of detecting a deleted environment, >> it sees that the environment is there and alive. The resulting >> issues are going to be a living hell to debug. > I don't see any issues in this scenario. Created, deleted, created > again, re-synced. Everything is fine, clients are not able to connect to > the original environment via yum (it has different certificate). CLI > also works, you can re-sync without any problems. What is the issue > again? > > Having labels does not mean we are resigning from primary keys. Every > resource should have it's own primary key as we have it today. Anybody > will be able to notice the change. Theoretically numeric id could be > re-assigned by sql server, but that is another story... > From jsherril at redhat.com Wed Aug 15 14:19:13 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 15 Aug 2012 10:19:13 -0400 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <502BAC1B.4070600@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> <502BA548.1030300@redhat.com> <502BAC1B.4070600@redhat.com> Message-ID: <502BAFE1.2060704@redhat.com> On 08/15/2012 10:03 AM, Ohad Levy wrote: > On 08/15/2012 04:34 PM, Ivan Ne?as wrote: >> On 08/15/2012 03:26 PM, Tom McKay wrote: >>> One of the design tasks for this sprint is to come up with a way to >>> associate key-value pairs to systems and subscriptions. This would be >>> similar to the system facts that exist. It would be nice to allow >>> these pairs to exist on other objects now or in the future as well >>> (eg. activation keys). >>> >>> Question: What is the best way to model this in the katello db? Joins >>> or something? >> We have already this in User model: see >> >> serialize :preferences >> >> this serializes this parameters into blob transparently. >> > when you serialize you lose a few things > > 1. the ability to join > 2. the ability to filter in sql (you have to load it all, decode it > and do in memory search).. > > > Ohad With katello's implementation of elastic search it could alleviate some of those issues depending on the implementation. Although I'm not entirely sure what you mean by 'the ability to join'. -Justin >> -- 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 From dmitri at redhat.com Wed Aug 15 14:26:45 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 15 Aug 2012 15:26:45 +0100 Subject: [katello-devel] moving of systems between environments In-Reply-To: <970407779.5582514.1344992169403.JavaMail.root@redhat.com> References: <970407779.5582514.1344992169403.JavaMail.root@redhat.com> Message-ID: <502BB1A5.8080308@redhat.com> It looks like rhsm detected the change in certificate serial number. Could you check if entitlement certificates are being updated and content urls in those certificates point to the correct environment? -d On 15/08/12 01:56 AM, Og Maciel wrote: >> I would imagine a 'subscription-manager refresh' would do it... that >> said, I tried out the above with an install of the latest from git. >> Some notes: >> >> * The webUI worked fine, the system shows up in the next environment >> I >> moved it to > Same here > >> * Tried a 'subscription-manager refresh' and took a look at the >> redhat.repos file and it still pointed at /dev/ but I had moved the >> system to test >> >> * tried 'yum repolist', same thing > Ditto. > > FWIW, here's what my client's (moved from Development to QA) rhsm.log shows: > > 2012-08-14 20:24:56,402 [INFO] @connection.py:350 - Using certificate authentication: key = /etc/pki/consumer/key.pem, cert = /etc/pki/consumer/cert.pem, ca = /etc/rhsm/ca/, insecure = False > 2012-08-14 20:24:56,403 [DEBUG] @connection.py:188 - Loading CA PEM certificates from: /etc/rhsm/ca/ > 2012-08-14 20:24:56,403 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/redhat-uep.pem' > 2012-08-14 20:24:56,404 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-stage.pem' > 2012-08-14 20:24:56,404 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-local.pem' > 2012-08-14 20:24:56,405 [DEBUG] @connection.py:209 - Making request: GET /katello/api/ > 2012-08-14 20:24:56,461 [DEBUG] @connection.py:218 - Response status: 200 > 2012-08-14 20:24:56,462 [DEBUG] @connection.py:379 - Server supports the following resources: > 2012-08-14 20:24:56,462 [DEBUG] @connection.py:380 - {'templates': '/api/templates/', 'organizations': '/api/organizations/', 'tasks': '/api/tasks/', 'users': '/api/users/', 'roles': '/api/roles/', 'changesets': '/api/changesets/', 'providers': '/api/providers/', 'repositories': '/api/repositories/', 'environments': '/api/environments/', 'entitlements': '/api/entitlements/', 'systems': '/api/systems/', 'gpg_keys': '/api/gpg_keys/', 'activation_keys': '/api/activation_keys/', 'packages': '/api/packages/', 'consumers': '/api/consumers/'} > 2012-08-14 20:24:56,463 [INFO] @connection.py:362 - Connection Established: host: qetello02.usersys.redhat.com, port: 443, handler: /katello/api > 2012-08-14 20:24:56,653 [DEBUG] @cert_sorter.py:89 - Sorting product and entitlement cert status for: 2012-08-15 00:24:56.653666+00:00 > 2012-08-14 20:24:56,655 [DEBUG] @cert_sorter.py:176 - Installed product IDs: ['69'] > 2012-08-14 20:24:56,671 [DEBUG] @cert_sorter.py:93 - valid entitled products: ['69'] > 2012-08-14 20:24:56,671 [DEBUG] @cert_sorter.py:94 - expired entitled products: [] > 2012-08-14 20:24:56,671 [DEBUG] @cert_sorter.py:95 - partially entitled products: [] > 2012-08-14 20:24:56,671 [DEBUG] @cert_sorter.py:96 - unentitled products: [] > 2012-08-14 20:24:56,672 [DEBUG] @cert_sorter.py:97 - future products: [] > 2012-08-14 20:24:56,674 [DEBUG] @connection.py:188 - Loading CA PEM certificates from: /etc/rhsm/ca/ > 2012-08-14 20:24:56,674 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/redhat-uep.pem' > 2012-08-14 20:24:56,675 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-stage.pem' > 2012-08-14 20:24:56,675 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-local.pem' > 2012-08-14 20:24:56,676 [DEBUG] @connection.py:209 - Making request: GET /katello/api/consumers/8ac5fb6a-6258-41e6-9e4e-656a57da3934 > 2012-08-14 20:24:57,085 [DEBUG] @connection.py:218 - Response status: 200 > 2012-08-14 20:24:57,094 [INFO] @certlib.py:111 - Checking if system requires healing. > 2012-08-14 20:24:57,095 [DEBUG] @cert_sorter.py:89 - Sorting product and entitlement cert status for: 2012-08-15 00:24:57.095333+00:00 > 2012-08-14 20:24:57,097 [DEBUG] @cert_sorter.py:176 - Installed product IDs: ['69'] > 2012-08-14 20:24:57,108 [DEBUG] @cert_sorter.py:93 - valid entitled products: ['69'] > 2012-08-14 20:24:57,108 [DEBUG] @cert_sorter.py:94 - expired entitled products: [] > 2012-08-14 20:24:57,108 [DEBUG] @cert_sorter.py:95 - partially entitled products: [] > 2012-08-14 20:24:57,108 [DEBUG] @cert_sorter.py:96 - unentitled products: [] > 2012-08-14 20:24:57,108 [DEBUG] @cert_sorter.py:97 - future products: [] > 2012-08-14 20:24:57,109 [INFO] @certlib.py:130 - Entitlements are valid for today: 2012-08-15 00:24:57.095333+00:00 > 2012-08-14 20:24:57,109 [DEBUG] @cert_sorter.py:89 - Sorting product and entitlement cert status for: 2012-08-16 00:24:57.095333+00:00 > 2012-08-14 20:24:57,111 [DEBUG] @cert_sorter.py:176 - Installed product IDs: ['69'] > 2012-08-14 20:24:57,120 [DEBUG] @cert_sorter.py:93 - valid entitled products: ['69'] > 2012-08-14 20:24:57,120 [DEBUG] @cert_sorter.py:94 - expired entitled products: [] > 2012-08-14 20:24:57,121 [DEBUG] @cert_sorter.py:95 - partially entitled products: [] > 2012-08-14 20:24:57,121 [DEBUG] @cert_sorter.py:96 - unentitled products: [] > 2012-08-14 20:24:57,121 [DEBUG] @cert_sorter.py:97 - future products: [] > 2012-08-14 20:24:57,122 [INFO] @certlib.py:140 - Entitlements are valid for tomorrow: 2012-08-16 00:24:57.095333+00:00 > 2012-08-14 20:24:57,122 [INFO] @certlib.py:147 - Auto-heal check complete. > 2012-08-14 20:24:57,122 [DEBUG] @cert_sorter.py:89 - Sorting product and entitlement cert status for: 2012-08-15 00:24:57.122648+00:00 > 2012-08-14 20:24:57,124 [DEBUG] @cert_sorter.py:176 - Installed product IDs: ['69'] > 2012-08-14 20:24:57,134 [DEBUG] @cert_sorter.py:93 - valid entitled products: ['69'] > 2012-08-14 20:24:57,134 [DEBUG] @cert_sorter.py:94 - expired entitled products: [] > 2012-08-14 20:24:57,134 [DEBUG] @cert_sorter.py:95 - partially entitled products: [] > 2012-08-14 20:24:57,135 [DEBUG] @cert_sorter.py:96 - unentitled products: [] > 2012-08-14 20:24:57,135 [DEBUG] @cert_sorter.py:97 - future products: [] > 2012-08-14 20:24:57,151 [INFO] @certlib.py:151 - Current installed product status: > 2012-08-14 20:24:57,151 [INFO] @certlib.py:154 - > ProductName: Red Hat Enterprise Linux Server > Status: 6.2 > > 2012-08-14 20:24:57,155 [DEBUG] @connection.py:188 - Loading CA PEM certificates from: /etc/rhsm/ca/ > 2012-08-14 20:24:57,156 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/redhat-uep.pem' > 2012-08-14 20:24:57,156 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-stage.pem' > 2012-08-14 20:24:57,157 [DEBUG] @connection.py:171 - Loading CA certificate: '/etc/rhsm/ca/candlepin-local.pem' > 2012-08-14 20:24:57,157 [DEBUG] @connection.py:209 - Making request: GET /katello/api/consumers/8ac5fb6a-6258-41e6-9e4e-656a57da3934/certificates/serials > 2012-08-14 20:24:57,288 [DEBUG] @connection.py:218 - Response status: 200 > 2012-08-14 20:24:57,292 [INFO] @certlib.py:201 - certs updated: > Total updates: 0 > Found (local) serial# [1305231365247380612L] > Expected (UEP) serial# [1305231365247380612] > Added (new) > > Deleted (rogue): > > Expired (not deleted): > > Expired (deleted): > > From ohadlevy at redhat.com Wed Aug 15 14:28:58 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 15 Aug 2012 17:28:58 +0300 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <502BAFE1.2060704@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> <502BA548.1030300@redhat.com> <502BAC1B.4070600@redhat.com> <502BAFE1.2060704@redhat.com> Message-ID: <502BB22A.2010103@redhat.com> On 08/15/2012 05:19 PM, Justin Sherrill wrote: > On 08/15/2012 10:03 AM, Ohad Levy wrote: >> On 08/15/2012 04:34 PM, Ivan Ne?as wrote: >>> On 08/15/2012 03:26 PM, Tom McKay wrote: >>>> One of the design tasks for this sprint is to come up with a way to >>>> associate key-value pairs to systems and subscriptions. This would be >>>> similar to the system facts that exist. It would be nice to allow >>>> these pairs to exist on other objects now or in the future as well >>>> (eg. activation keys). >>>> >>>> Question: What is the best way to model this in the katello db? Joins >>>> or something? >>> We have already this in User model: see >>> >>> serialize :preferences >>> >>> this serializes this parameters into blob transparently. >>> >> when you serialize you lose a few things >> >> 1. the ability to join >> 2. the ability to filter in sql (you have to load it all, decode it >> and do in memory search).. >> >> >> Ohad > With katello's implementation of elastic search it could alleviate some > of those issues depending on the implementation. Although I'm not > entirely sure what you mean by 'the ability to join'. yeah, i mean the ability to sort.. Ohad > > -Justin > >>> -- 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 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From dmitri at redhat.com Wed Aug 15 14:38:04 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 15 Aug 2012 15:38:04 +0100 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> Message-ID: <502BB44C.605@redhat.com> On 15/08/12 02:26 PM, Tom McKay wrote: > One of the design tasks for this sprint is to come up with a way to associate key-value pairs to systems and subscriptions. This would be similar to the system facts that exist. It would be nice to allow these pairs to exist on other objects now or in the future as well (eg. activation keys). > > Question: What is the best way to model this in the katello db? Joins or something? > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel How many key-value pairs are we looking at: per system/per subscription/total per katello installation? Should they be mutable? The question was raised about searching - do we need to support it? If the total number of key-value pairs is low (doesn't cross a million rows threshold) it should work ok, although searches will start to slow down when approaching the threshold above. If the total number of pairs is large, might be better to store the whole set as a text blob, and rely on elastic search for lookups. -d From inecas at redhat.com Wed Aug 15 14:39:03 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 15 Aug 2012 16:39:03 +0200 Subject: [katello-devel] Experience contributing a new feature as a user In-Reply-To: <162222688.5838124.1345037857934.JavaMail.root@redhat.com> References: <162222688.5838124.1345037857934.JavaMail.root@redhat.com> Message-ID: <502BB487.2070201@redhat.com> On 08/15/2012 03:37 PM, Og Maciel wrote: > Hey Ivan, thanks for the reply. I am actually running Fedora (and RHEL 6.3) and have tried a mix of yum and gem install commands to get to a point where I can try to run a simple rspec test... Though having a script that does what you mentioned, which is, turn a katello system that was installed and configured into a devel environment would help me right now, imvho it does not solve what may be the bigger issue here: why do I need to install the application in order to run a test? In the rails world all you need is a test db as you don't actually want to touch the real db. > > Also, why can't we just use bundle install like most rails apps? Sure, you don't have to get all the other moving parts with this command, such as pulp, candlepin, etc, but at least get enough dependencies so that one can run tests against it? > > As a contributing user I'd like to checkout the source code, run bundle install, and be able to write and run rpsec tests :) you would get the same error (with missing ruby-devel) with bundle install as well. In this case, there is no difference between `bundle install` and `gem install`. Therefore the RPMs are the preferred way to do things. And if we had all the devel pacakges in the "Katello Devel" comps. It would by just as easy as installing it. It just doesn't help the people without yum. pchalupa is working on a better solution for `bundle install` issue (he has motivation: runs on Mac OS :) The biggest issue right not is that it's not very clear, how the gem repo is generated (we are considering to move it go github pages). It also needs a patch in bundler that will prefer system gems instead of the remote ones. But we are addressing this. -- Ivan From inecas at redhat.com Wed Aug 15 14:41:46 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 15 Aug 2012 16:41:46 +0200 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <502BB44C.605@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> <502BB44C.605@redhat.com> Message-ID: <502BB52A.8060500@redhat.com> On 08/15/2012 04:38 PM, Dmitri Dolguikh wrote: > On 15/08/12 02:26 PM, Tom McKay wrote: >> One of the design tasks for this sprint is to come up with a way to >> associate key-value pairs to systems and subscriptions. This would be >> similar to the system facts that exist. It would be nice to allow >> these pairs to exist on other objects now or in the future as well >> (eg. activation keys). >> >> Question: What is the best way to model this in the katello db? Joins >> or something? >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > How many key-value pairs are we looking at: per system/per > subscription/total per katello installation? Should they be mutable? > The question was raised about searching - do we need to support it? > > If the total number of key-value pairs is low (doesn't cross a million > rows threshold) it should work ok, although searches will start to > slow down when approaching the threshold above. > > If the total number of pairs is large, might be better to store the > whole set as a text blob, and rely on elastic search for lookups. > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel With the amount of data stored ouside of our database, it's probably worth looking into another way to search/sort things. I always thought elasticsearch is one that could be able to do it. -- Ivan From jsherril at redhat.com Wed Aug 15 14:45:15 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 15 Aug 2012 10:45:15 -0400 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <502BB22A.2010103@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> <502BA548.1030300@redhat.com> <502BAC1B.4070600@redhat.com> <502BAFE1.2060704@redhat.com> <502BB22A.2010103@redhat.com> Message-ID: <502BB5FB.6040103@redhat.com> On 08/15/2012 10:28 AM, Ohad Levy wrote: > On 08/15/2012 05:19 PM, Justin Sherrill wrote: >> On 08/15/2012 10:03 AM, Ohad Levy wrote: >>> On 08/15/2012 04:34 PM, Ivan Ne?as wrote: >>>> On 08/15/2012 03:26 PM, Tom McKay wrote: >>>>> One of the design tasks for this sprint is to come up with a way to >>>>> associate key-value pairs to systems and subscriptions. This would be >>>>> similar to the system facts that exist. It would be nice to allow >>>>> these pairs to exist on other objects now or in the future as well >>>>> (eg. activation keys). >>>>> >>>>> Question: What is the best way to model this in the katello db? Joins >>>>> or something? >>>> We have already this in User model: see >>>> >>>> serialize :preferences >>>> >>>> this serializes this parameters into blob transparently. >>>> >>> when you serialize you lose a few things >>> >>> 1. the ability to join >>> 2. the ability to filter in sql (you have to load it all, decode it >>> and do in memory search).. >>> >>> >>> Ohad >> With katello's implementation of elastic search it could alleviate some >> of those issues depending on the implementation. Although I'm not >> entirely sure what you mean by 'the ability to join'. > yeah, i mean the ability to sort.. > Ah yeah, ES would give us that too, granted if we're trying to share this across multiple apps we couldn't rely on that functionality. -Justin > Ohad >> >> -Justin >> >>>> -- 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 >> >> _______________________________________________ >> 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 adprice at redhat.com Wed Aug 15 14:55:06 2012 From: adprice at redhat.com (Adam Price) Date: Wed, 15 Aug 2012 10:55:06 -0400 (EDT) Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <502BB44C.605@redhat.com> Message-ID: <988413423.14344205.1345042506710.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dmitri Dolguikh" > To: katello-devel at redhat.com > Sent: Wednesday, August 15, 2012 10:38:04 AM > Subject: Re: [katello-devel] key-value pairs for objects in katello db > > On 15/08/12 02:26 PM, Tom McKay wrote: > > One of the design tasks for this sprint is to come up with a way to > > associate key-value pairs to systems and subscriptions. This would > > be similar to the system facts that exist. It would be nice to > > allow these pairs to exist on other objects now or in the future > > as well (eg. activation keys). > > > > Question: What is the best way to model this in the katello db? > > Joins or something? > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > How many key-value pairs are we looking at: per system/per > subscription/total per katello installation? Should they be mutable? > The > question was raised about searching - do we need to support it? > > If the total number of key-value pairs is low (doesn't cross a > million > rows threshold) it should work ok, although searches will start to > slow > down when approaching the threshold above. > > If the total number of pairs is large, might be better to store the > whole set as a text blob, and rely on elastic search for lookups. the number of pairs per system will be fairly small. it will be custom data that they can attach to a particular system (i.e. asset tag), so hopefully it won't be nearing 1M rows total. > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > -- Adam Price adprice at redhat dot com From omaciel at redhat.com Wed Aug 15 14:57:39 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 15 Aug 2012 10:57:39 -0400 (EDT) Subject: [katello-devel] moving of systems between environments In-Reply-To: <502BB1A5.8080308@redhat.com> Message-ID: <2130758643.5938752.1345042659161.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dmitri Dolguikh" > To: "Og Maciel" > Cc: "Mike McCune" , katello-devel at redhat.com > Sent: Wednesday, August 15, 2012 10:26:45 AM > Subject: Re: [katello-devel] moving of systems between environments > > It looks like rhsm detected the change in certificate serial number. > Could you check if entitlement certificates are being updated and > content urls in those certificates point to the correct environment? Where would I check that in the client? -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From msuchy at redhat.com Wed Aug 15 15:06:38 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 15 Aug 2012 17:06:38 +0200 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <988413423.14344205.1345042506710.JavaMail.root@redhat.com> References: <988413423.14344205.1345042506710.JavaMail.root@redhat.com> Message-ID: <502BBAFE.7030803@redhat.com> On 08/15/2012 04:55 PM, Adam Price wrote: > the number of pairs per system will be fairly small. it will be custom data that they can attach to a particular system (i.e. asset tag), so hopefully it won't be nearing 1M rows total. If you have 10,000 machines, each with 100 notes, you are on 1 milion records. And these numbers does not look big to me. -- Miroslav Suchy Red Hat Systems Management Engineering From omaciel at redhat.com Wed Aug 15 15:34:24 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 15 Aug 2012 11:34:24 -0400 (EDT) Subject: [katello-devel] moving of systems between environments In-Reply-To: <2130758643.5938752.1345042659161.JavaMail.root@redhat.com> Message-ID: <980564148.6019176.1345044864952.JavaMail.root@redhat.com> # openssl x509 -text -noout -in 1305231365247380612.pem -inform PEM Certificate: Data: Version: 3 (0x2) Serial Number: 12:1d:1d:02:e3:44:ac:84 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=North Carolina, L=Raleigh, O=Red Hat, OU=Cloud BU, CN=qetello02.usersys.redhat.com Validity Not Before: May 8 04:00:00 2012 GMT Not After : May 8 03:59:59 2013 GMT Subject: CN=ff808081388195650138904b044c0079 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b3:85:55:fd:b3:45:19:30:d1:ca:a7:67:65:a0: a0:57:e2:a2:10:46:d0:af:eb:58:14:42:23:6b:06: f3:43:f7:92:83:89:0f:c0:8a:2d:df:c6:f6:21:05: a5:10:1c:9a:8c:9b:22:58:90:66:22:82:61:ab:0f: 79:21:3a:06:bc:e8:b6:30:37:51:17:fa:74:10:34: f3:6b:3b:e1:1a:4e:71:98:2d:ca:33:5c:75:c5:b6: df:0e:fe:66:89:4d:8a:13:48:dc:56:91:a2:07:79: 22:3b:15:71:11:a9:05:91:c6:0b:b8:d9:c1:a8:f0: c0:b9:62:ad:c4:3e:06:09:bc:c4:71:36:f4:e5:0f: 39:6c:51:e5:8b:39:84:07:ca:6f:9e:58:4b:36:db: 63:c6:09:b8:ff:20:13:32:a2:b4:e9:38:8a:d4:2f: 1f:98:06:eb:8c:72:fa:d9:79:a9:88:70:4c:e4:e8: 96:8b:36:c2:09:65:30:9c:09:27:23:16:3f:c6:dc: 99:17:77:59:23:11:54:28:42:65:a1:ba:4f:98:ba: a8:89:34:20:b4:43:d0:dc:85:79:51:69:cf:02:a3: 6d:d3:43:00:75:61:d5:db:86:e0:fa:81:ad:28:8c: f6:99:a5:76:90:aa:f7:22:be:59:14:6d:4c:06:0f: 80:f1 Exponent: 65537 (0x10001) X509v3 extensions: Netscape Cert Type: SSL Client, S/MIME X509v3 Key Usage: Digital Signature, Key Encipherment, Data Encipherment X509v3 Authority Key Identifier: keyid:4C:F2:23:37:76:F5:6E:26:F7:71:6F:A0:02:C0:7C:98:9B:21:E8:56 DirName:/C=US/ST=North Carolina/L=Raleigh/O=Red Hat/OU=Cloud BU/CN=qetello02.usersys.redhat.com serial:A2:AD:30:18:68:C0:65:40 X509v3 Subject Key Identifier: 27:C3:9A:EB:91:C7:A1:54:A9:18:48:AE:55:51:B5:00:F8:2E:B8:51 X509v3 Extended Key Usage: TLS Web Client Authentication 1.3.6.1.4.1.2312.9.1.176.1: .+Red Hat Developer Toolset (for RHEL Server) 1.3.6.1.4.1.2312.9.1.176.3: . x86,x86_64 1.3.6.1.4.1.2312.9.1.176.2: .. 1.3.6.1.4.1.2312.9.1.69.1: ..Red Hat Enterprise Linux Server 1.3.6.1.4.1.2312.9.1.69.3: ..x86,ia64,x86_64 1.3.6.1.4.1.2312.9.1.69.2: .. 1.3.6.1.4.1.2312.9.2.168.1: ..yum 1.3.6.1.4.1.2312.9.2.168.1.1: .(Red Hat Enterprise Linux 6 Server (RPMs) 1.3.6.1.4.1.2312.9.2.168.1.2: ..rhel-6-server-rpms 1.3.6.1.4.1.2312.9.2.168.1.5: ..Red Hat 1.3.6.1.4.1.2312.9.2.168.1.6: .G/Lenovo/Development/content/dist/rhel/server/6/$releasever/$basearch/os 1.3.6.1.4.1.2312.9.2.168.1.7: .2file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release 1.3.6.1.4.1.2312.9.2.168.1.8: ..1 1.3.6.1.4.1.2312.9.2.168.1.10: rhel-6-server . 1.3.6.1.4.1.2312.9.2.1398.1: ..yum 1.3.6.1.4.1.2312.9.2.1398.1.1: .*Red Hat CloudForms Tools for RHEL 6 (RPMs) 1.3.6.1.4.1.2312.9.2.1398.1.2: ..rhel-6-server-cf-tools-1-rpms 1.3.6.1.4.1.2312.9.2.1398.1.5: ..Red Hat 1.3.6.1.4.1.2312.9.2.1398.1.6: .T/Lenovo/Development/content/dist/rhel/server/6/$releasever/$basearch/cf-tools/1.0/os 1.3.6.1.4.1.2312.9.2.1398.1.7: .2file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release 1.3.6.1.4.1.2312.9.2.1398.1.8: ..1 1.3.6.1.4.1.2312.9.2.1398.1.9: ..86400 1.3.6.1.4.1.2312.9.2.1398.1.10: rhel-6-server . 1.3.6.1.4.1.2312.9.4.1: .ERed Hat Enterprise Linux Server, Premium (8 sockets) (Up to 4 guests) 1.3.6.1.4.1.2312.9.4.2: . ff808081388195650138900ab1d8003b 1.3.6.1.4.1.2312.9.4.3: ..RH0103708 1.3.6.1.4.1.2312.9.4.5: ..2 1.3.6.1.4.1.2312.9.4.9: ..8 1.3.6.1.4.1.2312.9.4.6: ..2012-05-08T04:00:00Z 1.3.6.1.4.1.2312.9.4.7: ..2013-05-08T03:59:59Z 1.3.6.1.4.1.2312.9.4.12: ..0 1.3.6.1.4.1.2312.9.4.10: ..3020027 1.3.6.1.4.1.2312.9.4.13: ..1580807 1.3.6.1.4.1.2312.9.4.14: ..0 1.3.6.1.4.1.2312.9.4.15: ..Premium 1.3.6.1.4.1.2312.9.4.16: ..L1-L3 1.3.6.1.4.1.2312.9.4.11: ..1 1.3.6.1.4.1.2312.9.5.1: .$8ac5fb6a-6258-41e6-9e4e-656a57da3934 Signature Algorithm: sha1WithRSAEncryption c0:6a:49:f0:00:95:d4:93:e1:1c:0a:47:27:bf:44:7b:cb:33: 31:c9:65:31:37:8b:b0:e7:85:2e:e3:65:81:8d:78:25:19:c5: 43:a0:ff:c2:88:5b:e0:06:0d:48:7b:71:46:6b:3b:4b:0b:5d: b1:17:2b:c0:65:97:52:f0:bd:dc:b0:2d:3a:af:51:5a:82:13: 33:e3:e0:28:75:9a:c2:45:00:16:36:c5:49:3a:5f:d2:09:7b: 4d:cf:bf:99:b1:89:ed:99:a3:6c:7b:98:a3:6c:2f:27:2d:68: 7f:77:67:ab:a1:72:b6:5b:19:a5:ed:e8:42:e5:69:b3:34:7b: 66:44:5a:15:25:de:c3:5f:1d:72:2d:10:38:f4:44:45:de:30: c9:58:76:58:a4:18:60:d6:27:6d:7b:75:55:a2:cd:56:db:7e: 80:35:55:0b:49:9f:ec:db:59:97:42:f1:62:23:f9:43:0f:0d: 7d:ab:5d:2b:13:14:76:84:44:a9:11:69:57:e4:24:b5:92:a4: 51:e0:bc:1b:bd:22:48:93:02:31:b3:8e:84:ed:5a:5d:8a:20: a8:78:cd:24:19:f2:1c:1e:bb:56:96:c0:a8:d8:ac:15:80:9b: 8d:df:5b:df:1b:46:b9:a3:36:01:3c:36:7c:9a:0c:fb:71:fc: 27:66:46:bb -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From hbrock at redhat.com Wed Aug 15 15:45:18 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 15 Aug 2012 11:45:18 -0400 Subject: [katello-devel] Experience contributing a new feature as a user In-Reply-To: <502BB487.2070201@redhat.com> References: <162222688.5838124.1345037857934.JavaMail.root@redhat.com> <502BB487.2070201@redhat.com> Message-ID: <20120815154518.GM9380@redhat.com> On Wed, Aug 15, 2012 at 04:39:03PM +0200, Ivan Ne?as wrote: > On 08/15/2012 03:37 PM, Og Maciel wrote: > >Hey Ivan, thanks for the reply. I am actually running Fedora (and RHEL 6.3) and have tried a mix of yum and gem install commands to get to a point where I can try to run a simple rspec test... Though having a script that does what you mentioned, which is, turn a katello system that was installed and configured into a devel environment would help me right now, imvho it does not solve what may be the bigger issue here: why do I need to install the application in order to run a test? In the rails world all you need is a test db as you don't actually want to touch the real db. > > > >Also, why can't we just use bundle install like most rails apps? Sure, you don't have to get all the other moving parts with this command, such as pulp, candlepin, etc, but at least get enough dependencies so that one can run tests against it? > > > >As a contributing user I'd like to checkout the source code, run bundle install, and be able to write and run rpsec tests :) > you would get the same error (with missing ruby-devel) with bundle > install as well. In this case, there is no difference between > `bundle install` and `gem install`. Therefore the RPMs are the > preferred way to do things. And if we had all the devel pacakges in > the "Katello Devel" comps. It would by just as easy as installing > it. It just doesn't help the people without yum. > > pchalupa is working on a better solution for `bundle install` issue > (he has motivation: runs on Mac OS :) The biggest issue right not is > that it's not very clear, how the gem repo is generated (we are > considering to move it go github pages). It also needs a patch in > bundler that will prefer system gems instead of the remote ones. But > we are addressing this. You guys are aware of Jay Guiditta's work on exactly this issue, right? We're currently using a patched Bundler for Aeolus that uses standard gems by default, but will switch to system (rpm-installed) gems if you set the appropriate flag. --H -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From bkearney at redhat.com Wed Aug 15 16:28:49 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 15 Aug 2012 12:28:49 -0400 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <502BB44C.605@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> <502BB44C.605@redhat.com> Message-ID: <502BCE41.2020809@redhat.com> On 08/15/2012 10:38 AM, Dmitri Dolguikh wrote: > On 15/08/12 02:26 PM, Tom McKay wrote: >> One of the design tasks for this sprint is to come up with a way to >> associate key-value pairs to systems and subscriptions. This would be >> similar to the system facts that exist. It would be nice to allow >> these pairs to exist on other objects now or in the future as well >> (eg. activation keys). >> >> Question: What is the best way to model this in the katello db? Joins >> or something? >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > How many key-value pairs are we looking at: per system/per > subscription/total per katello installation? Should they be mutable? The > question was raised about searching - do we need to support it? Per org. I would like to annotate all subscriptions with certain values. So, there is a notion of the class, and then the instance with values. > > If the total number of key-value pairs is low (doesn't cross a million > rows threshold) it should work ok, although searches will start to slow > down when approaching the threshold above. > Less than a million :) -- bk From dmitri at redhat.com Wed Aug 15 16:30:49 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 15 Aug 2012 17:30:49 +0100 Subject: [katello-devel] key-value pairs for objects in katello db In-Reply-To: <502BCE41.2020809@redhat.com> References: <877867409.9855794.1345037197402.JavaMail.root@redhat.com> <502BB44C.605@redhat.com> <502BCE41.2020809@redhat.com> Message-ID: <502BCEB9.3070807@redhat.com> On 15/08/12 05:28 PM, Bryan Kearney wrote: > On 08/15/2012 10:38 AM, Dmitri Dolguikh wrote: >> On 15/08/12 02:26 PM, Tom McKay wrote: >>> One of the design tasks for this sprint is to come up with a way to >>> associate key-value pairs to systems and subscriptions. This would be >>> similar to the system facts that exist. It would be nice to allow >>> these pairs to exist on other objects now or in the future as well >>> (eg. activation keys). >>> >>> Question: What is the best way to model this in the katello db? Joins >>> or something? >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> How many key-value pairs are we looking at: per system/per >> subscription/total per katello installation? Should they be mutable? The >> question was raised about searching - do we need to support it? > > Per org. I would like to annotate all subscriptions with certain > values. So, there is a notion of the class, and then the instance with > values. > >> >> If the total number of key-value pairs is low (doesn't cross a million >> rows threshold) it should work ok, although searches will start to slow >> down when approaching the threshold above. >> > > Less than a million :) > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Might be useful to generate a bunch of data approximating what we expect and check execution plans on various queries... -d From bkearney at redhat.com Wed Aug 15 16:34:38 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 15 Aug 2012 12:34:38 -0400 Subject: [katello-devel] moving of systems between environments In-Reply-To: <980564148.6019176.1345044864952.JavaMail.root@redhat.com> References: <980564148.6019176.1345044864952.JavaMail.root@redhat.com> Message-ID: <502BCF9E.3010502@redhat.com> If you have the latest, you can use rct :) rct cat-cert some/swanky/cert -- bk On 08/15/2012 11:34 AM, Og Maciel wrote: > # openssl x509 -text -noout -in 1305231365247380612.pem -inform PEM > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 12:1d:1d:02:e3:44:ac:84 > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=US, ST=North Carolina, L=Raleigh, O=Red Hat, OU=Cloud BU, CN=qetello02.usersys.redhat.com > Validity > Not Before: May 8 04:00:00 2012 GMT > Not After : May 8 03:59:59 2013 GMT > Subject: CN=ff808081388195650138904b044c0079 > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > 00:b3:85:55:fd:b3:45:19:30:d1:ca:a7:67:65:a0: > a0:57:e2:a2:10:46:d0:af:eb:58:14:42:23:6b:06: > f3:43:f7:92:83:89:0f:c0:8a:2d:df:c6:f6:21:05: > a5:10:1c:9a:8c:9b:22:58:90:66:22:82:61:ab:0f: > 79:21:3a:06:bc:e8:b6:30:37:51:17:fa:74:10:34: > f3:6b:3b:e1:1a:4e:71:98:2d:ca:33:5c:75:c5:b6: > df:0e:fe:66:89:4d:8a:13:48:dc:56:91:a2:07:79: > 22:3b:15:71:11:a9:05:91:c6:0b:b8:d9:c1:a8:f0: > c0:b9:62:ad:c4:3e:06:09:bc:c4:71:36:f4:e5:0f: > 39:6c:51:e5:8b:39:84:07:ca:6f:9e:58:4b:36:db: > 63:c6:09:b8:ff:20:13:32:a2:b4:e9:38:8a:d4:2f: > 1f:98:06:eb:8c:72:fa:d9:79:a9:88:70:4c:e4:e8: > 96:8b:36:c2:09:65:30:9c:09:27:23:16:3f:c6:dc: > 99:17:77:59:23:11:54:28:42:65:a1:ba:4f:98:ba: > a8:89:34:20:b4:43:d0:dc:85:79:51:69:cf:02:a3: > 6d:d3:43:00:75:61:d5:db:86:e0:fa:81:ad:28:8c: > f6:99:a5:76:90:aa:f7:22:be:59:14:6d:4c:06:0f: > 80:f1 > Exponent: 65537 (0x10001) > X509v3 extensions: > Netscape Cert Type: > SSL Client, S/MIME > X509v3 Key Usage: > Digital Signature, Key Encipherment, Data Encipherment > X509v3 Authority Key Identifier: > keyid:4C:F2:23:37:76:F5:6E:26:F7:71:6F:A0:02:C0:7C:98:9B:21:E8:56 > DirName:/C=US/ST=North Carolina/L=Raleigh/O=Red Hat/OU=Cloud BU/CN=qetello02.usersys.redhat.com > serial:A2:AD:30:18:68:C0:65:40 > > X509v3 Subject Key Identifier: > 27:C3:9A:EB:91:C7:A1:54:A9:18:48:AE:55:51:B5:00:F8:2E:B8:51 > X509v3 Extended Key Usage: > TLS Web Client Authentication > 1.3.6.1.4.1.2312.9.1.176.1: > .+Red Hat Developer Toolset (for RHEL Server) > 1.3.6.1.4.1.2312.9.1.176.3: > . > x86,x86_64 > 1.3.6.1.4.1.2312.9.1.176.2: > .. > 1.3.6.1.4.1.2312.9.1.69.1: > ..Red Hat Enterprise Linux Server > 1.3.6.1.4.1.2312.9.1.69.3: > ..x86,ia64,x86_64 > 1.3.6.1.4.1.2312.9.1.69.2: > .. > 1.3.6.1.4.1.2312.9.2.168.1: > ..yum > 1.3.6.1.4.1.2312.9.2.168.1.1: > .(Red Hat Enterprise Linux 6 Server (RPMs) > 1.3.6.1.4.1.2312.9.2.168.1.2: > ..rhel-6-server-rpms > 1.3.6.1.4.1.2312.9.2.168.1.5: > ..Red Hat > 1.3.6.1.4.1.2312.9.2.168.1.6: > .G/Lenovo/Development/content/dist/rhel/server/6/$releasever/$basearch/os > 1.3.6.1.4.1.2312.9.2.168.1.7: > .2file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release > 1.3.6.1.4.1.2312.9.2.168.1.8: > ..1 > 1.3.6.1.4.1.2312.9.2.168.1.10: > rhel-6-server . > 1.3.6.1.4.1.2312.9.2.1398.1: > ..yum > 1.3.6.1.4.1.2312.9.2.1398.1.1: > .*Red Hat CloudForms Tools for RHEL 6 (RPMs) > 1.3.6.1.4.1.2312.9.2.1398.1.2: > ..rhel-6-server-cf-tools-1-rpms > 1.3.6.1.4.1.2312.9.2.1398.1.5: > ..Red Hat > 1.3.6.1.4.1.2312.9.2.1398.1.6: > .T/Lenovo/Development/content/dist/rhel/server/6/$releasever/$basearch/cf-tools/1.0/os > 1.3.6.1.4.1.2312.9.2.1398.1.7: > .2file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release > 1.3.6.1.4.1.2312.9.2.1398.1.8: > ..1 > 1.3.6.1.4.1.2312.9.2.1398.1.9: > ..86400 > 1.3.6.1.4.1.2312.9.2.1398.1.10: > rhel-6-server . > 1.3.6.1.4.1.2312.9.4.1: > .ERed Hat Enterprise Linux Server, Premium (8 sockets) (Up to 4 guests) > 1.3.6.1.4.1.2312.9.4.2: > . ff808081388195650138900ab1d8003b > 1.3.6.1.4.1.2312.9.4.3: > ..RH0103708 > 1.3.6.1.4.1.2312.9.4.5: > ..2 > 1.3.6.1.4.1.2312.9.4.9: > ..8 > 1.3.6.1.4.1.2312.9.4.6: > ..2012-05-08T04:00:00Z > 1.3.6.1.4.1.2312.9.4.7: > ..2013-05-08T03:59:59Z > 1.3.6.1.4.1.2312.9.4.12: > ..0 > 1.3.6.1.4.1.2312.9.4.10: > ..3020027 > 1.3.6.1.4.1.2312.9.4.13: > ..1580807 > 1.3.6.1.4.1.2312.9.4.14: > ..0 > 1.3.6.1.4.1.2312.9.4.15: > ..Premium > 1.3.6.1.4.1.2312.9.4.16: > ..L1-L3 > 1.3.6.1.4.1.2312.9.4.11: > ..1 > 1.3.6.1.4.1.2312.9.5.1: > .$8ac5fb6a-6258-41e6-9e4e-656a57da3934 > Signature Algorithm: sha1WithRSAEncryption > c0:6a:49:f0:00:95:d4:93:e1:1c:0a:47:27:bf:44:7b:cb:33: > 31:c9:65:31:37:8b:b0:e7:85:2e:e3:65:81:8d:78:25:19:c5: > 43:a0:ff:c2:88:5b:e0:06:0d:48:7b:71:46:6b:3b:4b:0b:5d: > b1:17:2b:c0:65:97:52:f0:bd:dc:b0:2d:3a:af:51:5a:82:13: > 33:e3:e0:28:75:9a:c2:45:00:16:36:c5:49:3a:5f:d2:09:7b: > 4d:cf:bf:99:b1:89:ed:99:a3:6c:7b:98:a3:6c:2f:27:2d:68: > 7f:77:67:ab:a1:72:b6:5b:19:a5:ed:e8:42:e5:69:b3:34:7b: > 66:44:5a:15:25:de:c3:5f:1d:72:2d:10:38:f4:44:45:de:30: > c9:58:76:58:a4:18:60:d6:27:6d:7b:75:55:a2:cd:56:db:7e: > 80:35:55:0b:49:9f:ec:db:59:97:42:f1:62:23:f9:43:0f:0d: > 7d:ab:5d:2b:13:14:76:84:44:a9:11:69:57:e4:24:b5:92:a4: > 51:e0:bc:1b:bd:22:48:93:02:31:b3:8e:84:ed:5a:5d:8a:20: > a8:78:cd:24:19:f2:1c:1e:bb:56:96:c0:a8:d8:ac:15:80:9b: > 8d:df:5b:df:1b:46:b9:a3:36:01:3c:36:7c:9a:0c:fb:71:fc: > 27:66:46:bb > From inecas at redhat.com Wed Aug 15 16:44:32 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 15 Aug 2012 18:44:32 +0200 Subject: [katello-devel] Experience contributing a new feature as a user In-Reply-To: <20120815160649.GC3581@redhat.com> References: <162222688.5838124.1345037857934.JavaMail.root@redhat.com> <502BB487.2070201@redhat.com> <20120815154518.GM9380@redhat.com> <20120815160649.GC3581@redhat.com> Message-ID: <502BD1F0.1090402@redhat.com> On Wed 15 Aug 2012 06:06:49 PM CEST, Jason Guiditta wrote: > On 15/08/12 11:45 -0400, Hugh Brock wrote: >> On Wed, Aug 15, 2012 at 04:39:03PM +0200, Ivan Ne?as wrote: >>> On 08/15/2012 03:37 PM, Og Maciel wrote: >>> >Hey Ivan, thanks for the reply. I am actually running Fedora (and >>> RHEL 6.3) and have tried a mix of yum and gem install commands to >>> get to a point where I can try to run a simple rspec test... Though >>> having a script that does what you mentioned, which is, turn a >>> katello system that was installed and configured into a devel >>> environment would help me right now, imvho it does not solve what >>> may be the bigger issue here: why do I need to install the >>> application in order to run a test? In the rails world all you need >>> is a test db as you don't actually want to touch the real db. >>> > >>> >Also, why can't we just use bundle install like most rails apps? >>> Sure, you don't have to get all the other moving parts with this >>> command, such as pulp, candlepin, etc, but at least get enough >>> dependencies so that one can run tests against it? >>> > >>> >As a contributing user I'd like to checkout the source code, run >>> bundle install, and be able to write and run rpsec tests :) >>> you would get the same error (with missing ruby-devel) with bundle >>> install as well. In this case, there is no difference between >>> `bundle install` and `gem install`. Therefore the RPMs are the >>> preferred way to do things. And if we had all the devel pacakges in >>> the "Katello Devel" comps. It would by just as easy as installing >>> it. It just doesn't help the people without yum. >>> >>> pchalupa is working on a better solution for `bundle install` issue >>> (he has motivation: runs on Mac OS :) The biggest issue right not is >>> that it's not very clear, how the gem repo is generated (we are >>> considering to move it go github pages). It also needs a patch in >>> bundler that will prefer system gems instead of the remote ones. But >>> we are addressing this. >> >> You guys are aware of Jay Guiditta's work on exactly this issue, right? >> We're currently using a patched Bundler for Aeolus that uses standard >> gems by default, but will switch to system (rpm-installed) gems if you >> set the appropriate flag. >> >> --H >> > > Just to clarify, it is more of a reuse of the bundle gemfile dsl, the > library is called bundler_ext, and there is an example usage described > in the README on github: > https://github.com/aeolus-incubator/bundler_ext#readme > > We currently use an embedded version of this in conductor (exactly the > same code), and will move to depending on the gem as soon as it gets > packaged as an rpm (probably post 1.1 for us). > > > Feel free to ping me with questions or issues. > > -j Interesting. In the meantime, we've found another possible way here https://github.com/carlhuda/bundler/issues/1964 (dating the same time as yours), with a little bit different approach (and little buit monkey patching :(. We haven't though about turning bundler off completely for those lucky ones with Fedora/RHEL/CentOS, since not all development dependencies were packed as RPMs. But we are heading this, in which case this approach is much stable, than monkey patching (although at the end it seems like just one method alias). One another concern we have is to provide the same code for developers, that is running in production: a gem repo with gems repacked from RPMs with the patches applied. Seems funny to see the Gem -> RPM -> Gem process, but less funny is to see some random error only on a production machine, and we've already hit that. Therefore I'm still more fan of having custom gem repos. I have a student working on a RPM -> Gem conversion. I will check the progress. -- Ivan From dmitri at redhat.com Wed Aug 15 17:46:13 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 15 Aug 2012 18:46:13 +0100 Subject: [katello-devel] Renaming of environments: summary, take II Message-ID: <502BE065.9050003@redhat.com> Please see original conversation thread [1], first attempt at summary [2], and BZ [3] for details. The majority of the conversation revolved around use of human-readable ids to preserve user-friendiness of urls vs. using uuids to preserve data consistency of client applications that use Katello API. Another concern expressed was readability of repository urls genereated by Katello in yum configuration files. It was suggested to use Punycode for encoding of non-ascii-based labels. Proposed changes: - introduce immutable labels - replace use of environment name with environment label in urls not impacting data integrity, such as repository urls. This would eliminate the need for entitlement certificate regeneration after environment name changes - introduce uuids, and replace current use of primary db keys in resource urls with uuids Tasks on Katello side: - take a look at and implement Punycode - introduce environment labels: db changes, model changes, controller changes - introduce uuids: db changes, model changes, controller changes - figure out migration for existing Katello installations Tasks on Candlepin side: - add label and uuid fields to model. Replace use of environment names with environment labels [1] https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html [2] https://www.redhat.com/archives/katello-devel/2012-August/msg00144.html [3] https://bugzilla.redhat.com/show_bug.cgi?id=795928 [4] http://en.wikipedia.org/wiki/Punycode -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvaldez at redhat.com Wed Aug 15 20:02:04 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Wed, 15 Aug 2012 15:02:04 -0500 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <5006F35F.60008@redhat.com> References: <5006F35F.60008@redhat.com> Message-ID: <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> Team, I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. Thanks, Vinny On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: > Do you want to be a star, and help promote Katello. Have we got a deal for you: > > https://fedorahosted.org/katello/wiki/Screencasts > > -- bk > From adprice at redhat.com Wed Aug 15 20:42:37 2012 From: adprice at redhat.com (Adam Price) Date: Wed, 15 Aug 2012 16:42:37 -0400 (EDT) Subject: [katello-devel] Custom Attributes for a System In-Reply-To: <1852354915.14545917.1345062317201.JavaMail.root@redhat.com> Message-ID: <1050230022.14552671.1345063357389.JavaMail.root@redhat.com> after looking at the email thread about key-value pairs for a system, i put together a small design doc outlining what this change entails. please look it over and make some comments. https://fedorahosted.org/katello/wiki/SystemsCustomAttributesDesign Brno guys, please specifically look over the cli portion. i want to make sure we stay with the same command-style (naming, etc) as the rest of the cli. thanks. -- Adam Price adprice at redhat dot com From vvaldez at redhat.com Wed Aug 15 21:22:40 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Wed, 15 Aug 2012 16:22:40 -0500 Subject: [katello-devel] Error syncing Fedora 16 on package openoffice.org-voikko Message-ID: <5470F238-544D-4409-AC43-0FD2307B88BF@redhat.com> I setup katello on Fedora 16 and tried to sync Fedora 16 from a repo created from a gold ISO. I get the following error: 2012-08-15 20:30:01,845 3359:140003283810048: pulp.server.tasking.task:ERROR: task:472 Task failed: Task 261f4dcf-e740-11e1-b495-525400360b28: _sync(Example-Fedora16-fedora16-x86_64, synchronizer=, skip={}, max_speed=None, threads=4, progress_callback=>) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/pulp/server/tasking/task.py", line 418, in run result = self.callable(*self.args, **self.kwargs) File "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", line 283, in _sync progress_callback, synchronizer, max_speed, threads) File "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", line 379, in fetch_content added_errataids = synchronizer.import_metadata(repo_dir, repo_id, skip_dict) File "/usr/lib/python2.7/site-packages/pulp/server/api/synchronizers.py", line 415, in import_metadata self.repo_api.collection.save(repo, safe=True) File "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", line 80, in retry return method(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line 237, in save manipulate, safe, _check_keys=True, **kwargs) File "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", line 80, in retry return method(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line 411, in update _check_keys, self.__uuid_subtype), safe) InvalidDocument: key 'openoffice.org-voikko' must not contain '.' Is there anything I am doing wrong here? katello-1.0.4-1.fc16.noarch katello-cli-common-1.0.1-1.fc16.noarch katello-configure-1.0.1-1.fc16.noarch katello-common-1.0.4-1.fc16.noarch katello-qpid-broker-key-pair-1.0-1.noarch katello-glue-foreman-1.0.4-1.fc16.noarch katello-all-1.0.4-1.fc16.noarch katello-certs-tools-1.1.7-1.fc16.noarch katello-qpid-client-key-pair-1.0-1.noarch katello-repos-1.0.3-1.fc16.noarch katello-glue-candlepin-1.0.4-1.fc16.noarch katello-cli-1.0.1-1.fc16.noarch katello-glue-pulp-1.0.4-1.fc16.noarch katello-candlepin-cert-key-pair-1.0-1.noarch katello-selinux-1.0.1-1.fc16.noarch pulp-common-1.1.11-1.fc16.noarch pulp-selinux-server-1.1.11-1.fc16.noarch pulp-1.1.11-1.fc16.noarch candlepin-0.7.4.2-1.fc16.noarch candlepin-tomcat6-0.7.4.2-1.fc16.noarch qpid-cpp-server-0.16-3.1.fc16.x86_64 qpid-cpp-client-0.16-3.1.fc16.x86_64 qpid-cpp-server-ssl-0.16-3.1.fc16.x86_64 qpid-cpp-client-ssl-0.16-3.1.fc16.x86_64 Regards, Vinny -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsanders at redhat.com Wed Aug 15 21:46:55 2012 From: tsanders at redhat.com (Todd Sanders) Date: Wed, 15 Aug 2012 17:46:55 -0400 Subject: [katello-devel] Error syncing Fedora 16 on package openoffice.org-voikko In-Reply-To: <5470F238-544D-4409-AC43-0FD2307B88BF@redhat.com> References: <5470F238-544D-4409-AC43-0FD2307B88BF@redhat.com> Message-ID: <502C18CF.9090907@redhat.com> Probably the version of pymongo....see: https://fedorahosted.org/pulp/wiki/UGFAQ#rpmname -Todd On 08/15/2012 05:22 PM, Vinny Valdez wrote: > I setup katello on Fedora 16 and tried to sync Fedora 16 from a repo > created from a gold ISO. I get the following error: > > 2012-08-15 20:30:01,845 3359:140003283810048: > pulp.server.tasking.task:ERROR: task:472 Task failed: Task > 261f4dcf-e740-11e1-b495-525400360b28: > _sync(Example-Fedora16-fedora16-x86_64, > synchronizer= 0x7f554bcc7bd0>, skip={}, max_speed=None, threads=4, > progress_callback= >) > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/pulp/server/tasking/task.py", > line 418, in run > result = self.callable(*self.args, **self.kwargs) > File > "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", line > 283, in _sync > progress_callback, synchronizer, max_speed, threads) > File > "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", line > 379, in fetch_content > added_errataids = synchronizer.import_metadata(repo_dir, repo_id, > skip_dict) > File > "/usr/lib/python2.7/site-packages/pulp/server/api/synchronizers.py", > line 415, in import_metadata > self.repo_api.collection.save(repo, safe=True) > File > "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", line > 80, in retry > return method(*args, **kwargs) > File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", > line 237, in save > manipulate, safe, _check_keys=True, **kwargs) > File > "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", line > 80, in retry > return method(*args, **kwargs) > File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", > line 411, in update > _check_keys, self.__uuid_subtype), safe) > InvalidDocument: key 'openoffice.org -voikko' > must not contain '.' > > Is there anything I am doing wrong here? > > katello-1.0.4-1.fc16.noarch > katello-cli-common-1.0.1-1.fc16.noarch > katello-configure-1.0.1-1.fc16.noarch > katello-common-1.0.4-1.fc16.noarch > katello-qpid-broker-key-pair-1.0-1.noarch > katello-glue-foreman-1.0.4-1.fc16.noarch > katello-all-1.0.4-1.fc16.noarch > katello-certs-tools-1.1.7-1.fc16.noarch > katello-qpid-client-key-pair-1.0-1.noarch > katello-repos-1.0.3-1.fc16.noarch > katello-glue-candlepin-1.0.4-1.fc16.noarch > katello-cli-1.0.1-1.fc16.noarch > katello-glue-pulp-1.0.4-1.fc16.noarch > katello-candlepin-cert-key-pair-1.0-1.noarch > katello-selinux-1.0.1-1.fc16.noarch > pulp-common-1.1.11-1.fc16.noarch > pulp-selinux-server-1.1.11-1.fc16.noarch > pulp-1.1.11-1.fc16.noarch > candlepin-0.7.4.2-1.fc16.noarch > candlepin-tomcat6-0.7.4.2-1.fc16.noarch > qpid-cpp-server-0.16-3.1.fc16.x86_64 > qpid-cpp-client-0.16-3.1.fc16.x86_64 > qpid-cpp-server-ssl-0.16-3.1.fc16.x86_64 > qpid-cpp-client-ssl-0.16-3.1.fc16.x86_64 > > Regards, > > Vinny > > > > _______________________________________________ > 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 vvaldez at redhat.com Wed Aug 15 22:49:15 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Wed, 15 Aug 2012 17:49:15 -0500 Subject: [katello-devel] Error syncing Fedora 16 In-Reply-To: <502C18CF.9090907@redhat.com> References: <5470F238-544D-4409-AC43-0FD2307B88BF@redhat.com> <502C18CF.9090907@redhat.com> Message-ID: My mistake, the error is actually as follows: 2012-08-15 22:33:59,275 2436:139770315405056: grinder.ProgressTracker:WARNING: ProgressTracker:141 http://files.example. com/pub/installers/fedora/16/x86_64/os//images/boot.iso changing tracker for tree_file total_size_bytes from 0 to 332 2012-08-15 22:33:59,278 2436:139770315405056: grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, read md5sum of: 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b 2012-08-15 22:33:59,279 2436:139770315405056: grinder.BaseFetch:WARNING: activeobject:162 Retrying fetch of: boot.iso with 1 retry attempts left. HTTP status was 404 2012-08-15 22:33:59,279 2436:139770315405056: grinder.BaseFetch:INFO: activeobject:162 Cleanup /var/lib/pulp/distributions/ks-Fedora-Fedora-16-x86_64/boot.iso 2012-08-15 22:33:59,279 2436:139770315405056: grinder.ProgressTracker:WARNING: ProgressTracker:258 Resetting progress for 2012-08-15 22:33:59,283 2436:139770315405056: grinder.BaseFetch:INFO: activeobject:162 Fetching Unknown bytes: boot.iso from http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, read md5sum of: 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:WARNING: activeobject:162 Retrying fetch of: boot.iso with 0 retry attempts left. HTTP status was 404 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:INFO: activeobject:162 Cleanup /var/lib/pulp/distributions/ks-Fedora-Fedora-16-x86_64/boot.iso 2012-08-15 22:33:59,285 2436:139770315405056: grinder.ProgressTracker:WARNING: ProgressTracker:258 Resetting progress for 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:INFO: activeobject:162 Fetching Unknown bytes: boot.iso from http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso 2012-08-15 22:33:59,287 2436:139770315405056: grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, read md5sum of: 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b When I first hit this error, I thought I needed to update as a gut reaction troubleshooting step, I did so then ran into the updated pymongo issue, and incorrectly pasted that as the culprit. scollier also gets the same error in his environment. Vinny On Aug 15, 2012, at 4:46 PM, Todd Sanders wrote: > Probably the version of pymongo....see: https://fedorahosted.org/pulp/wiki/UGFAQ#rpmname > > -Todd > > On 08/15/2012 05:22 PM, Vinny Valdez wrote: >> I setup katello on Fedora 16 and tried to sync Fedora 16 from a repo created from a gold ISO. I get the following error: >> >> 2012-08-15 20:30:01,845 3359:140003283810048: pulp.server.tasking.task:ERROR: task:472 Task failed: Task 261f4dcf-e740-11e1-b495-525400360b28: _sync(Example-Fedora16-fedora16-x86_64, synchronizer=, skip={}, max_speed=None, threads=4, progress_callback=>) >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/pulp/server/tasking/task.py", line 418, in run >> result = self.callable(*self.args, **self.kwargs) >> File "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", line 283, in _sync >> progress_callback, synchronizer, max_speed, threads) >> File "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", line 379, in fetch_content >> added_errataids = synchronizer.import_metadata(repo_dir, repo_id, skip_dict) >> File "/usr/lib/python2.7/site-packages/pulp/server/api/synchronizers.py", line 415, in import_metadata >> self.repo_api.collection.save(repo, safe=True) >> File "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", line 80, in retry >> return method(*args, **kwargs) >> File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line 237, in save >> manipulate, safe, _check_keys=True, **kwargs) >> File "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", line 80, in retry >> return method(*args, **kwargs) >> File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line 411, in update >> _check_keys, self.__uuid_subtype), safe) >> InvalidDocument: key 'openoffice.org-voikko' must not contain '.' >> >> Is there anything I am doing wrong here? >> >> katello-1.0.4-1.fc16.noarch >> katello-cli-common-1.0.1-1.fc16.noarch >> katello-configure-1.0.1-1.fc16.noarch >> katello-common-1.0.4-1.fc16.noarch >> katello-qpid-broker-key-pair-1.0-1.noarch >> katello-glue-foreman-1.0.4-1.fc16.noarch >> katello-all-1.0.4-1.fc16.noarch >> katello-certs-tools-1.1.7-1.fc16.noarch >> katello-qpid-client-key-pair-1.0-1.noarch >> katello-repos-1.0.3-1.fc16.noarch >> katello-glue-candlepin-1.0.4-1.fc16.noarch >> katello-cli-1.0.1-1.fc16.noarch >> katello-glue-pulp-1.0.4-1.fc16.noarch >> katello-candlepin-cert-key-pair-1.0-1.noarch >> katello-selinux-1.0.1-1.fc16.noarch >> pulp-common-1.1.11-1.fc16.noarch >> pulp-selinux-server-1.1.11-1.fc16.noarch >> pulp-1.1.11-1.fc16.noarch >> candlepin-0.7.4.2-1.fc16.noarch >> candlepin-tomcat6-0.7.4.2-1.fc16.noarch >> qpid-cpp-server-0.16-3.1.fc16.x86_64 >> qpid-cpp-client-0.16-3.1.fc16.x86_64 >> qpid-cpp-server-ssl-0.16-3.1.fc16.x86_64 >> qpid-cpp-client-ssl-0.16-3.1.fc16.x86_64 >> >> Regards, >> >> Vinny >> >> >> >> _______________________________________________ >> 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 paji at redhat.com Wed Aug 15 23:05:16 2012 From: paji at redhat.com (Partha Aji) Date: Wed, 15 Aug 2012 19:05:16 -0400 (EDT) Subject: [katello-devel] New call Justin added to AR In-Reply-To: <691057316.6303758.1345071592115.JavaMail.root@redhat.com> Message-ID: <1733269792.6304759.1345071916985.JavaMail.root@redhat.com> Many may not know this, so just highlighting a new call Just Sherrill added to katello master. Its called "pluck" Often we just need one attribute of an AR object, for example if we just need the list of ids of environments or pulp_ids of a Repository, we'd write something like this KTEnvironment.select(:id).where(<...>).collect {|env| env.id} Repository.select(:id).where(<...>).collect {|r| r.pulp_id} One common mistake here is people forget to add the "select" so you end up loading all columns even though you just need id or pulp_id With Justin's magic method (which is in newer versions of AR. He back ported it) one can now do KTEnvironment.where(<...>).pluck(:id) Repository.where(<...>).pluck(:pulp_id) This magic method makes sure you are only selecting what you need. Partha From bkearney at redhat.com Thu Aug 16 01:00:25 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 15 Aug 2012 21:00:25 -0400 Subject: [katello-devel] Custom Attributes for a System In-Reply-To: <1050230022.14552671.1345063357389.JavaMail.root@redhat.com> References: <1050230022.14552671.1345063357389.JavaMail.root@redhat.com> Message-ID: <502C4629.4040202@redhat.com> On 08/15/2012 04:42 PM, Adam Price wrote: > after looking at the email thread about key-value pairs for a system, i put together a small design doc outlining what this change entails. please look it over and make some comments. > > https://fedorahosted.org/katello/wiki/SystemsCustomAttributesDesign > > Brno guys, please specifically look over the cli portion. i want to make sure we stay with the same command-style (naming, etc) as the rest of the cli. thanks. > ouple of things: 1) How do I extend this to work for more than just systems? i would like to see this on many objects. 2) How do I set up all objects (in an org mind you) to add an attribute on each object. For example, In my org I would like all systems to have the AssetTag and Project fields. Then, whoever is defining a system will see these fields. As a bonus, can I give them a type and some type of regex to validate? 3) can I gemify this to share it with aeolus? -- bk From jomara at redhat.com Thu Aug 16 03:59:52 2012 From: jomara at redhat.com (Jordan O'Mara) Date: Wed, 15 Aug 2012 23:59:52 -0400 (EDT) Subject: [katello-devel] Custom Attributes for a System In-Reply-To: <502C4629.4040202@redhat.com> Message-ID: <261375271.5565550.1345089592479.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/15/2012 04:42 PM, Adam Price wrote: > > after looking at the email thread about key-value pairs for a > > system, i put together a small design doc outlining what this > > change entails. please look it over and make some comments. > > > > https://fedorahosted.org/katello/wiki/SystemsCustomAttributesDesign > > > > Brno guys, please specifically look over the cli portion. i want to > > make sure we stay with the same command-style (naming, etc) as the > > rest of the cli. thanks. > > > ouple of things: > > 1) How do I extend this to work for more than just systems? i would > like > to see this on many objects. > 2) How do I set up all objects (in an org mind you) to add an > attribute > on each object. For example, In my org I would like all systems to > have > the AssetTag and Project fields. Then, whoever is defining a system > will > see these fields. As a bonus, can I give them a type and some type of > regex to validate? I think these two problems could be solved with the same design. Make the attributes table generic and give any object you want to "Factify" and add a foreign key to that table. Then, you can create arbitrary rules for fact summation. For example, a system's facts are the union of the system + the org + the environment Or something like that > 3) can I gemify this to share it with aeolus? IMO this design (as it is now) is not easily exportable to other projects since its basically a single AR model and some FKs -- Jordan O'Mara Red Hat Engineering, Raleigh From msuchy at redhat.com Thu Aug 16 08:27:27 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Thu, 16 Aug 2012 10:27:27 +0200 Subject: [katello-devel] Custom Attributes for a System In-Reply-To: <1050230022.14552671.1345063357389.JavaMail.root@redhat.com> References: <1050230022.14552671.1345063357389.JavaMail.root@redhat.com> Message-ID: <502CAEEF.5030105@redhat.com> On 08/15/2012 10:42 PM, Adam Price wrote: > after looking at the email thread about key-value pairs for a system, i put together a small design doc outlining what this change entails. please look it over and make some comments. > > https://fedorahosted.org/katello/wiki/SystemsCustomAttributesDesign > > Brno guys, please specifically look over the cli portion. i want to make sure we stay with the same command-style (naming, etc) as the rest of the cli. thanks. > Pair (system_id, attr_key) will be unique? I would suggest to not be unique. I can image having attr_key: people_having_access: msuchy people_having_access: aprice It will not mean change in WebUI, but in CLI we would have to extend to: katello system_attribute delete --system-name="dudley" --name="cube number" --value="Chuck Norris" While: katello system_attribute delete --system-name="dudley" --name="cube number" would ask if proceed if deleting more then one row unless --force is present on command line. Add: katello system_attribute update --system-name="dudley" --name="user" --old-value="Bruce Lee" --new-value="Chuck Norris" And this command: katello system_attribute update --system-name="dudley" --name="user" --new-value="Chuck Norris" will refuse to continue if there is more then one attr_key "user" for "dudley". -- Miroslav Suchy Red Hat Systems Management Engineering From inecas at redhat.com Thu Aug 16 08:34:48 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 16 Aug 2012 10:34:48 +0200 Subject: [katello-devel] Custom Attributes for a System In-Reply-To: <1050230022.14552671.1345063357389.JavaMail.root@redhat.com> References: <1050230022.14552671.1345063357389.JavaMail.root@redhat.com> Message-ID: <502CB0A8.9090300@redhat.com> On 08/15/2012 10:42 PM, Adam Price wrote: > after looking at the email thread about key-value pairs for a system, i put together a small design doc outlining what this change entails. please look it over and make some comments. > > https://fedorahosted.org/katello/wiki/SystemsCustomAttributesDesign > > Brno guys, please specifically look over the cli portion. i want to make sure we stay with the same command-style (naming, etc) as the rest of the cli. thanks. > Maybe having that under `katello system update` action is more expected. At least that's where I would search for that. We already have this pattern there: katello template update --add-parameter param-name --value param-value katello template update --remove-parameter param-name --value param-value -- Ivan From sghai at redhat.com Thu Aug 16 08:36:21 2012 From: sghai at redhat.com (Sachin Ghai) Date: Thu, 16 Aug 2012 14:06:21 +0530 Subject: [katello-devel] moving of systems between environments In-Reply-To: <502AEEDB.3070709@redhat.com> References: <502A4AFD.9060700@redhat.com> <20120814142519.GO2850@lzapx.brq.redhat.com> <502AEEDB.3070709@redhat.com> Message-ID: <502CB105.60106@redhat.com> On 08/15/2012 06:05 AM, Mike McCune wrote: > On 08/14/2012 07:25 AM, Lukas Zapletal wrote: >> On Tue, Aug 14, 2012 at 01:56:29PM +0100, Dmitri Dolguikh wrote: >>> Hey all, >>> >>> the above functionality is in master as of yesterday. >>> >>> To move the system using web ui: on system detail screen, change the >>> environment name to the one you intend to move the system to. Once >>> completed, the system will reside in the new environment. >>> To move the system via cli: katello system update --org=Blah >>> --name=My_system --new_environment= >>> >>> To verify that the system has been moved successfully: pull >>> entitlement certificate and verify that the content urls have been >>> updated to use the new environment. Please note that if the content >>> that the system has been subscribed to is not available in the new >>> environment, the entitlement certificate is not going to have it >>> either. >>> >> >> Great. And how does a real-world scenario look like? I mean, does rhsm >> automatically pull entitlement certs every X hours? Or do I need to take >> some explicit action on the client? >> >> > > I would imagine a 'subscription-manager refresh' would do it... that > said, I tried out the above with an install of the latest from git. Some > notes: > > * The webUI worked fine, the system shows up in the next environment I > moved it to > > * Tried a 'subscription-manager refresh' and took a look at the > redhat.repos file and it still pointed at /dev/ but I had moved the > system to test > > * tried 'yum repolist', same thing I observed same behaviour. Since I moved the system from 'test' to 'dev' env, the redhat.repo was still showing the 'test' in URL. Content URLs in entitlement cert also points to 'test' env instead of dev. Logs are here: http://pastebin.test.redhat.com/102204 Regards, -Sachin From dmitri at redhat.com Thu Aug 16 08:37:06 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 16 Aug 2012 09:37:06 +0100 Subject: [katello-devel] Custom Attributes for a System In-Reply-To: <261375271.5565550.1345089592479.JavaMail.root@redhat.com> References: <261375271.5565550.1345089592479.JavaMail.root@redhat.com> Message-ID: <502CB132.7090804@redhat.com> On 16/08/12 04:59 AM, Jordan O'Mara wrote: > > ----- Original Message ----- >> On 08/15/2012 04:42 PM, Adam Price wrote: >>> after looking at the email thread about key-value pairs for a >>> system, i put together a small design doc outlining what this >>> change entails. please look it over and make some comments. >>> >>> https://fedorahosted.org/katello/wiki/SystemsCustomAttributesDesign >>> >>> Brno guys, please specifically look over the cli portion. i want to >>> make sure we stay with the same command-style (naming, etc) as the >>> rest of the cli. thanks. >>> >> ouple of things: >> >> 1) How do I extend this to work for more than just systems? i would >> like >> to see this on many objects. >> 2) How do I set up all objects (in an org mind you) to add an >> attribute >> on each object. For example, In my org I would like all systems to >> have >> the AssetTag and Project fields. Then, whoever is defining a system >> will >> see these fields. As a bonus, can I give them a type and some type of >> regex to validate? > I think these two problems could be solved with the same design. Make the attributes table generic > and give any object you want to "Factify" and add a foreign key to that table. +1, but I think we need an additional table to constrain what custom attributes are available on what object. > > Then, you can create arbitrary rules for fact summation. For example, a system's facts are the union of > > the system + the org + the environment > > Or something like that > >> 3) can I gemify this to share it with aeolus? > IMO this design (as it is now) is not easily exportable to other projects since its basically a single AR model and some FKs I think it's doable - there are rails plugins that extend project schema. Tom - did you figure out what retrieval/addition/removal of key-values is going to look like from API perspective? -d From inecas at redhat.com Thu Aug 16 08:38:54 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 16 Aug 2012 10:38:54 +0200 Subject: [katello-devel] katello-dev-box proposal Message-ID: <502CB19E.7060306@redhat.com> Hi, Interesting news yesterday: Rails team published a "rails-dev-box", which basically provides you a way how to get a VM and turn it into development environment for Rails so that you can start contributing to it really quickly. For me, there is a message behind this: rvm, rbenv or bundler are not the ultimate tools for Ruby development and if it's not just a simple library without dependencies, you need something more. And this is case for Katello as well. I don't see a reason why this couldn't be the preferred way to get an environment ready for Katello development. We already have the setup automated enough, we just need to talk about it more loudly. What would we do: 1. create a Vagrant image to have Fedora/CentOS with preinstalled Katello dependencies from RPMs + yum update from nightly builds to always have the latest/greatest 2. tune our puppet modules to run on that after first start + make custom development config to use git source repo 3. publish it, blog about it 4. party :) What it brings: 1. one OS agnostic command to have everything up and running for development 2. don't pollute you host OS with Katello dependencies, make it easier to start over again, if something goes wrong 3. provide the supported stack for development 4. using our katello-configure Puppet modules in development = continuous improvement for the Puppet modules But what if I want to use the tools (editor, IDE) from my host machine? - you can set up sshfs to the virtual machine But what if I desperately want to run Rails server on my host machine - nobody can stop you, the Gemfile lock is already there, with the versions that are used in the supported stack, you need to do some additional steps, but nothing is for free - you still have all the other dependencies encapsulated in the VM But Ruby developers are used just to run `bundle install` and go: - no, Ruby developers are used to get up and running quickly - there is no way pure bundler will ever help you to get Katello for development up and running. Period. - having just Ruby dependencies isn't enough for development: green unit tests don't mean your code really works, it's just a hint you are on a good way What do you think? I'm using this approach for my devel setup and it makes the world much better place. -- Ivan From dmitri at redhat.com Thu Aug 16 08:44:45 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 16 Aug 2012 09:44:45 +0100 Subject: [katello-devel] katello-dev-box proposal In-Reply-To: <502CB19E.7060306@redhat.com> References: <502CB19E.7060306@redhat.com> Message-ID: <502CB2FD.1030300@redhat.com> On 16/08/12 09:38 AM, Ivan Ne?as wrote: > Hi, > > Interesting news yesterday: Rails team published a "rails-dev-box", > which basically provides you a way how to get a VM and turn it into > development environment for Rails so that you can start contributing > to it really quickly. For me, there is a message behind this: rvm, > rbenv or bundler are not the ultimate tools for Ruby development and > if it's not just a simple library without dependencies, you need > something more. And this is case for Katello as well. > > I don't see a reason why this couldn't be the preferred way to get an > environment ready for Katello development. We already have the setup > automated enough, we just need to talk about it more loudly. > > What would we do: > > 1. create a Vagrant image to have Fedora/CentOS with preinstalled > Katello dependencies from RPMs + yum update from nightly builds to > always have the latest/greatest > 2. tune our puppet modules to run on that after first start + make > custom development config to use git source repo > 3. publish it, blog about it > 4. party :) > > What it brings: > > 1. one OS agnostic command to have everything up and running for > development > 2. don't pollute you host OS with Katello dependencies, make it easier > to start over again, if something goes wrong > 3. provide the supported stack for development > 4. using our katello-configure Puppet modules in development = > continuous improvement for the Puppet modules > > But what if I want to use the tools (editor, IDE) from my host machine? > > - you can set up sshfs to the virtual machine > > But what if I desperately want to run Rails server on my host machine > > - nobody can stop you, the Gemfile lock is already there, with the > versions that are used in the supported stack, you need to do some > additional steps, but nothing is for free > - you still have all the other dependencies encapsulated in the VM > > But Ruby developers are used just to run `bundle install` and go: > > - no, Ruby developers are used to get up and running quickly > - there is no way pure bundler will ever help you to get Katello for > development up and running. Period. > - having just Ruby dependencies isn't enough for development: green > unit tests don't mean your code really works, it's just a hint you are > on a good way > No, it means you have problems with your tests and/or code coverage. -d > What do you think? I'm using this approach for my devel setup and it > makes the world much better place. > From inecas at redhat.com Thu Aug 16 08:58:22 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Thu, 16 Aug 2012 10:58:22 +0200 Subject: [katello-devel] katello-dev-box proposal In-Reply-To: <502CB2FD.1030300@redhat.com> References: <502CB19E.7060306@redhat.com> <502CB2FD.1030300@redhat.com> Message-ID: <502CB62E.5020908@redhat.com> On 08/16/2012 10:44 AM, Dmitri Dolguikh wrote: > On 16/08/12 09:38 AM, Ivan Ne?as wrote: >> >> > No, it means you have problems with your tests and/or code coverage. > -d How unit tests solve this scenario: 1. you have separate unit tests for CLI and API, all green 2. you decide to improve the API, make unit tests green again (forget about CLI, because green tests is what you care about) result: green tests and broken code, green tests =! working code. And I don't think "my tests are green" is valid reason to close any bugzilla. So you have 2 options: spent the rest of your life writing unit tests to simulate all the possible scenarios. Or you run all the code (with all the other moving parts) and test against it. -- Ivan From dmitri at redhat.com Thu Aug 16 09:35:10 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 16 Aug 2012 10:35:10 +0100 Subject: [katello-devel] katello-dev-box proposal In-Reply-To: <502CB62E.5020908@redhat.com> References: <502CB19E.7060306@redhat.com> <502CB2FD.1030300@redhat.com> <502CB62E.5020908@redhat.com> Message-ID: <502CBECE.6020102@redhat.com> On 16/08/12 09:58 AM, Ivan Ne?as wrote: > On 08/16/2012 10:44 AM, Dmitri Dolguikh wrote: >> On 16/08/12 09:38 AM, Ivan Ne?as wrote: >>> >>> >> No, it means you have problems with your tests and/or code coverage. >> -d > How unit tests solve this scenario: > > 1. you have separate unit tests for CLI and API, all green > 2. you decide to improve the API, make unit tests green again (forget > about CLI, because green tests is what you care about) > > result: green tests and broken code, green tests =! working code. > > And I don't think "my tests are green" is valid reason to close any > bugzilla. > > So you have 2 options: spent the rest of your life writing unit tests > to simulate all the possible scenarios. Or you run all the code (with > all the other moving parts) and test against it. > I never said anything about detecting changes in sub-components of the system. That is not the purpose of unit- (developer-) tests. You need a set of tests periodically exercising integration points that a given component relies on. Unit tests cover the rest. -d From hbrock at redhat.com Thu Aug 16 11:50:17 2012 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 16 Aug 2012 07:50:17 -0400 Subject: [katello-devel] New call Justin added to AR In-Reply-To: <1733269792.6304759.1345071916985.JavaMail.root@redhat.com> References: <691057316.6303758.1345071592115.JavaMail.root@redhat.com> <1733269792.6304759.1345071916985.JavaMail.root@redhat.com> Message-ID: <20120816115017.GR9380@redhat.com> On Wed, Aug 15, 2012 at 07:05:16PM -0400, Partha Aji wrote: > > Many may not know this, so just highlighting a new call Just Sherrill added to katello master. Its called "pluck" > > Often we just need one attribute of an AR object, for example if we just need the list of ids of environments or pulp_ids of a Repository, we'd write something like this > > KTEnvironment.select(:id).where(<...>).collect {|env| env.id} > Repository.select(:id).where(<...>).collect {|r| r.pulp_id} > > One common mistake here is people forget to add the "select" so you end up loading all columns even though you just need id or pulp_id > > With Justin's magic method (which is in newer versions of AR. He back ported it) one can now do > > KTEnvironment.where(<...>).pluck(:id) > Repository.where(<...>).pluck(:pulp_id) > > This magic method makes sure you are only selecting what you need. When are we moving the whole shooting match to 3.2, again? --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 sghai at redhat.com Thu Aug 16 12:50:07 2012 From: sghai at redhat.com (Sachin Ghai) Date: Thu, 16 Aug 2012 18:20:07 +0530 Subject: [katello-devel] moving of systems between environments In-Reply-To: <502CB105.60106@redhat.com> References: <502A4AFD.9060700@redhat.com> <20120814142519.GO2850@lzapx.brq.redhat.com> <502AEEDB.3070709@redhat.com> <502CB105.60106@redhat.com> Message-ID: <502CEC7F.3010206@redhat.com> On 08/16/2012 02:06 PM, Sachin Ghai wrote: > > > On 08/15/2012 06:05 AM, Mike McCune wrote: >> On 08/14/2012 07:25 AM, Lukas Zapletal wrote: >>> On Tue, Aug 14, 2012 at 01:56:29PM +0100, Dmitri Dolguikh wrote: >>>> Hey all, >>>> >>>> the above functionality is in master as of yesterday. >>>> >>>> To move the system using web ui: on system detail screen, change the >>>> environment name to the one you intend to move the system to. Once >>>> completed, the system will reside in the new environment. >>>> To move the system via cli: katello system update --org=Blah >>>> --name=My_system --new_environment= >>>> >>>> To verify that the system has been moved successfully: pull >>>> entitlement certificate and verify that the content urls have been >>>> updated to use the new environment. Please note that if the content >>>> that the system has been subscribed to is not available in the new >>>> environment, the entitlement certificate is not going to have it >>>> either. >>>> >>> >>> Great. And how does a real-world scenario look like? I mean, does rhsm >>> automatically pull entitlement certs every X hours? Or do I need to take >>> some explicit action on the client? >>> >>> >> >> I would imagine a 'subscription-manager refresh' would do it... that >> said, I tried out the above with an install of the latest from git. Some >> notes: >> >> * The webUI worked fine, the system shows up in the next environment I >> moved it to >> >> * Tried a 'subscription-manager refresh' and took a look at the >> redhat.repos file and it still pointed at /dev/ but I had moved the >> system to test >> >> * tried 'yum repolist', same thing > > I observed same behaviour. Since I moved the system from 'test' to 'dev' > env, the redhat.repo was still showing the 'test' in URL. > > Content URLs in entitlement cert also points to 'test' env instead of > dev. Logs are here: > http://pastebin.test.redhat.com/102204 > The candlepin version installed on katello server is: candlepin-0.5.32-1.el6.noarch Regards. -Sachin From bkearney at redhat.com Thu Aug 16 13:10:19 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 16 Aug 2012 09:10:19 -0400 Subject: [katello-devel] Custom Attributes for a System In-Reply-To: <502CB132.7090804@redhat.com> References: <261375271.5565550.1345089592479.JavaMail.root@redhat.com> <502CB132.7090804@redhat.com> Message-ID: <502CF13B.1050800@redhat.com> On 08/16/2012 04:37 AM, Dmitri Dolguikh wrote: > On 16/08/12 04:59 AM, Jordan O'Mara wrote: >> >> ----- Original Message ----- >>> On 08/15/2012 04:42 PM, Adam Price wrote: >>>> after looking at the email thread about key-value pairs for a >>>> system, i put together a small design doc outlining what this >>>> change entails. please look it over and make some comments. >>>> >>>> https://fedorahosted.org/katello/wiki/SystemsCustomAttributesDesign >>>> >>>> Brno guys, please specifically look over the cli portion. i want to >>>> make sure we stay with the same command-style (naming, etc) as the >>>> rest of the cli. thanks. >>>> >>> ouple of things: >>> >>> 1) How do I extend this to work for more than just systems? i would >>> like >>> to see this on many objects. >>> 2) How do I set up all objects (in an org mind you) to add an >>> attribute >>> on each object. For example, In my org I would like all systems to >>> have >>> the AssetTag and Project fields. Then, whoever is defining a system >>> will >>> see these fields. As a bonus, can I give them a type and some type of >>> regex to validate? >> I think these two problems could be solved with the same design. Make >> the attributes table generic >> and give any object you want to "Factify" and add a foreign key to >> that table. > +1, but I think we need an additional table to constrain what custom > attributes are available on what object. >> >> Then, you can create arbitrary rules for fact summation. For example, >> a system's facts are the union of >> >> the system + the org + the environment >> >> Or something like that >> >>> 3) can I gemify this to share it with aeolus? >> IMO this design (as it is now) is not easily exportable to other >> projects since its basically a single AR model and some FKs > I think it's doable - there are rails plugins that extend project > schema. Tom - did you figure out what retrieval/addition/removal of > key-values is going to look like from API perspective? > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Lets rework based on the comments here and send out again. -- bk From dmitri at redhat.com Thu Aug 16 13:26:11 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 16 Aug 2012 14:26:11 +0100 Subject: [katello-devel] moving of systems between environments In-Reply-To: <502CEC7F.3010206@redhat.com> References: <502A4AFD.9060700@redhat.com> <20120814142519.GO2850@lzapx.brq.redhat.com> <502AEEDB.3070709@redhat.com> <502CB105.60106@redhat.com> <502CEC7F.3010206@redhat.com> Message-ID: <502CF4F3.8020105@redhat.com> On 16/08/12 01:50 PM, Sachin Ghai wrote: > > > On 08/16/2012 02:06 PM, Sachin Ghai wrote: >> >> >> On 08/15/2012 06:05 AM, Mike McCune wrote: >>> On 08/14/2012 07:25 AM, Lukas Zapletal wrote: >>>> On Tue, Aug 14, 2012 at 01:56:29PM +0100, Dmitri Dolguikh wrote: >>>>> Hey all, >>>>> >>>>> the above functionality is in master as of yesterday. >>>>> >>>>> To move the system using web ui: on system detail screen, change the >>>>> environment name to the one you intend to move the system to. Once >>>>> completed, the system will reside in the new environment. >>>>> To move the system via cli: katello system update --org=Blah >>>>> --name=My_system --new_environment= >>>>> >>>>> To verify that the system has been moved successfully: pull >>>>> entitlement certificate and verify that the content urls have been >>>>> updated to use the new environment. Please note that if the content >>>>> that the system has been subscribed to is not available in the new >>>>> environment, the entitlement certificate is not going to have it >>>>> either. >>>>> >>>> >>>> Great. And how does a real-world scenario look like? I mean, does rhsm >>>> automatically pull entitlement certs every X hours? Or do I need to >>>> take >>>> some explicit action on the client? >>>> >>>> >>> >>> I would imagine a 'subscription-manager refresh' would do it... that >>> said, I tried out the above with an install of the latest from git. >>> Some >>> notes: >>> >>> * The webUI worked fine, the system shows up in the next environment I >>> moved it to >>> >>> * Tried a 'subscription-manager refresh' and took a look at the >>> redhat.repos file and it still pointed at /dev/ but I had moved the >>> system to test >>> >>> * tried 'yum repolist', same thing >> >> I observed same behaviour. Since I moved the system from 'test' to 'dev' >> env, the redhat.repo was still showing the 'test' in URL. >> >> Content URLs in entitlement cert also points to 'test' env instead of >> dev. Logs are here: >> http://pastebin.test.redhat.com/102204 >> > > The candlepin version installed on katello server is: > > candlepin-0.5.32-1.el6.noarch 0.5.32-1 was tagged on May 3rd - candlepin changes required to support moving of systems were in master on June 6th. Not sure what you can do about this short of installing later candlepin release by hand... -d > > Regards. > -Sachin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Thu Aug 16 21:39:36 2012 From: mmccune at redhat.com (Mike McCune) Date: Thu, 16 Aug 2012 14:39:36 -0700 Subject: [katello-devel] Deleting old yum repo location Message-ID: <502D6898.9010904@redhat.com> Now that we have switched to the new koji based infrastructure and the fedorahosted groups storage location I'm deleting this set of repositories to reduce confusion: http://repos.fedorapeople.org/repos/katello/ everything RPM should now be found at: http://fedorapeople.org/groups/katello/ Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From vvaldez at redhat.com Thu Aug 16 22:28:05 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Thu, 16 Aug 2012 17:28:05 -0500 Subject: [katello-devel] Error syncing Fedora 16 In-Reply-To: References: <5470F238-544D-4409-AC43-0FD2307B88BF@redhat.com> <502C18CF.9090907@redhat.com> Message-ID: <1C338F07-0719-4230-910B-BEB1CBA8E319@redhat.com> I duplicated this in a lab pointing to a known good repo, with no updates on any packages. As soon as I start the sync, I get these errors: 2012-08-16 21:58:17,715 31245:139849537402624: grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, read md5sum of: 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b 2012-08-16 21:58:17,740 31245:139849537402624: grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, read md5sum of: 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b 2012-08-16 21:58:17,748 31245:139849537402624: grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, read md5sum of: 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b 2012-08-16 21:58:17,760 31245:139849537402624: grinder.BaseFetch:WARNING: activeobject:162 ERROR: Response = 404 fetching http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso. I also tried directly with grinder and get this error: grinder yum --label=test1 --url=http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os/ grinder.ProgressTracker: WARNING http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/efidisk.img changing tracker for tree_file total_size_bytes from 140755203 to 281549059 grinder.BaseFetch: ERROR boot.iso md5sum mismatch, read md5sum of: 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b grinder.BaseFetch: WARNING Retrying fetch of: boot.iso with 0 retry attempts left. HTTP status was 404 grinder.BaseFetch: INFO Cleanup ./test1/images/boot.iso grinder.ProgressTracker: WARNING Resetting progress for grinder.BaseFetch: INFO Fetching Unknown bytes: boot.iso from http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso grinder.BaseFetch: ERROR boot.iso md5sum mismatch, read md5sum of: 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b grinder.BaseFetch: INFO Cleanup ./test1/images/boot.iso grinder.BaseFetch: WARNING ERROR: Response = 404 fetching http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso. I'll try building a system even with the repo in this state. Vinny On Aug 15, 2012, at 5:49 PM, Vinny Valdez wrote: > My mistake, the error is actually as follows: > 2012-08-15 22:33:59,275 2436:139770315405056: grinder.ProgressTracker:WARNING: ProgressTracker:141 http://files.example. > com/pub/installers/fedora/16/x86_64/os//images/boot.iso changing tracker for tree_file total_size_bytes from 0 to 332 > 2012-08-15 22:33:59,278 2436:139770315405056: grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, read md5sum of: 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > 2012-08-15 22:33:59,279 2436:139770315405056: grinder.BaseFetch:WARNING: activeobject:162 Retrying fetch of: boot.iso with 1 retry attempts left. HTTP status was 404 > 2012-08-15 22:33:59,279 2436:139770315405056: grinder.BaseFetch:INFO: activeobject:162 Cleanup /var/lib/pulp/distributions/ks-Fedora-Fedora-16-x86_64/boot.iso > 2012-08-15 22:33:59,279 2436:139770315405056: grinder.ProgressTracker:WARNING: ProgressTracker:258 Resetting progress for > 2012-08-15 22:33:59,283 2436:139770315405056: grinder.BaseFetch:INFO: activeobject:162 Fetching Unknown bytes: boot.iso from http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso > 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, read md5sum of: 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:WARNING: activeobject:162 Retrying fetch of: boot.iso with 0 retry attempts left. HTTP status was 404 > 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:INFO: activeobject:162 Cleanup /var/lib/pulp/distributions/ks-Fedora-Fedora-16-x86_64/boot.iso > 2012-08-15 22:33:59,285 2436:139770315405056: grinder.ProgressTracker:WARNING: ProgressTracker:258 Resetting progress for > 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:INFO: activeobject:162 Fetching Unknown bytes: boot.iso from http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso > 2012-08-15 22:33:59,287 2436:139770315405056: grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, read md5sum of: 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c expected md5sum of a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > > When I first hit this error, I thought I needed to update as a gut reaction troubleshooting step, I did so then ran into the updated pymongo issue, and incorrectly pasted that as the culprit. scollier also gets the same error in his environment. > > Vinny > > On Aug 15, 2012, at 4:46 PM, Todd Sanders wrote: > >> Probably the version of pymongo....see: https://fedorahosted.org/pulp/wiki/UGFAQ#rpmname >> >> -Todd >> >> On 08/15/2012 05:22 PM, Vinny Valdez wrote: >>> I setup katello on Fedora 16 and tried to sync Fedora 16 from a repo created from a gold ISO. I get the following error: >>> >>> 2012-08-15 20:30:01,845 3359:140003283810048: pulp.server.tasking.task:ERROR: task:472 Task failed: Task 261f4dcf-e740-11e1-b495-525400360b28: _sync(Example-Fedora16-fedora16-x86_64, synchronizer=, skip={}, max_speed=None, threads=4, progress_callback=>) >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/pulp/server/tasking/task.py", line 418, in run >>> result = self.callable(*self.args, **self.kwargs) >>> File "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", line 283, in _sync >>> progress_callback, synchronizer, max_speed, threads) >>> File "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", line 379, in fetch_content >>> added_errataids = synchronizer.import_metadata(repo_dir, repo_id, skip_dict) >>> File "/usr/lib/python2.7/site-packages/pulp/server/api/synchronizers.py", line 415, in import_metadata >>> self.repo_api.collection.save(repo, safe=True) >>> File "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", line 80, in retry >>> return method(*args, **kwargs) >>> File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line 237, in save >>> manipulate, safe, _check_keys=True, **kwargs) >>> File "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", line 80, in retry >>> return method(*args, **kwargs) >>> File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line 411, in update >>> _check_keys, self.__uuid_subtype), safe) >>> InvalidDocument: key 'openoffice.org-voikko' must not contain '.' >>> >>> Is there anything I am doing wrong here? >>> >>> katello-1.0.4-1.fc16.noarch >>> katello-cli-common-1.0.1-1.fc16.noarch >>> katello-configure-1.0.1-1.fc16.noarch >>> katello-common-1.0.4-1.fc16.noarch >>> katello-qpid-broker-key-pair-1.0-1.noarch >>> katello-glue-foreman-1.0.4-1.fc16.noarch >>> katello-all-1.0.4-1.fc16.noarch >>> katello-certs-tools-1.1.7-1.fc16.noarch >>> katello-qpid-client-key-pair-1.0-1.noarch >>> katello-repos-1.0.3-1.fc16.noarch >>> katello-glue-candlepin-1.0.4-1.fc16.noarch >>> katello-cli-1.0.1-1.fc16.noarch >>> katello-glue-pulp-1.0.4-1.fc16.noarch >>> katello-candlepin-cert-key-pair-1.0-1.noarch >>> katello-selinux-1.0.1-1.fc16.noarch >>> pulp-common-1.1.11-1.fc16.noarch >>> pulp-selinux-server-1.1.11-1.fc16.noarch >>> pulp-1.1.11-1.fc16.noarch >>> candlepin-0.7.4.2-1.fc16.noarch >>> candlepin-tomcat6-0.7.4.2-1.fc16.noarch >>> qpid-cpp-server-0.16-3.1.fc16.x86_64 >>> qpid-cpp-client-0.16-3.1.fc16.x86_64 >>> qpid-cpp-server-ssl-0.16-3.1.fc16.x86_64 >>> qpid-cpp-client-ssl-0.16-3.1.fc16.x86_64 >>> >>> Regards, >>> >>> Vinny >>> >>> >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmccune at redhat.com Thu Aug 16 23:55:23 2012 From: mmccune at redhat.com (Mike McCune) Date: Thu, 16 Aug 2012 16:55:23 -0700 Subject: [katello-devel] moving of systems between environments In-Reply-To: <502CF4F3.8020105@redhat.com> References: <502A4AFD.9060700@redhat.com> <20120814142519.GO2850@lzapx.brq.redhat.com> <502AEEDB.3070709@redhat.com> <502CB105.60106@redhat.com> <502CEC7F.3010206@redhat.com> <502CF4F3.8020105@redhat.com> Message-ID: <502D886B.1060206@redhat.com> On 08/16/2012 06:26 AM, Dmitri Dolguikh wrote: > On 16/08/12 01:50 PM, Sachin Ghai wrote: >> >> >> On 08/16/2012 02:06 PM, Sachin Ghai wrote: >>> >>> >>> On 08/15/2012 06:05 AM, Mike McCune wrote: >>>> On 08/14/2012 07:25 AM, Lukas Zapletal wrote: >>>>> On Tue, Aug 14, 2012 at 01:56:29PM +0100, Dmitri Dolguikh wrote: >>>>>> Hey all, >>>>>> >>>>>> the above functionality is in master as of yesterday. >>>>>> >>>>>> To move the system using web ui: on system detail screen, change the >>>>>> environment name to the one you intend to move the system to. Once >>>>>> completed, the system will reside in the new environment. >>>>>> To move the system via cli: katello system update --org=Blah >>>>>> --name=My_system --new_environment= >>>>>> >>>>>> To verify that the system has been moved successfully: pull >>>>>> entitlement certificate and verify that the content urls have been >>>>>> updated to use the new environment. Please note that if the content >>>>>> that the system has been subscribed to is not available in the new >>>>>> environment, the entitlement certificate is not going to have it >>>>>> either. >>>>>> >>>>> >>>>> Great. And how does a real-world scenario look like? I mean, does rhsm >>>>> automatically pull entitlement certs every X hours? Or do I need to >>>>> take >>>>> some explicit action on the client? >>>>> >>>>> >>>> >>>> I would imagine a 'subscription-manager refresh' would do it... that >>>> said, I tried out the above with an install of the latest from git. >>>> Some >>>> notes: >>>> >>>> * The webUI worked fine, the system shows up in the next environment I >>>> moved it to >>>> >>>> * Tried a 'subscription-manager refresh' and took a look at the >>>> redhat.repos file and it still pointed at /dev/ but I had moved the >>>> system to test >>>> >>>> * tried 'yum repolist', same thing >>> >>> I observed same behaviour. Since I moved the system from 'test' to 'dev' >>> env, the redhat.repo was still showing the 'test' in URL. >>> >>> Content URLs in entitlement cert also points to 'test' env instead of >>> dev. Logs are here: >>> http://pastebin.test.redhat.com/102204 >>> >> >> The candlepin version installed on katello server is: >> >> candlepin-0.5.32-1.el6.noarch > 0.5.32-1 was tagged on May 3rd - candlepin changes required to support > moving of systems were in master on June 6th. Not sure what you can do > about this short of installing later candlepin release by hand... > works great as you say ... my only feedback would be to say perhaps a bit extra in the messaging when you move the environment: "This system's environment has been updated. Next time it checks in with the Katello server it will point at the environment and content will be available." something like that. Nice work thou! Mike From jmatthew at redhat.com Fri Aug 17 00:02:31 2012 From: jmatthew at redhat.com (John Matthews) Date: Thu, 16 Aug 2012 20:02:31 -0400 (EDT) Subject: [katello-devel] Error syncing Fedora 16 In-Reply-To: <1C338F07-0719-4230-910B-BEB1CBA8E319@redhat.com> Message-ID: <126086150.47692747.1345161751135.JavaMail.root@redhat.com> Vinny, This looks like a problem on the remote repo. The remote repo has a metadata file called ".treeinfo". ".treeinfo" specifies a file "images/boot.iso", yet "images/boot.iso" does not exist on the repo. When I try to fetch "images/boot.iso" I get a 404. http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso ".treeinfo" is here: http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os/.treeinfo [general] family = Fedora timestamp = 1320289812.31 variant = Fedora version = 16 packagedir = arch = x86_64 [images-x86_64] kernel = images/pxeboot/vmlinuz initrd = images/pxeboot/initrd.img boot.iso = images/boot.iso [images-xen] kernel = images/pxeboot/vmlinuz initrd = images/pxeboot/initrd.img [checksums] images/efidisk.img = sha256:fa168ed2bbd556606a0dcfef7ff531f3181f67546a4a148210d211cc129fd572 images/boot.iso = sha256:a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b images/efiboot.img = sha256:ec7ad37b2cd09ecadbbaa0a51b60c5909712c2303f0529578a5045758d5e6e04 images/pxeboot/initrd.img = sha256:60fd924a0684fc623c25d53395f41d752c37b68fc53596c04cfe3e9b057c1fc2 images/pxeboot/vmlinuz = sha256:82ee5b351a875dc7b646f78e4aad9cf697eb3c85784b0f82134fe0e907202171 repodata/repomd.xml = sha256:441f0cdbaa66d8742fb4d3399efb5b2a25998f49a718f41665a1e116d0bffff8 ----- Original Message ----- > > > I duplicated this in a lab pointing to a known good repo, with no > updates on any packages. As soon as I start the sync, I get these > errors: > > > > 2012-08-16 21:58:17,715 31245:139849537402624: > grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, > read md5sum of: > 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec > expected md5sum of > a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > 2012-08-16 21:58:17,740 31245:139849537402624: > grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, > read md5sum of: > 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec > expected md5sum of > a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > 2012-08-16 21:58:17,748 31245:139849537402624: > grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, > read md5sum of: > 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec > expected md5sum of > a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > 2012-08-16 21:58:17,760 31245:139849537402624: > grinder.BaseFetch:WARNING: activeobject:162 ERROR: Response = 404 > fetching > http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso > . > > > I also tried directly with grinder and get this error: > > > grinder yum --label=test1 --url= > http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os/ > > grinder.ProgressTracker: WARNING > http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/efidisk.img > changing tracker for tree_file total_size_bytes from 140755203 to > 281549059 > grinder.BaseFetch: ERROR boot.iso md5sum mismatch, read md5sum of: > 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec > expected md5sum of > a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > grinder.BaseFetch: WARNING Retrying fetch of: boot.iso with 0 retry > attempts left. HTTP status was 404 > grinder.BaseFetch: INFO Cleanup ./test1/images/boot.iso > grinder.ProgressTracker: WARNING Resetting progress for < > http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso > > > grinder.BaseFetch: INFO Fetching Unknown bytes: boot.iso from > http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso > grinder.BaseFetch: ERROR boot.iso md5sum mismatch, read md5sum of: > 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec > expected md5sum of > a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > grinder.BaseFetch: INFO Cleanup ./test1/images/boot.iso > grinder.BaseFetch: WARNING ERROR: Response = 404 fetching > http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso > . > > I'll try building a system even with the repo in this state. > > > > > > > Vinny > > > > On Aug 15, 2012, at 5:49 PM, Vinny Valdez < vvaldez at redhat.com > > wrote: > > > > > My mistake, the error is actually as follows: > > 2012-08-15 22:33:59,275 2436:139770315405056: > grinder.ProgressTracker:WARNING: ProgressTracker:141 > http://files.example . > com/pub/installers/fedora/16/x86_64/os//images/boot.iso changing > tracker for tree_file total_size_bytes from 0 to 332 > 2012-08-15 22:33:59,278 2436:139770315405056: > grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, > read md5sum of: > 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c > expected md5sum of > a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > 2012-08-15 22:33:59,279 2436:139770315405056: > grinder.BaseFetch:WARNING: activeobject:162 Retrying fetch of: > boot.iso with 1 retry attempts left. HTTP status was 404 > 2012-08-15 22:33:59,279 2436:139770315405056: grinder.BaseFetch:INFO: > activeobject:162 Cleanup > /var/lib/pulp/distributions/ks-Fedora-Fedora-16-x86_64/boot.iso > 2012-08-15 22:33:59,279 2436:139770315405056: > grinder.ProgressTracker:WARNING: ProgressTracker:258 Resetting > progress for < > http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso > > > 2012-08-15 22:33:59,283 2436:139770315405056: grinder.BaseFetch:INFO: > activeobject:162 Fetching Unknown bytes: boot.iso from > http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso > 2012-08-15 22:33:59,285 2436:139770315405056: > grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, > read md5sum of: > 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c > expected md5sum of > a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > 2012-08-15 22:33:59,285 2436:139770315405056: > grinder.BaseFetch:WARNING: activeobject:162 Retrying fetch of: > boot.iso with 0 retry attempts left. HTTP status was 404 > 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:INFO: > activeobject:162 Cleanup > /var/lib/pulp/distributions/ks-Fedora-Fedora-16-x86_64/boot.iso > 2012-08-15 22:33:59,285 2436:139770315405056: > grinder.ProgressTracker:WARNING: ProgressTracker:258 Resetting > progress for < > http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso > > > 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:INFO: > activeobject:162 Fetching Unknown bytes: boot.iso from > http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso > 2012-08-15 22:33:59,287 2436:139770315405056: > grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, > read md5sum of: > 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c > expected md5sum of > a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > > > When I first hit this error, I thought I needed to update as a gut > reaction troubleshooting step, I did so then ran into the updated > pymongo issue, and incorrectly pasted that as the culprit. scollier > also gets the same error in his environment. > > > > > Vinny > > > On Aug 15, 2012, at 4:46 PM, Todd Sanders < tsanders at redhat.com > > wrote: > > > > > Probably the version of pymongo....see: > https://fedorahosted.org/pulp/wiki/UGFAQ#rpmname > > -Todd > > On 08/15/2012 05:22 PM, Vinny Valdez wrote: > > > > I setup katello on Fedora 16 and tried to sync Fedora 16 from a repo > created from a gold ISO. I get the following error: > > > > 2012-08-15 20:30:01,845 3359:140003283810048: > pulp.server.tasking.task:ERROR: task:472 Task failed: Task > 261f4dcf-e740-11e1-b495-525400360b28: > _sync(Example-Fedora16-fedora16-x86_64, > synchronizer= at 0x7f554bcc7bd0>, skip={}, max_speed=None, threads=4, > progress_callback= 0x7f554bcc7d90>>) > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/pulp/server/tasking/task.py", > line 418, in run > result = self.callable(*self.args, **self.kwargs) > File "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", > line 283, in _sync > progress_callback, synchronizer, max_speed, threads) > File "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", > line 379, in fetch_content > added_errataids = synchronizer.import_metadata(repo_dir, repo_id, > skip_dict) > File > "/usr/lib/python2.7/site-packages/pulp/server/api/synchronizers.py", > line 415, in import_metadata > self.repo_api.collection.save(repo, safe=True) > File "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", > line 80, in retry > return method(*args, **kwargs) > File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line > 237, in save > manipulate, safe, _check_keys=True, **kwargs) > File "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", > line 80, in retry > return method(*args, **kwargs) > File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line > 411, in update > _check_keys, self.__uuid_subtype), safe) > InvalidDocument: key ' openoffice.org -voikko' must not contain '.' > > > Is there anything I am doing wrong here? > > > > katello-1.0.4-1.fc16.noarch > katello-cli-common-1.0.1-1.fc16.noarch > katello-configure-1.0.1-1.fc16.noarch > katello-common-1.0.4-1.fc16.noarch > katello-qpid-broker-key-pair-1.0-1.noarch > katello-glue-foreman-1.0.4-1.fc16.noarch > katello-all-1.0.4-1.fc16.noarch > katello-certs-tools-1.1.7-1.fc16.noarch > katello-qpid-client-key-pair-1.0-1.noarch > katello-repos-1.0.3-1.fc16.noarch > katello-glue-candlepin-1.0.4-1.fc16.noarch > katello-cli-1.0.1-1.fc16.noarch > katello-glue-pulp-1.0.4-1.fc16.noarch > katello-candlepin-cert-key-pair-1.0-1.noarch > katello-selinux-1.0.1-1.fc16.noarch > > pulp-common-1.1.11-1.fc16.noarch > pulp-selinux-server-1.1.11-1.fc16.noarch > pulp-1.1.11-1.fc16.noarch > > candlepin-0.7.4.2-1.fc16.noarch > candlepin-tomcat6-0.7.4.2-1.fc16.noarch > > qpid-cpp-server-0.16-3.1.fc16.x86_64 > qpid-cpp-client-0.16-3.1.fc16.x86_64 > qpid-cpp-server-ssl-0.16-3.1.fc16.x86_64 > qpid-cpp-client-ssl-0.16-3.1.fc16.x86_64 > > > Regards, > > > > > > > Vinny > > > _______________________________________________ > 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 ehelms at redhat.com Fri Aug 17 12:54:14 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 17 Aug 2012 08:54:14 -0400 (EDT) Subject: [katello-devel] Custom Attributes for a System In-Reply-To: <502CF13B.1050800@redhat.com> Message-ID: <1998330637.10958262.1345208054600.JavaMail.root@redhat.com> 1 question, 1 comment. Could you also add the API design for this? The UI design for it looks comparable to what we have in other places in the app with the exception of the edit button. This could easily be an inline jeditable style interaction for each individual element. - Eric ----- Original Message ----- From: "Bryan Kearney" To: katello-devel at redhat.com Sent: Thursday, August 16, 2012 9:10:19 AM Subject: Re: [katello-devel] Custom Attributes for a System On 08/16/2012 04:37 AM, Dmitri Dolguikh wrote: > On 16/08/12 04:59 AM, Jordan O'Mara wrote: >> >> ----- Original Message ----- >>> On 08/15/2012 04:42 PM, Adam Price wrote: >>>> after looking at the email thread about key-value pairs for a >>>> system, i put together a small design doc outlining what this >>>> change entails. please look it over and make some comments. >>>> >>>> https://fedorahosted.org/katello/wiki/SystemsCustomAttributesDesign >>>> >>>> Brno guys, please specifically look over the cli portion. i want to >>>> make sure we stay with the same command-style (naming, etc) as the >>>> rest of the cli. thanks. >>>> >>> ouple of things: >>> >>> 1) How do I extend this to work for more than just systems? i would >>> like >>> to see this on many objects. >>> 2) How do I set up all objects (in an org mind you) to add an >>> attribute >>> on each object. For example, In my org I would like all systems to >>> have >>> the AssetTag and Project fields. Then, whoever is defining a system >>> will >>> see these fields. As a bonus, can I give them a type and some type of >>> regex to validate? >> I think these two problems could be solved with the same design. Make >> the attributes table generic >> and give any object you want to "Factify" and add a foreign key to >> that table. > +1, but I think we need an additional table to constrain what custom > attributes are available on what object. >> >> Then, you can create arbitrary rules for fact summation. For example, >> a system's facts are the union of >> >> the system + the org + the environment >> >> Or something like that >> >>> 3) can I gemify this to share it with aeolus? >> IMO this design (as it is now) is not easily exportable to other >> projects since its basically a single AR model and some FKs > I think it's doable - there are rails plugins that extend project > schema. Tom - did you figure out what retrieval/addition/removal of > key-values is going to look like from API perspective? > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Lets rework based on the comments here and send out again. -- bk _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From jrist at redhat.com Fri Aug 17 13:28:48 2012 From: jrist at redhat.com (Jason Rist) Date: Fri, 17 Aug 2012 07:28:48 -0600 Subject: [katello-devel] Custom Attributes for a System In-Reply-To: <1998330637.10958262.1345208054600.JavaMail.root@redhat.com> References: <502CF13B.1050800@redhat.com> <1998330637.10958262.1345208054600.JavaMail.root@redhat.com> Message-ID: <502E4710.7080402@redhat.com> On Fri 17 Aug 2012 06:54:14 AM MDT, Eric Helms wrote: > 1 question, 1 comment. > > Could you also add the API design for this? > > The UI design for it looks comparable to what we have in other places in the app with the exception of the edit button. This could easily be an inline jeditable style interaction for each individual element. > > - Eric > > ----- Original Message ----- > From: "Bryan Kearney" > To: katello-devel at redhat.com > Sent: Thursday, August 16, 2012 9:10:19 AM > Subject: Re: [katello-devel] Custom Attributes for a System > > On 08/16/2012 04:37 AM, Dmitri Dolguikh wrote: >> On 16/08/12 04:59 AM, Jordan O'Mara wrote: >>> >>> ----- Original Message ----- >>>> On 08/15/2012 04:42 PM, Adam Price wrote: >>>>> after looking at the email thread about key-value pairs for a >>>>> system, i put together a small design doc outlining what this >>>>> change entails. please look it over and make some comments. >>>>> >>>>> https://fedorahosted.org/katello/wiki/SystemsCustomAttributesDesign >>>>> >>>>> Brno guys, please specifically look over the cli portion. i want to >>>>> make sure we stay with the same command-style (naming, etc) as the >>>>> rest of the cli. thanks. >>>>> >>>> ouple of things: >>>> >>>> 1) How do I extend this to work for more than just systems? i would >>>> like >>>> to see this on many objects. >>>> 2) How do I set up all objects (in an org mind you) to add an >>>> attribute >>>> on each object. For example, In my org I would like all systems to >>>> have >>>> the AssetTag and Project fields. Then, whoever is defining a system >>>> will >>>> see these fields. As a bonus, can I give them a type and some type of >>>> regex to validate? >>> I think these two problems could be solved with the same design. Make >>> the attributes table generic >>> and give any object you want to "Factify" and add a foreign key to >>> that table. >> +1, but I think we need an additional table to constrain what custom >> attributes are available on what object. >>> >>> Then, you can create arbitrary rules for fact summation. For example, >>> a system's facts are the union of >>> >>> the system + the org + the environment >>> >>> Or something like that >>> >>>> 3) can I gemify this to share it with aeolus? >>> IMO this design (as it is now) is not easily exportable to other >>> projects since its basically a single AR model and some FKs >> I think it's doable - there are rails plugins that extend project >> schema. Tom - did you figure out what retrieval/addition/removal of >> key-values is going to look like from API perspective? >> >> -d >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Lets rework based on the comments here and send out again. > > -- bk > +1 to what Eric said re: jeditable. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jrist at redhat.com Fri Aug 17 13:30:42 2012 From: jrist at redhat.com (Jason Rist) Date: Fri, 17 Aug 2012 07:30:42 -0600 Subject: [katello-devel] [katello] Post 1.1 Code "Breakup" Discussion (#450) In-Reply-To: References: Message-ID: <502E4782.9090402@redhat.com> > > You mean Katello design discussions right, not all discussions :-) > > By the way if you are going to present some artifacts (like screens or > UX designs), pull requests are also good option. Github is able to embed > these in there. > Lukas - How does that work, exactly? Not the embedding of images (I get that), but the pull-request-for-design-discussion method. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From ehelms at redhat.com Fri Aug 17 13:35:41 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 17 Aug 2012 09:35:41 -0400 (EDT) Subject: [katello-devel] Direct Pushes to Katello Master Message-ID: <499416694.10971330.1345210541109.JavaMail.root@redhat.com> I have seen what appears to be direct pushes to Katello master in the past week or two which goes against our core requirement that EVERYTHING going to master (minus tags) goes through via a Pull Request. If this policy needs to be amended, then let's amend it instead of going around it or, better yet, if there are things that need to be direct pushed to a repository then perhaps that code needs to be in it's own repository so it can have it's own set of rules. - Eric From msuchy at redhat.com Fri Aug 17 14:06:58 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Fri, 17 Aug 2012 16:06:58 +0200 Subject: [katello-devel] Direct Pushes to Katello Master In-Reply-To: <499416694.10971330.1345210541109.JavaMail.root@redhat.com> References: <499416694.10971330.1345210541109.JavaMail.root@redhat.com> Message-ID: <502E5002.9000101@redhat.com> On 08/17/2012 03:35 PM, Eric Helms wrote: > I have seen what appears to be direct pushes to Katello master in the past week or two which goes against our core requirement that EVERYTHING going to master (minus tags) goes through via a Pull Request. If this policy needs to be amended, then let's amend it instead of going around it or, better yet, if there are things that need to be direct pushed to a repository then perhaps that code needs to be in it's own repository so it can have it's own set of rules. Which *code* went directly? I'm pushing some commits directly, but they are rel-eng related. It is either tagged packages or changes in comps files. -- Miroslav Suchy Red Hat Systems Management Engineering From bkearney at redhat.com Fri Aug 17 14:13:54 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 17 Aug 2012 10:13:54 -0400 Subject: [katello-devel] Renaming of environments: summary, take II In-Reply-To: <502BE065.9050003@redhat.com> References: <502BE065.9050003@redhat.com> Message-ID: <502E51A2.5030208@redhat.com> On 08/15/2012 01:46 PM, Dmitri Dolguikh wrote: > Please see original conversation thread [1], first attempt at summary > [2], and BZ [3] for details. > > The majority of the conversation revolved around use of human-readable > ids to preserve user-friendiness of urls vs. using uuids to preserve > data consistency of client applications that use Katello API. Another > concern expressed was readability of repository urls genereated by > Katello in yum configuration files. It was suggested to use Punycode for > encoding of non-ascii-based labels. > > Proposed changes: > - introduce immutable labels > - replace use of environment name with environment label in urls not > impacting data integrity, such as repository urls. This would eliminate > the need for entitlement certificate regeneration after environment name > changes > - introduce uuids, and replace current use of primary db keys in > resource urls with uuids > > Tasks on Katello side: > - take a look at and implement Punycode > - introduce environment labels: db changes, model changes, controller > changes > - introduce uuids: db changes, model changes, controller changes > - figure out migration for existing Katello installations > > Tasks on Candlepin side: > - add label and uuid fields to model. Replace use of environment names > with environment labels > > > > [1] https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html > [2] https://www.redhat.com/archives/katello-devel/2012-August/msg00144.html > [3] https://bugzilla.redhat.com/show_bug.cgi?id=795928 > [4] http://en.wikipedia.org/wiki/Punycode > so, in katello, if I create an environment called JarJar, a product called Binks, and a repo called IsASuperStar, today I would see this: [jarjar-binks-IsASuperStar] Name: JarJarBinksIsASuperStar baseurl:JarJar/Binks/IsASuperStar What will i see tomorow? - bk From esammons at redhat.com Fri Aug 17 14:19:09 2012 From: esammons at redhat.com (Eric Sammons) Date: Fri, 17 Aug 2012 10:19:09 -0400 (EDT) Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <20120814092915.GF2850@lzapx.brq.redhat.com> Message-ID: <616123916.7613133.1345213149529.JavaMail.root@redhat.com> ----- Original Message ----- > On Thu, Aug 09, 2012 at 12:25:41PM -0400, Eric Sammons wrote: > > Coming from GSS and having been a customer I can assure you that > > DEV == dev == Dev in a production world. Anything like > > Library->DEV->dev would be bad design within a company because in > > the real world dev is dev is dev regardless of how you type it. > > The same goes for usernames; in fact most web ui apps will > > convert for you the username entered to the case supported (for > > example I have seen, esammons at example.com get changed to > > ESAMMONS at EXAMPLE.COM, perhaps they have a Mainframe backend). > > > > So while I may not agree here that allowing Dev DEV and dev, I am > > more of the opinion that we either fix it or we document it > > because as is the current behavior could be dangerous. > > In particular, why having both DEV and dev is a bad thing? > Personally, I > like the possibility of having them, while I understand it can be > pretty > cluttered. This would be a horrible behavior as in a corporate IT shop you would not want to have a discussion that goes something like: IT Tech1: Today I will be promoting to dev IT Tech2: Will that be capital dev or lowercase dev? IT Tech1: hmmmm, good question. > > In any case, we can expect UTF-8 issues (Ruby 1.8 vs Ruby 1.9), > because > there are many non-US characters that has uppercase and lowercase > variants. External dependency will likely need to be introduced for > Ruby > 1.8. Does it really worth the change? What I believe would be correct is some logic that simply checks to see if, dev in this example exists in the db. I'm not sure if this would work but perhaps a check that simple does if env_input.lower() != env_from_db.lower(): store(input) Regardless, it sounds like this issue is much easier to address in Ruby 1.9 so based on the feedback on this thread I am going to mark the bugs out there already as Future Feature and perhaps we can get a user story for SAM-1.3 and CFSE-1.? Thanks for everyone's input. --Eric From dmitri at redhat.com Fri Aug 17 14:32:04 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 17 Aug 2012 15:32:04 +0100 Subject: [katello-devel] Renaming of environments: summary, take II In-Reply-To: <502E51A2.5030208@redhat.com> References: <502BE065.9050003@redhat.com> <502E51A2.5030208@redhat.com> Message-ID: <502E55E4.7000302@redhat.com> On 17/08/12 03:13 PM, Bryan Kearney wrote: > On 08/15/2012 01:46 PM, Dmitri Dolguikh wrote: >> Please see original conversation thread [1], first attempt at summary >> [2], and BZ [3] for details. >> >> The majority of the conversation revolved around use of human-readable >> ids to preserve user-friendiness of urls vs. using uuids to preserve >> data consistency of client applications that use Katello API. Another >> concern expressed was readability of repository urls genereated by >> Katello in yum configuration files. It was suggested to use Punycode for >> encoding of non-ascii-based labels. >> >> Proposed changes: >> - introduce immutable labels >> - replace use of environment name with environment label in urls not >> impacting data integrity, such as repository urls. This would eliminate >> the need for entitlement certificate regeneration after environment name >> changes >> - introduce uuids, and replace current use of primary db keys in >> resource urls with uuids >> >> Tasks on Katello side: >> - take a look at and implement Punycode >> - introduce environment labels: db changes, model changes, controller >> changes >> - introduce uuids: db changes, model changes, controller changes >> - figure out migration for existing Katello installations >> >> Tasks on Candlepin side: >> - add label and uuid fields to model. Replace use of environment names >> with environment labels >> >> >> >> [1] >> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html >> [2] >> https://www.redhat.com/archives/katello-devel/2012-August/msg00144.html >> [3] https://bugzilla.redhat.com/show_bug.cgi?id=795928 >> [4] http://en.wikipedia.org/wiki/Punycode >> > > so, in katello, if I create an environment called JarJar, a product > called Binks, and a repo called IsASuperStar, today I would see this: > > [jarjar-binks-IsASuperStar] > Name: JarJarBinksIsASuperStar > baseurl:JarJar/Binks/IsASuperStar > > What will i see tomorow? > > - bk I'm assuming that you are asking what you are going to see in yum repository configuration file. I'm proposing to keep that file without any changes, with the exception that we use environment label instead of the name. For existing installations, I'm proposing to initialize label with current environment name during the migration. -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Fri Aug 17 14:55:54 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 17 Aug 2012 16:55:54 +0200 Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <616123916.7613133.1345213149529.JavaMail.root@redhat.com> References: <20120814092915.GF2850@lzapx.brq.redhat.com> <616123916.7613133.1345213149529.JavaMail.root@redhat.com> Message-ID: <20120817145554.GF2820@lzapx.brq.redhat.com> On Fri, Aug 17, 2012 at 10:19:09AM -0400, Eric Sammons wrote: > This would be a horrible behavior as in a corporate IT shop you would not want to have a discussion that goes something like: > > IT Tech1: Today I will be promoting to dev > IT Tech2: Will that be capital dev or lowercase dev? > IT Tech1: hmmmm, good question. > Let's leave the decision on the IT shops themselves. Microsoft did this for us - and its a pain in the ahhhh now. UNIX vs Windows. :) I mean - I don't consider this to be important. But if you feel customers need it... no issues from my side. -- Later, Lukas "lzap" Zapletal #katello #systemengine From mmccune at redhat.com Fri Aug 17 15:05:27 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 17 Aug 2012 08:05:27 -0700 Subject: [katello-devel] Renaming of environments: summary, take II In-Reply-To: <502E55E4.7000302@redhat.com> References: <502BE065.9050003@redhat.com> <502E51A2.5030208@redhat.com> <502E55E4.7000302@redhat.com> Message-ID: <502E5DB7.2060500@redhat.com> On 08/17/2012 07:32 AM, Dmitri Dolguikh wrote: > On 17/08/12 03:13 PM, Bryan Kearney wrote: >> On 08/15/2012 01:46 PM, Dmitri Dolguikh wrote: >>> Please see original conversation thread [1], first attempt at summary >>> [2], and BZ [3] for details. >>> >>> The majority of the conversation revolved around use of human-readable >>> ids to preserve user-friendiness of urls vs. using uuids to preserve >>> data consistency of client applications that use Katello API. Another >>> concern expressed was readability of repository urls genereated by >>> Katello in yum configuration files. It was suggested to use Punycode for >>> encoding of non-ascii-based labels. >>> >>> Proposed changes: >>> - introduce immutable labels >>> - replace use of environment name with environment label in urls not >>> impacting data integrity, such as repository urls. This would eliminate >>> the need for entitlement certificate regeneration after environment name >>> changes >>> - introduce uuids, and replace current use of primary db keys in >>> resource urls with uuids >>> >>> Tasks on Katello side: >>> - take a look at and implement Punycode >>> - introduce environment labels: db changes, model changes, controller >>> changes >>> - introduce uuids: db changes, model changes, controller changes >>> - figure out migration for existing Katello installations >>> >>> Tasks on Candlepin side: >>> - add label and uuid fields to model. Replace use of environment names >>> with environment labels >>> >>> >>> >>> [1] >>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html >>> [2] >>> https://www.redhat.com/archives/katello-devel/2012-August/msg00144.html >>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=795928 >>> [4] http://en.wikipedia.org/wiki/Punycode >>> >> >> so, in katello, if I create an environment called JarJar, a product >> called Binks, and a repo called IsASuperStar, today I would see this: >> >> [jarjar-binks-IsASuperStar] >> Name: JarJarBinksIsASuperStar >> baseurl:JarJar/Binks/IsASuperStar >> >> What will i see tomorow? >> >> - bk > I'm assuming that you are asking what you are going to see in yum > repository configuration file. I'm proposing to keep that file without > any changes, with the exception that we use environment label instead of > the name. For existing installations, I'm proposing to initialize label > with current environment name during the migration. > that sounds perfect .. label is fine Mike From dmitri at redhat.com Fri Aug 17 15:09:29 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 17 Aug 2012 16:09:29 +0100 Subject: [katello-devel] Renaming of environments: summary, take II In-Reply-To: <502E5DB7.2060500@redhat.com> References: <502BE065.9050003@redhat.com> <502E51A2.5030208@redhat.com> <502E55E4.7000302@redhat.com> <502E5DB7.2060500@redhat.com> Message-ID: <502E5EA9.9070104@redhat.com> On 17/08/12 04:05 PM, Mike McCune wrote: > On 08/17/2012 07:32 AM, Dmitri Dolguikh wrote: >> On 17/08/12 03:13 PM, Bryan Kearney wrote: >>> On 08/15/2012 01:46 PM, Dmitri Dolguikh wrote: >>>> Please see original conversation thread [1], first attempt at summary >>>> [2], and BZ [3] for details. >>>> >>>> The majority of the conversation revolved around use of human-readable >>>> ids to preserve user-friendiness of urls vs. using uuids to preserve >>>> data consistency of client applications that use Katello API. Another >>>> concern expressed was readability of repository urls genereated by >>>> Katello in yum configuration files. It was suggested to use >>>> Punycode for >>>> encoding of non-ascii-based labels. >>>> >>>> Proposed changes: >>>> - introduce immutable labels >>>> - replace use of environment name with environment label in urls >>>> not >>>> impacting data integrity, such as repository urls. This would >>>> eliminate >>>> the need for entitlement certificate regeneration after environment >>>> name >>>> changes >>>> - introduce uuids, and replace current use of primary db keys in >>>> resource urls with uuids >>>> >>>> Tasks on Katello side: >>>> - take a look at and implement Punycode >>>> - introduce environment labels: db changes, model changes, >>>> controller >>>> changes >>>> - introduce uuids: db changes, model changes, controller changes >>>> - figure out migration for existing Katello installations >>>> >>>> Tasks on Candlepin side: >>>> - add label and uuid fields to model. Replace use of environment >>>> names >>>> with environment labels >>>> >>>> >>>> >>>> [1] >>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html >>>> >>>> [2] >>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00144.html >>>> >>>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=795928 >>>> [4] http://en.wikipedia.org/wiki/Punycode >>>> >>> >>> so, in katello, if I create an environment called JarJar, a product >>> called Binks, and a repo called IsASuperStar, today I would see this: >>> >>> [jarjar-binks-IsASuperStar] >>> Name: JarJarBinksIsASuperStar >>> baseurl:JarJar/Binks/IsASuperStar >>> >>> What will i see tomorow? >>> >>> - bk >> I'm assuming that you are asking what you are going to see in yum >> repository configuration file. I'm proposing to keep that file without >> any changes, with the exception that we use environment label instead of >> the name. For existing installations, I'm proposing to initialize label >> with current environment name during the migration. >> > > that sounds perfect .. label is fine Note that we could use the environment name in yum repository url too, but that would result in en-masse certificate regeneration for all systems in a given environment on environment name change. -d > > Mike From thomasmckay at redhat.com Fri Aug 17 15:32:05 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 17 Aug 2012 11:32:05 -0400 (EDT) Subject: [katello-devel] Direct Pushes to Katello Master In-Reply-To: <502E5002.9000101@redhat.com> Message-ID: <795854100.11054658.1345217525557.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Miroslav Such?" > To: "katello-devel" > Sent: Friday, August 17, 2012 10:06:58 AM > Subject: Re: [katello-devel] Direct Pushes to Katello Master > > On 08/17/2012 03:35 PM, Eric Helms wrote: > > I have seen what appears to be direct pushes to Katello master in > > the past week or two which goes against our core requirement that > > EVERYTHING going to master (minus tags) goes through via a Pull > > Request. If this policy needs to be amended, then let's amend it > > instead of going around it or, better yet, if there are things > > that need to be direct pushed to a repository then perhaps that > > code needs to be in it's own repository so it can have it's own > > set of rules. > > Which *code* went directly? > > I'm pushing some commits directly, but they are rel-eng related. It > is > either tagged packages or changes in comps files. It is very important that the entire team(s) see the changes going into katello master. The best way to retain visibility is via pull-request for everything. Specifically, "rel-eng" changes will impact SAM/headpin too and our team needs to be aware of them. Unless there is an exceedingly good reason I am in favor of _all_ changes going through the pull-request process. Thanks! > > -- > Miroslav Suchy > Red Hat Systems Management Engineering > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jomara at redhat.com Fri Aug 17 15:47:43 2012 From: jomara at redhat.com (Jordan OMara) Date: Fri, 17 Aug 2012 11:47:43 -0400 Subject: [katello-devel] Direct Pushes to Katello Master In-Reply-To: <795854100.11054658.1345217525557.JavaMail.root@redhat.com> References: <502E5002.9000101@redhat.com> <795854100.11054658.1345217525557.JavaMail.root@redhat.com> Message-ID: <20120817154743.GK38885@redhat.com> On 17/08/12 11:32 -0400, Tom McKay wrote: > > >----- Original Message ----- >> From: "Miroslav Such?" >> To: "katello-devel" >> Sent: Friday, August 17, 2012 10:06:58 AM >> Subject: Re: [katello-devel] Direct Pushes to Katello Master > >It is very important that the entire team(s) see the changes going into katello master. The best way to retain visibility is via pull-request for everything. Specifically, "rel-eng" changes will impact SAM/headpin too and our team needs to be aware of them. +1 >Unless there is an exceedingly good reason I am in favor of _all_ changes going through the pull-request process. Except pushing tags :) -- 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 mmccune at redhat.com Fri Aug 17 15:57:14 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 17 Aug 2012 08:57:14 -0700 Subject: [katello-devel] Direct Pushes to Katello Master In-Reply-To: <795854100.11054658.1345217525557.JavaMail.root@redhat.com> References: <795854100.11054658.1345217525557.JavaMail.root@redhat.com> Message-ID: <502E69DA.7020600@redhat.com> On 08/17/2012 08:32 AM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Miroslav Such?" >> To: "katello-devel" >> Sent: Friday, August 17, 2012 10:06:58 AM >> Subject: Re: [katello-devel] Direct Pushes to Katello Master >> >> On 08/17/2012 03:35 PM, Eric Helms wrote: >>> I have seen what appears to be direct pushes to Katello master in >>> the past week or two which goes against our core requirement that >>> EVERYTHING going to master (minus tags) goes through via a Pull >>> Request. If this policy needs to be amended, then let's amend it >>> instead of going around it or, better yet, if there are things >>> that need to be direct pushed to a repository then perhaps that >>> code needs to be in it's own repository so it can have it's own >>> set of rules. >> >> Which *code* went directly? >> >> I'm pushing some commits directly, but they are rel-eng related. It >> is >> either tagged packages or changes in comps files. > > It is very important that the entire team(s) see the changes going into katello master. The best way to retain visibility is via pull-request for everything. Specifically, "rel-eng" changes will impact SAM/headpin too and our team needs to be aware of them. > > Unless there is an exceedingly good reason I am in favor of _all_ changes going through the pull-request process. we agreed a while back that tito initiated changes (tags and specfile version diffs) should not require pull requests. examples: https://github.com/Katello/katello/commit/4e1bba08dd990273812ecb1d640179649642517d https://github.com/Katello/katello/commit/ba4b853a4f5d5fb2fc1ebb5222f39617977b1452 https://github.com/Katello/katello/commit/d310f961d6e64e8ef96938fc09399b1a59fd104b For any other changes to the structural nature of the specfile we should be using Pull Requests. For actual code changes, we should always be using Pull Requests Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From esammons at redhat.com Fri Aug 17 16:30:26 2012 From: esammons at redhat.com (Eric Sammons) Date: Fri, 17 Aug 2012 12:30:26 -0400 (EDT) Subject: [katello-devel] Doubts In-Reply-To: <1737820197.3529243.1345104746119.JavaMail.root@redhat.com> Message-ID: <1260903678.7688518.1345221026781.JavaMail.root@redhat.com> ----- Original Message ----- cc'ing katello-devel here for transparency and they may have some input here. > Hi, > > > 1. I uploaded a manifests which was valid on one of the servers. > 2. the rpm packages installed is as follows : > [root at dell-pesc1435-01 ~]# rpm -qa | grep katello > katello-all-1.0.5-1.fc16.noarch > katello-glue-candlepin-1.0.5-1.fc16.noarch > katello-configure-1.1.3-1.fc16.noarch > katello-glue-pulp-1.0.5-1.fc16.noarch > katello-1.0.5-1.fc16.noarch > katello-candlepin-cert-key-pair-1.0-1.noarch > katello-selinux-1.0.1-1.fc16.noarch > katello-cli-headpin-1.1.0-1.git.14.d10e8a3.fc16.noarch > katello-glue-foreman-1.0.5-1.fc16.noarch > katello-certs-tools-1.1.8-1.fc16.noarch > katello-cli-common-1.1.1-1.fc16.noarch > katello-common-1.0.5-1.fc16.noarch > > 3. Later, I subscribed few systems to the subscriptions > uploaded. > > 4. Uploaded another manifests created from the same distributor > . > 5. subscribed the systems again with the new subscriptions. > > 6. Subscriptions appear to be invalid although they are valid. For the above, I will try and reproduce as I have not tried this; however, my first question is did you use the --force open when re-subscribing the systems? Did you receive any errors during the register/subscribe process? And finally, did you do a subscription-manager clean first (--force I believe will take care of this for you)? > > 7. Also, when I tried to upload the very first manifest again it > failed with errors. This behavior here is expected as the manifest is in fact older than the manifest you have currently loaded. > Please, let me know if its a bug so that can be filed accordingly. > > > Thanks & Regards, > Tazim --Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: import_error_16thaugust.png Type: image/png Size: 110181 bytes Desc: not available URL: From bkearney at redhat.com Fri Aug 17 20:38:48 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 17 Aug 2012 16:38:48 -0400 Subject: [katello-devel] Renaming of environments: summary, take II In-Reply-To: <502E5EA9.9070104@redhat.com> References: <502BE065.9050003@redhat.com> <502E51A2.5030208@redhat.com> <502E55E4.7000302@redhat.com> <502E5DB7.2060500@redhat.com> <502E5EA9.9070104@redhat.com> Message-ID: <502EABD8.6030705@redhat.com> On 08/17/2012 11:09 AM, Dmitri Dolguikh wrote: > On 17/08/12 04:05 PM, Mike McCune wrote: >> On 08/17/2012 07:32 AM, Dmitri Dolguikh wrote: >>> On 17/08/12 03:13 PM, Bryan Kearney wrote: >>>> On 08/15/2012 01:46 PM, Dmitri Dolguikh wrote: >>>>> Please see original conversation thread [1], first attempt at summary >>>>> [2], and BZ [3] for details. >>>>> >>>>> The majority of the conversation revolved around use of human-readable >>>>> ids to preserve user-friendiness of urls vs. using uuids to preserve >>>>> data consistency of client applications that use Katello API. Another >>>>> concern expressed was readability of repository urls genereated by >>>>> Katello in yum configuration files. It was suggested to use >>>>> Punycode for >>>>> encoding of non-ascii-based labels. >>>>> >>>>> Proposed changes: >>>>> - introduce immutable labels >>>>> - replace use of environment name with environment label in urls >>>>> not >>>>> impacting data integrity, such as repository urls. This would >>>>> eliminate >>>>> the need for entitlement certificate regeneration after environment >>>>> name >>>>> changes >>>>> - introduce uuids, and replace current use of primary db keys in >>>>> resource urls with uuids >>>>> >>>>> Tasks on Katello side: >>>>> - take a look at and implement Punycode >>>>> - introduce environment labels: db changes, model changes, >>>>> controller >>>>> changes >>>>> - introduce uuids: db changes, model changes, controller changes >>>>> - figure out migration for existing Katello installations >>>>> >>>>> Tasks on Candlepin side: >>>>> - add label and uuid fields to model. Replace use of environment >>>>> names >>>>> with environment labels >>>>> >>>>> >>>>> >>>>> [1] >>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html >>>>> >>>>> [2] >>>>> https://www.redhat.com/archives/katello-devel/2012-August/msg00144.html >>>>> >>>>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=795928 >>>>> [4] http://en.wikipedia.org/wiki/Punycode >>>>> >>>> >>>> so, in katello, if I create an environment called JarJar, a product >>>> called Binks, and a repo called IsASuperStar, today I would see this: >>>> >>>> [jarjar-binks-IsASuperStar] >>>> Name: JarJarBinksIsASuperStar >>>> baseurl:JarJar/Binks/IsASuperStar >>>> >>>> What will i see tomorow? >>>> >>>> - bk >>> I'm assuming that you are asking what you are going to see in yum >>> repository configuration file. I'm proposing to keep that file without >>> any changes, with the exception that we use environment label instead of >>> the name. For existing installations, I'm proposing to initialize label >>> with current environment name during the migration. >>> >> >> that sounds perfect .. label is fine > Note that we could use the environment name in yum repository url too, > but that would result in en-masse certificate regeneration for all > systems in a given environment on environment name change. > so, we oculd end up with an environment named Dev, with a label of Prod. Kinda a hokey example.. but ok. I would envision, at some point, haveing an admin task which does the label rename and regens all the certs. -- bk From vvaldez at redhat.com Fri Aug 17 21:45:11 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Fri, 17 Aug 2012 16:45:11 -0500 Subject: [katello-devel] Error syncing Fedora 16 In-Reply-To: <126086150.47692747.1345161751135.JavaMail.root@redhat.com> References: <126086150.47692747.1345161751135.JavaMail.root@redhat.com> Message-ID: Interesting. I still get the same error if I point to ftp://mirrors.kernel.org/fedora/releases/16/Fedora/x86_64/os/. I tried with Fedora 17, and it worked fine using ftp://mirrors.kernel.org/fedora/releases/17/Fedora/x86_64/os/. However, if I rsync a mounted ISO I get the same boot.iso failure with both F16/F17, but cause the ISOs don't contain images/boot.iso. This is definitely not a katello issue, thanks for catching that. I'll rsync a public mirror instead of using an ISO. Vinny On Aug 16, 2012, at 7:02 PM, John Matthews wrote: > Vinny, > > This looks like a problem on the remote repo. The remote repo has a metadata file called ".treeinfo". > ".treeinfo" specifies a file "images/boot.iso", yet "images/boot.iso" does not exist on the repo. > > > When I try to fetch "images/boot.iso" I get a 404. > http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso > > > ".treeinfo" is here: > http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os/.treeinfo > > [general] > family = Fedora > timestamp = 1320289812.31 > variant = Fedora > version = 16 > packagedir = > arch = x86_64 > > [images-x86_64] > kernel = images/pxeboot/vmlinuz > initrd = images/pxeboot/initrd.img > boot.iso = images/boot.iso > > [images-xen] > kernel = images/pxeboot/vmlinuz > initrd = images/pxeboot/initrd.img > > [checksums] > images/efidisk.img = sha256:fa168ed2bbd556606a0dcfef7ff531f3181f67546a4a148210d211cc129fd572 > images/boot.iso = sha256:a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b > images/efiboot.img = sha256:ec7ad37b2cd09ecadbbaa0a51b60c5909712c2303f0529578a5045758d5e6e04 > images/pxeboot/initrd.img = sha256:60fd924a0684fc623c25d53395f41d752c37b68fc53596c04cfe3e9b057c1fc2 > images/pxeboot/vmlinuz = sha256:82ee5b351a875dc7b646f78e4aad9cf697eb3c85784b0f82134fe0e907202171 > repodata/repomd.xml = sha256:441f0cdbaa66d8742fb4d3399efb5b2a25998f49a718f41665a1e116d0bffff8 > > > ----- Original Message ----- >> >> >> I duplicated this in a lab pointing to a known good repo, with no >> updates on any packages. As soon as I start the sync, I get these >> errors: >> >> >> >> 2012-08-16 21:58:17,715 31245:139849537402624: >> grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, >> read md5sum of: >> 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec >> expected md5sum of >> a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b >> 2012-08-16 21:58:17,740 31245:139849537402624: >> grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, >> read md5sum of: >> 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec >> expected md5sum of >> a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b >> 2012-08-16 21:58:17,748 31245:139849537402624: >> grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, >> read md5sum of: >> 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec >> expected md5sum of >> a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b >> 2012-08-16 21:58:17,760 31245:139849537402624: >> grinder.BaseFetch:WARNING: activeobject:162 ERROR: Response = 404 >> fetching >> http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso >> . >> >> >> I also tried directly with grinder and get this error: >> >> >> grinder yum --label=test1 --url= >> http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os/ >> >> grinder.ProgressTracker: WARNING >> http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/efidisk.img >> changing tracker for tree_file total_size_bytes from 140755203 to >> 281549059 >> grinder.BaseFetch: ERROR boot.iso md5sum mismatch, read md5sum of: >> 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec >> expected md5sum of >> a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b >> grinder.BaseFetch: WARNING Retrying fetch of: boot.iso with 0 retry >> attempts left. HTTP status was 404 >> grinder.BaseFetch: INFO Cleanup ./test1/images/boot.iso >> grinder.ProgressTracker: WARNING Resetting progress for < >> http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso >>> >> grinder.BaseFetch: INFO Fetching Unknown bytes: boot.iso from >> http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso >> grinder.BaseFetch: ERROR boot.iso md5sum mismatch, read md5sum of: >> 657cd2d3122b3cb9bbc9c2252d023b4c1ff43bcd6f55af5e7447bfe9cf5035ec >> expected md5sum of >> a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b >> grinder.BaseFetch: INFO Cleanup ./test1/images/boot.iso >> grinder.BaseFetch: WARNING ERROR: Response = 404 fetching >> http://file.gsso.redhat.com/pub/data/isos/fedora/16/x86_64/os//images/boot.iso >> . >> >> I'll try building a system even with the repo in this state. >> >> >> >> >> >> >> Vinny >> >> >> >> On Aug 15, 2012, at 5:49 PM, Vinny Valdez < vvaldez at redhat.com > >> wrote: >> >> >> >> >> My mistake, the error is actually as follows: >> >> 2012-08-15 22:33:59,275 2436:139770315405056: >> grinder.ProgressTracker:WARNING: ProgressTracker:141 >> http://files.example . >> com/pub/installers/fedora/16/x86_64/os//images/boot.iso changing >> tracker for tree_file total_size_bytes from 0 to 332 >> 2012-08-15 22:33:59,278 2436:139770315405056: >> grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, >> read md5sum of: >> 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c >> expected md5sum of >> a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b >> 2012-08-15 22:33:59,279 2436:139770315405056: >> grinder.BaseFetch:WARNING: activeobject:162 Retrying fetch of: >> boot.iso with 1 retry attempts left. HTTP status was 404 >> 2012-08-15 22:33:59,279 2436:139770315405056: grinder.BaseFetch:INFO: >> activeobject:162 Cleanup >> /var/lib/pulp/distributions/ks-Fedora-Fedora-16-x86_64/boot.iso >> 2012-08-15 22:33:59,279 2436:139770315405056: >> grinder.ProgressTracker:WARNING: ProgressTracker:258 Resetting >> progress for < >> http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso >>> >> 2012-08-15 22:33:59,283 2436:139770315405056: grinder.BaseFetch:INFO: >> activeobject:162 Fetching Unknown bytes: boot.iso from >> http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso >> 2012-08-15 22:33:59,285 2436:139770315405056: >> grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, >> read md5sum of: >> 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c >> expected md5sum of >> a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b >> 2012-08-15 22:33:59,285 2436:139770315405056: >> grinder.BaseFetch:WARNING: activeobject:162 Retrying fetch of: >> boot.iso with 0 retry attempts left. HTTP status was 404 >> 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:INFO: >> activeobject:162 Cleanup >> /var/lib/pulp/distributions/ks-Fedora-Fedora-16-x86_64/boot.iso >> 2012-08-15 22:33:59,285 2436:139770315405056: >> grinder.ProgressTracker:WARNING: ProgressTracker:258 Resetting >> progress for < >> http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso >>> >> 2012-08-15 22:33:59,285 2436:139770315405056: grinder.BaseFetch:INFO: >> activeobject:162 Fetching Unknown bytes: boot.iso from >> http://files.example.com/pub/installers/fedora/16/x86_64/os//images/boot.iso >> 2012-08-15 22:33:59,287 2436:139770315405056: >> grinder.BaseFetch:ERROR: activeobject:162 boot.iso md5sum mismatch, >> read md5sum of: >> 78a3708ddd2a4eee2b424ab3b20170473e0d3ca671033ef98151424f8bfe423c >> expected md5sum of >> a51885ea0e91471beea6af2e682d778e40f34de939e3752eec5ab24e56bca80b >> >> >> When I first hit this error, I thought I needed to update as a gut >> reaction troubleshooting step, I did so then ran into the updated >> pymongo issue, and incorrectly pasted that as the culprit. scollier >> also gets the same error in his environment. >> >> >> >> >> Vinny >> >> >> On Aug 15, 2012, at 4:46 PM, Todd Sanders < tsanders at redhat.com > >> wrote: >> >> >> >> >> Probably the version of pymongo....see: >> https://fedorahosted.org/pulp/wiki/UGFAQ#rpmname >> >> -Todd >> >> On 08/15/2012 05:22 PM, Vinny Valdez wrote: >> >> >> >> I setup katello on Fedora 16 and tried to sync Fedora 16 from a repo >> created from a gold ISO. I get the following error: >> >> >> >> 2012-08-15 20:30:01,845 3359:140003283810048: >> pulp.server.tasking.task:ERROR: task:472 Task failed: Task >> 261f4dcf-e740-11e1-b495-525400360b28: >> _sync(Example-Fedora16-fedora16-x86_64, >> synchronizer=> at 0x7f554bcc7bd0>, skip={}, max_speed=None, threads=4, >> progress_callback=> > 0x7f554bcc7d90>>) >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/pulp/server/tasking/task.py", >> line 418, in run >> result = self.callable(*self.args, **self.kwargs) >> File "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", >> line 283, in _sync >> progress_callback, synchronizer, max_speed, threads) >> File "/usr/lib/python2.7/site-packages/pulp/server/api/repo_sync.py", >> line 379, in fetch_content >> added_errataids = synchronizer.import_metadata(repo_dir, repo_id, >> skip_dict) >> File >> "/usr/lib/python2.7/site-packages/pulp/server/api/synchronizers.py", >> line 415, in import_metadata >> self.repo_api.collection.save(repo, safe=True) >> File "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", >> line 80, in retry >> return method(*args, **kwargs) >> File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line >> 237, in save >> manipulate, safe, _check_keys=True, **kwargs) >> File "/usr/lib/python2.7/site-packages/pulp/server/db/connection.py", >> line 80, in retry >> return method(*args, **kwargs) >> File "/usr/lib64/python2.7/site-packages/pymongo/collection.py", line >> 411, in update >> _check_keys, self.__uuid_subtype), safe) >> InvalidDocument: key ' openoffice.org -voikko' must not contain '.' >> >> >> Is there anything I am doing wrong here? >> >> >> >> katello-1.0.4-1.fc16.noarch >> katello-cli-common-1.0.1-1.fc16.noarch >> katello-configure-1.0.1-1.fc16.noarch >> katello-common-1.0.4-1.fc16.noarch >> katello-qpid-broker-key-pair-1.0-1.noarch >> katello-glue-foreman-1.0.4-1.fc16.noarch >> katello-all-1.0.4-1.fc16.noarch >> katello-certs-tools-1.1.7-1.fc16.noarch >> katello-qpid-client-key-pair-1.0-1.noarch >> katello-repos-1.0.3-1.fc16.noarch >> katello-glue-candlepin-1.0.4-1.fc16.noarch >> katello-cli-1.0.1-1.fc16.noarch >> katello-glue-pulp-1.0.4-1.fc16.noarch >> katello-candlepin-cert-key-pair-1.0-1.noarch >> katello-selinux-1.0.1-1.fc16.noarch >> >> pulp-common-1.1.11-1.fc16.noarch >> pulp-selinux-server-1.1.11-1.fc16.noarch >> pulp-1.1.11-1.fc16.noarch >> >> candlepin-0.7.4.2-1.fc16.noarch >> candlepin-tomcat6-0.7.4.2-1.fc16.noarch >> >> qpid-cpp-server-0.16-3.1.fc16.x86_64 >> qpid-cpp-client-0.16-3.1.fc16.x86_64 >> qpid-cpp-server-ssl-0.16-3.1.fc16.x86_64 >> qpid-cpp-client-ssl-0.16-3.1.fc16.x86_64 >> >> >> Regards, >> >> >> >> >> >> >> Vinny >> >> >> _______________________________________________ >> 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 omaciel at redhat.com Sat Aug 18 19:07:12 2012 From: omaciel at redhat.com (Og Maciel) Date: Sat, 18 Aug 2012 15:07:12 -0400 (EDT) Subject: [katello-devel] jammit for latest katello In-Reply-To: <1641256758.7954491.1345316791559.JavaMail.root@redhat.com> Message-ID: <2035166995.7954492.1345316832081.JavaMail.root@redhat.com> I may have missed the thread, but where will jammit eventually be found? Getting requirements for katello-1.1.5-1.git.24.212ceef.el6_3.src --> asciidoc-8.4.5-4.1.el6.noarch --> Already installed : util-linux-ng-2.17.2-12.7.el6.x86_64 --> Already installed : coreutils-8.4-19.el6.x86_64 --> Already installed : 1:findutils-4.4.2-6.el6.x86_64 --> Already installed : sed-4.2.1-10.el6.x86_64 --> rubygems-1.3.7-1.el6.noarch --> rubygem-rake-0.8.7-2.1.el6.noarch --> rubygem-gettext-2.1.0-1.el6.1.noarch Error: No Package found for rubygem(jammit) -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From omaciel at redhat.com Sat Aug 18 19:18:09 2012 From: omaciel at redhat.com (Og Maciel) Date: Sat, 18 Aug 2012 15:18:09 -0400 (EDT) Subject: [katello-devel] jammit for latest katello In-Reply-To: <2035166995.7954492.1345316832081.JavaMail.root@redhat.com> Message-ID: <1519219759.7955169.1345317489263.JavaMail.root@redhat.com> I believe this is it: http://fedorapeople.org/groups/katello/katello/6Server/x86_64/ -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From vvaldez at redhat.com Sat Aug 18 20:48:49 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Sat, 18 Aug 2012 15:48:49 -0500 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> References: <5006F35F.60008@redhat.com> <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> Message-ID: On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: > Team, > > I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts > > We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. > > Thanks, > > Vinny > > > On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: > >> Do you want to be a star, and help promote Katello. Have we got a deal for you: >> >> https://fedorahosted.org/katello/wiki/Screencasts >> >> -- bk >> > > The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. http://people.redhat.com/vvaldez/videos/katello/ Regards, Vinny From thomasmckay at redhat.com Sun Aug 19 11:08:40 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Sun, 19 Aug 2012 07:08:40 -0400 (EDT) Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: Message-ID: <1513531402.11314617.1345374520373.JavaMail.root@redhat.com> Nice! ----- Original Message ----- > From: "Vinny Valdez" > To: "Bryan Kearney" > Cc: katello-devel at redhat.com > Sent: Saturday, August 18, 2012 4:48:49 PM > Subject: Re: [katello-devel] Do you want to be a movie star? > > On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: > > > Team, > > > > I started working on these screencasts. Scott Collier and myself > > are going to split the work and try to get these done soon. I > > already have some footage of the initial setup, but wanted to > > request a review on the outlines I put together (taken from the > > fedorahosted wiki page). Everything is here: > > https://github.com/vvaldez/katello-screencasts > > > > We're hoping for some feedback on exactly what kind of user/role > > setup should be shown, maybe some assistance on system groups. > > Currently I recorded creating a "template admin" user and role, > > but I can certainly expand this more. > > > > Thanks, > > > > Vinny > > > > > > On Jul 18, 2012, at 12:33 PM, Bryan Kearney > > wrote: > > > >> Do you want to be a star, and help promote Katello. Have we got a > >> deal for you: > >> > >> https://fedorahosted.org/katello/wiki/Screencasts > >> > >> -- bk > >> > > > > > > The first video is ready for review. Please let me know if the volume > is too low, if there are any issues with playback on any devices, > codec preferences, quality issues, suggestions, etc. > > http://people.redhat.com/vvaldez/videos/katello/ > > Regards, > > Vinny > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From bkearney at redhat.com Sun Aug 19 14:12:47 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Sun, 19 Aug 2012 10:12:47 -0400 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: References: <5006F35F.60008@redhat.com> <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> Message-ID: <5030F45F.3050907@redhat.com> On 08/18/2012 04:48 PM, Vinny Valdez wrote: > On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: > >> Team, >> >> I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts >> >> We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. >> >> Thanks, >> >> Vinny >> >> >> On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: >> >>> Do you want to be a star, and help promote Katello. Have we got a deal for you: >>> >>> https://fedorahosted.org/katello/wiki/Screencasts >>> >>> -- bk >>> >> >> > > The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. > > http://people.redhat.com/vvaldez/videos/katello/ > > Regards, > > Vinny > This looks good! what software did you use to create this? There appears to be some text at the bottom when you log in which talks about the CLI? Is this the "how to do it in the CLI" version? -- bk From jrist at redhat.com Mon Aug 20 03:08:10 2012 From: jrist at redhat.com (Jason Rist) Date: Sun, 19 Aug 2012 21:08:10 -0600 Subject: [katello-devel] where to get required katello gems In-Reply-To: <500448AF.1030202@redhat.com> References: <12e2e122-609a-4070-b8e8-e0b4aeca2b86@zmail16.collab.prod.int.phx2.redhat.com> <20120716142359.GJ4145@lzapx.brq.redhat.com> <500439D0.3050704@redhat.com> <500448AF.1030202@redhat.com> Message-ID: <5031AA1A.3070005@redhat.com> On Mon 16 Jul 2012 11:00:31 AM MDT, Miroslav Suchy wrote: > On 16.7.2012 17:57, Petr Chalupa wrote: >> Not everybody is running on fedora, this affects all debian-based >> distributions as well. > > How many Debian users we have? > > Only developers, like to do "make configure && make && make install". > All ordinary users like (and admins managing their machines) like good > old packages - be it .rpm or .deb. > > Mirek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel What is the conclusion of this? Jordan and I were working on replicating an issue and we both had some issues with Gems. I understand we moved our Gem repo, but where is it? What happened to the old one? Is there a wiki page explaining what was done so that we can understand as we continue to develop? Thanks, Jason -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From msuchy at redhat.com Mon Aug 20 07:01:41 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 20 Aug 2012 09:01:41 +0200 Subject: [katello-devel] jammit for latest katello In-Reply-To: <1519219759.7955169.1345317489263.JavaMail.root@redhat.com> References: <1519219759.7955169.1345317489263.JavaMail.root@redhat.com> Message-ID: <5031E0D5.60602@redhat.com> On 08/18/2012 09:18 PM, Og Maciel wrote: > I believe this is it: http://fedorapeople.org/groups/katello/katello/6Server/x86_64/ > http://fedorapeople.org/groups/katello/katello/6Server/x86_64/rubygem-jammit-0.5.4-1.el6.noarch.rpm So you still have problem, or you solved it? -- Miroslav Suchy Red Hat Systems Management Engineering From lzap at redhat.com Mon Aug 20 09:12:51 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 20 Aug 2012 11:12:51 +0200 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: References: <5006F35F.60008@redhat.com> <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> Message-ID: <20120820091251.GD3593@lzapx.brq.redhat.com> It's looking great and files are small. Great work. LZ On Sat, Aug 18, 2012 at 03:48:49PM -0500, Vincent Valdez wrote: > On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: > > > Team, > > > > I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts > > > > We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. > > > > Thanks, > > > > Vinny > > > > > > On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: > > > >> Do you want to be a star, and help promote Katello. Have we got a deal for you: > >> > >> https://fedorahosted.org/katello/wiki/Screencasts > >> > >> -- bk > >> > > > > > > The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. > > http://people.redhat.com/vvaldez/videos/katello/ > > Regards, > > Vinny > > > _______________________________________________ > 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 Aug 20 09:18:22 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 20 Aug 2012 11:18:22 +0200 Subject: [katello-devel] [katello] Post 1.1 Code "Breakup" Discussion (#450) In-Reply-To: <502E4782.9090402@redhat.com> References: <502E4782.9090402@redhat.com> Message-ID: <20120820091822.GE3593@lzapx.brq.redhat.com> On Fri, Aug 17, 2012 at 07:30:42AM -0600, Jason Rist wrote: > Lukas - How does that work, exactly? Not the embedding of images (I get > that), but the pull-request-for-design-discussion method. I saw it in the github.com video I sent the other day on the list. You just open a branch, push images and stuff there and discuss it the normal way. Than it can be deleted perhaps. Not saying its the best way to do it, just noticed the guy was speaking about it. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Mon Aug 20 10:24:19 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 20 Aug 2012 12:24:19 +0200 Subject: [katello-devel] Non-RHEL clients and bootstrapping Message-ID: <20120820102419.GH3593@lzapx.brq.redhat.com> Hello, on the user list there is a report from Scientific Linux. The bootstrap RPM cannot configure rhsm, I guess its because there is none on his system. So to support RHEL clones, we need to ask users to install both rhsm and katello client. We have not been telling this in our client installation wiki page, so I did this (quite a huge) change: https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient?action=diff&version=27&old_version=26 Please test. I will also add a test in the post RPM script - if one of the components is not found, warning will be issued (currently it exits with error only). LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Mon Aug 20 11:48:21 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 20 Aug 2012 07:48:21 -0400 Subject: [katello-devel] Non-RHEL clients and bootstrapping In-Reply-To: <20120820102419.GH3593@lzapx.brq.redhat.com> References: <20120820102419.GH3593@lzapx.brq.redhat.com> Message-ID: <50322405.4000607@redhat.com> On 08/20/2012 06:24 AM, Lukas Zapletal wrote: > Hello, > > on the user list there is a report from Scientific Linux. The bootstrap > RPM cannot configure rhsm, I guess its because there is none on his > system. > > So to support RHEL clones, we need to ask users to install both rhsm and > katello client. We have not been telling this in our client installation > wiki page, so I did this (quite a huge) change: > > https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient > > https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient?action=diff&version=27&old_version=26 > > Please test. > > I will also add a test in the post RPM script - if one of the components > is not found, warning will be issued (currently it exits with error > only). > > LZ > Should the configrpm require subscription-manager? -- bk From bkearney at redhat.com Mon Aug 20 12:58:56 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 20 Aug 2012 08:58:56 -0400 Subject: [katello-devel] Doubts In-Reply-To: <1260903678.7688518.1345221026781.JavaMail.root@redhat.com> References: <1260903678.7688518.1345221026781.JavaMail.root@redhat.com> Message-ID: <50323490.9070309@redhat.com> On 08/17/2012 12:30 PM, Eric Sammons wrote: > > ----- Original Message ----- > > cc'ing katello-devel here for transparency and they may have some input here. > >> Hi, >> >> >> 1. I uploaded a manifests which was valid on one of the servers. >> 2. the rpm packages installed is as follows : >> [root at dell-pesc1435-01 ~]# rpm -qa | grep katello >> katello-all-1.0.5-1.fc16.noarch >> katello-glue-candlepin-1.0.5-1.fc16.noarch >> katello-configure-1.1.3-1.fc16.noarch >> katello-glue-pulp-1.0.5-1.fc16.noarch >> katello-1.0.5-1.fc16.noarch >> katello-candlepin-cert-key-pair-1.0-1.noarch >> katello-selinux-1.0.1-1.fc16.noarch >> katello-cli-headpin-1.1.0-1.git.14.d10e8a3.fc16.noarch >> katello-glue-foreman-1.0.5-1.fc16.noarch >> katello-certs-tools-1.1.8-1.fc16.noarch >> katello-cli-common-1.1.1-1.fc16.noarch >> katello-common-1.0.5-1.fc16.noarch >> >> 3. Later, I subscribed few systems to the subscriptions >> uploaded. >> >> 4. Uploaded another manifests created from the same distributor >> . >> 5. subscribed the systems again with the new subscriptions. >> >> 6. Subscriptions appear to be invalid although they are valid. > > For the above, I will try and reproduce as I have not tried this; however, my first question is did you use the --force open when re-subscribing the systems? Did you receive any errors during the register/subscribe process? And finally, did you do a subscription-manager clean first (--force I believe will take care of this for you)? What about auto-heal? It should pick up the new subscriptions. -- bk From bkearney at redhat.com Mon Aug 20 12:59:48 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 20 Aug 2012 08:59:48 -0400 Subject: [katello-devel] Case sensitive behavior in katello In-Reply-To: <616123916.7613133.1345213149529.JavaMail.root@redhat.com> References: <616123916.7613133.1345213149529.JavaMail.root@redhat.com> Message-ID: <503234C4.3050400@redhat.com> On 08/17/2012 10:19 AM, Eric Sammons wrote: > ----- Original Message ----- >> On Thu, Aug 09, 2012 at 12:25:41PM -0400, Eric Sammons wrote: >>> Coming from GSS and having been a customer I can assure you that >>> DEV == dev == Dev in a production world. Anything like >>> Library->DEV->dev would be bad design within a company because in >>> the real world dev is dev is dev regardless of how you type it. >>> The same goes for usernames; in fact most web ui apps will >>> convert for you the username entered to the case supported (for >>> example I have seen, esammons at example.com get changed to >>> ESAMMONS at EXAMPLE.COM, perhaps they have a Mainframe backend). >>> >>> So while I may not agree here that allowing Dev DEV and dev, I am >>> more of the opinion that we either fix it or we document it >>> because as is the current behavior could be dangerous. >> >> In particular, why having both DEV and dev is a bad thing? >> Personally, I >> like the possibility of having them, while I understand it can be >> pretty >> cluttered. > > This would be a horrible behavior as in a corporate IT shop you would not want to have a discussion that goes something like: > > IT Tech1: Today I will be promoting to dev > IT Tech2: Will that be capital dev or lowercase dev? > IT Tech1: hmmmm, good question. > >> >> In any case, we can expect UTF-8 issues (Ruby 1.8 vs Ruby 1.9), >> because >> there are many non-US characters that has uppercase and lowercase >> variants. External dependency will likely need to be introduced for >> Ruby >> 1.8. Does it really worth the change? > > What I believe would be correct is some logic that simply checks to see if, dev in this example exists in the db. I'm not sure if this would work but perhaps a check that simple does > > if env_input.lower() != env_from_db.lower(): > store(input) > > Regardless, it sounds like this issue is much easier to address in Ruby 1.9 so based on the feedback on this thread I am going to mark the bugs out there already as Future Feature and perhaps we can get a user story for SAM-1.3 and CFSE-1.? > Sounds good. - bk From jrist at redhat.com Mon Aug 20 13:17:56 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 20 Aug 2012 07:17:56 -0600 Subject: [katello-devel] [katello] Post 1.1 Code "Breakup" Discussion (#450) In-Reply-To: <20120820091822.GE3593@lzapx.brq.redhat.com> References: <502E4782.9090402@redhat.com> <20120820091822.GE3593@lzapx.brq.redhat.com> Message-ID: <50323904.3030107@redhat.com> On Mon 20 Aug 2012 03:18:22 AM MDT, Lukas Zapletal wrote: > On Fri, Aug 17, 2012 at 07:30:42AM -0600, Jason Rist wrote: >> Lukas - How does that work, exactly? Not the embedding of images (I get >> that), but the pull-request-for-design-discussion method. > > I saw it in the github.com video I sent the other day on the list. You > just open a branch, push images and stuff there and discuss it the > normal way. Than it can be deleted perhaps. > > Not saying its the best way to do it, just noticed the guy was speaking > about it. > Yeah, that certainly doesn't seem like an ideal situation... Might work nicely for the design guys? -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jomara at redhat.com Mon Aug 20 13:25:25 2012 From: jomara at redhat.com (Jordan OMara) Date: Mon, 20 Aug 2012 09:25:25 -0400 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: References: <5006F35F.60008@redhat.com> <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> Message-ID: <20120820132525.GN38885@redhat.com> On 18/08/12 15:48 -0500, Vinny Valdez wrote: >On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: > >The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. > >http://people.redhat.com/vvaldez/videos/katello/ > The volume is great. Really nice job with the editing, mouse effects, etc. A++! -- 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 omaciel at redhat.com Mon Aug 20 13:27:51 2012 From: omaciel at redhat.com (Og Maciel) Date: Mon, 20 Aug 2012 09:27:51 -0400 (EDT) Subject: [katello-devel] jammit for latest katello In-Reply-To: <5031E0D5.60602@redhat.com> Message-ID: <1215904921.10149670.1345469271893.JavaMail.root@redhat.com> # rpm -Uvh http://fedorapeople.org/groups/katello/releases/yum/nightly/RHEL/6Server/x86_64/katello-repos-latest.rpm # rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm # yum-config-manager --enable rhel-6-server-optional-rpms # yes|yum -y update # yes|yum install -y katello-all Loaded plugins: product-id, security, subscription-manager Updating certificate-based repositories. http://fedorapeople.org/groups/katello/releases/yum/katello-foreman/%40SUBDIR%40/6Server/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404" . . . . . --> Processing Dependency: rubygems for package: rubygem-warden-1.0.3-2.el6.noarch ---> Package rubygem-yui-compressor.noarch 0:0.9.6-5.el6 will be installed --> Processing Dependency: rubygems for package: rubygem-yui-compressor-0.9.6-5.el6.noarch --> Finished Dependency Resolution Error: Package: rubygem-railties-3.0.10-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-oauth-0.4.4-1.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-json-1.4.6-1.el6.x86_64 (epel) Requires: rubygems Error: Package: rubygem-text-format-1.0.0-6.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-transaction-simple-1.4.0.2-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-rdoc-3.8-5.el6.noarch (katello) Requires: rubygems Error: Package: 1:rubygem-rack-1.3.0-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-polyglot-0.3.1-3.el6.noarch (katello) Requires: rubygems Error: Package: 1:rubygem-activerecord-3.0.10-6.el6.noarch (katello) Requires: rubygems Error: Package: 1:rubygem-activesupport-3.0.10-4.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-mime-types-1.16-3.el6.noarch (epel) Requires: ruby(rubygems) Error: Package: rubygem-jammit-0.6.5-8.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-rest-client-1.6.1-2.el6.noarch (epel) Requires: rubygems Error: Package: rubygem-apipie-rails-0.0.11-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-uuidtools-2.1.1-1.el6.noarch (epel) Requires: ruby(rubygems) Error: Package: rubygem-abstract-1.0.0-2.el6.noarch (epel) Requires: ruby(rubygems) Error: Package: rubygem-gettext_i18n_rails-0.2.13-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-delayed_job-2.1.4-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-closure-compiler-1.1.6-6.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-builder-2.1.2-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-thin-1.2.8-4.el6.x86_64 (epel) Requires: rubygems Error: Package: rubygem-compass-0.11.5-1.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-ruport-1.6.3-4.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-open4-1.3.0-5.el6.noarch (katello) Requires: ruby(rubygems) Error: Package: rubygem-fastercsv-1.5.4-1.el6.noarch (epel) Requires: rubygems Error: Package: rubygem-erubis-2.6.6-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-rails_warden-0.5.2-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-i18n-0.5.0-1.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-eventmachine-0.12.10-4.el6.x86_64 (epel) Requires: rubygems Error: Package: rubygem-multi_json-1.0.3-2.el6.noarch (katello) Requires: ruby(rubygems) >= 1.3.6 Error: Package: katello-common-1.1.5-1.git.24.212ceef.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-haml-3.1.2-1.el6.noarch (katello) Requires: rubygems Error: Package: 1:rubygem-activeresource-3.0.10-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-thor-0.14.6-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-acts_as_reportable-1.1.1-9.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-net-ldap-0.1.1-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-POpen4-0.1.4-1.el6.noarch (katello) Requires: ruby(rubygems) Error: Package: rubygem-rake-0.8.7-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-pg-0.12.2-2.el6.x86_64 (epel) Requires: rubygems Error: Package: rubygem-simple-navigation-3.3.4-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-bundler-1.0.15-3.el6.noarch (katello) Requires: rubygems Error: Package: 1:rubygem-rails-3.0.10-4.el6.noarch (katello) Requires: ruby(rubygems) >= 1.3.4 Error: Package: rubygem-compass-960-plugin-0.10.4-1.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-mail-2.3.0-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-yui-compressor-0.9.6-5.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-i18n_data-0.2.7-1.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-ldap_fluff-0.1.1-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-sass-3.1.4-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-color-1.4.1-6.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-activemodel-3.0.10-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-tzinfo-0.3.23-2.el6.noarch (katello) Requires: rubygems Error: Package: 1:rubygem-actionmailer-3.0.10-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-rack-mount-0.7.1-8.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-fssm-0.2.7-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-haml-rails-0.3.4-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-regin-0.3.8-4.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-chunky_png-1.2.0-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-warden-1.0.3-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-treetop-1.4.10-1.el6.noarch (epel) Requires: rubygems Error: Package: rubygem-Platform-0.4.0-1.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-arel-2.0.9-2.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-pdf-writer-1.1.8-6.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-hashr-0.0.21-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-daemons-1.1.4-3.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-rack-test-0.5.7-1.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-fast_gettext-0.5.10-2.el6.noarch (katello) Requires: rubygems Error: Package: 1:rubygem-actionpack-3.0.10-3.4.el6.noarch (katello) Requires: rubygems Error: Package: rubygem-tire-0.3.13-5.el6.noarch (katello) Requires: rubygems You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest + echo 'Initial configuration for Katello' -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From inecas at redhat.com Mon Aug 20 13:30:49 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 20 Aug 2012 15:30:49 +0200 Subject: [katello-devel] jammit for latest katello In-Reply-To: <1215904921.10149670.1345469271893.JavaMail.root@redhat.com> References: <1215904921.10149670.1345469271893.JavaMail.root@redhat.com> Message-ID: <50323C09.5010604@redhat.com> On 08/20/2012 03:27 PM, Og Maciel wrote: > # rpm -Uvh > http://fedorapeople.org/groups/katello/releases/yum/nightly/RHEL/6Server/x86_64/katello-repos-latest.rpm > # rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm > # yum-config-manager --enable rhel-6-server-optional-rpms > # yes|yum -y update > # yes|yum install -y katello-all > > Loaded plugins: product-id, security, subscription-manager > Updating certificate-based repositories. > http://fedorapeople.org/groups/katello/releases/yum/katello-foreman/%40SUBDIR%40/6Server/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404" > . > . > . > . > . > --> Processing Dependency: rubygems for package: rubygem-warden-1.0.3-2.el6.noarch > ---> Package rubygem-yui-compressor.noarch 0:0.9.6-5.el6 will be installed > --> Processing Dependency: rubygems for package: rubygem-yui-compressor-0.9.6-5.el6.noarch > --> Finished Dependency Resolution > Error: Package: rubygem-railties-3.0.10-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-oauth-0.4.4-1.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-json-1.4.6-1.el6.x86_64 (epel) > Requires: rubygems > Error: Package: rubygem-text-format-1.0.0-6.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-transaction-simple-1.4.0.2-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-rdoc-3.8-5.el6.noarch (katello) > Requires: rubygems > Error: Package: 1:rubygem-rack-1.3.0-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-polyglot-0.3.1-3.el6.noarch (katello) > Requires: rubygems > Error: Package: 1:rubygem-activerecord-3.0.10-6.el6.noarch (katello) > Requires: rubygems > Error: Package: 1:rubygem-activesupport-3.0.10-4.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-mime-types-1.16-3.el6.noarch (epel) > Requires: ruby(rubygems) > Error: Package: rubygem-jammit-0.6.5-8.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-rest-client-1.6.1-2.el6.noarch (epel) > Requires: rubygems > Error: Package: rubygem-apipie-rails-0.0.11-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-uuidtools-2.1.1-1.el6.noarch (epel) > Requires: ruby(rubygems) > Error: Package: rubygem-abstract-1.0.0-2.el6.noarch (epel) > Requires: ruby(rubygems) > Error: Package: rubygem-gettext_i18n_rails-0.2.13-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-delayed_job-2.1.4-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-closure-compiler-1.1.6-6.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-builder-2.1.2-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-thin-1.2.8-4.el6.x86_64 (epel) > Requires: rubygems > Error: Package: rubygem-compass-0.11.5-1.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-ruport-1.6.3-4.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-open4-1.3.0-5.el6.noarch (katello) > Requires: ruby(rubygems) > Error: Package: rubygem-fastercsv-1.5.4-1.el6.noarch (epel) > Requires: rubygems > Error: Package: rubygem-erubis-2.6.6-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-rails_warden-0.5.2-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-i18n-0.5.0-1.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-eventmachine-0.12.10-4.el6.x86_64 (epel) > Requires: rubygems > Error: Package: rubygem-multi_json-1.0.3-2.el6.noarch (katello) > Requires: ruby(rubygems) >= 1.3.6 > Error: Package: katello-common-1.1.5-1.git.24.212ceef.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-haml-3.1.2-1.el6.noarch (katello) > Requires: rubygems > Error: Package: 1:rubygem-activeresource-3.0.10-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-thor-0.14.6-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-acts_as_reportable-1.1.1-9.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-net-ldap-0.1.1-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-POpen4-0.1.4-1.el6.noarch (katello) > Requires: ruby(rubygems) > Error: Package: rubygem-rake-0.8.7-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-pg-0.12.2-2.el6.x86_64 (epel) > Requires: rubygems > Error: Package: rubygem-simple-navigation-3.3.4-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-bundler-1.0.15-3.el6.noarch (katello) > Requires: rubygems > Error: Package: 1:rubygem-rails-3.0.10-4.el6.noarch (katello) > Requires: ruby(rubygems) >= 1.3.4 > Error: Package: rubygem-compass-960-plugin-0.10.4-1.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-mail-2.3.0-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-yui-compressor-0.9.6-5.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-i18n_data-0.2.7-1.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-ldap_fluff-0.1.1-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-sass-3.1.4-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-color-1.4.1-6.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-activemodel-3.0.10-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-tzinfo-0.3.23-2.el6.noarch (katello) > Requires: rubygems > Error: Package: 1:rubygem-actionmailer-3.0.10-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-rack-mount-0.7.1-8.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-fssm-0.2.7-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-haml-rails-0.3.4-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-regin-0.3.8-4.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-chunky_png-1.2.0-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-warden-1.0.3-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-treetop-1.4.10-1.el6.noarch (epel) > Requires: rubygems > Error: Package: rubygem-Platform-0.4.0-1.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-arel-2.0.9-2.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-pdf-writer-1.1.8-6.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-hashr-0.0.21-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-daemons-1.1.4-3.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-rack-test-0.5.7-1.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-fast_gettext-0.5.10-2.el6.noarch (katello) > Requires: rubygems > Error: Package: 1:rubygem-actionpack-3.0.10-3.4.el6.noarch (katello) > Requires: rubygems > Error: Package: rubygem-tire-0.3.13-5.el6.noarch (katello) > Requires: rubygems > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > + echo 'Initial configuration for Katello' Do you have RHEL optional repo turned on? -- Ivan From omaciel at redhat.com Mon Aug 20 13:35:25 2012 From: omaciel at redhat.com (Og Maciel) Date: Mon, 20 Aug 2012 09:35:25 -0400 (EDT) Subject: [katello-devel] jammit for latest katello In-Reply-To: <50323C09.5010604@redhat.com> Message-ID: <1339458255.10214183.1345469725363.JavaMail.root@redhat.com> > Do you have RHEL optional repo turned on? Yup, it was the third command I ran (after adding 2 repos). :) -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From msuchy at redhat.com Mon Aug 20 14:07:07 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 20 Aug 2012 16:07:07 +0200 Subject: [katello-devel] jammit for latest katello In-Reply-To: <1215904921.10149670.1345469271893.JavaMail.root@redhat.com> References: <1215904921.10149670.1345469271893.JavaMail.root@redhat.com> Message-ID: <5032448B.7000307@redhat.com> On 08/20/2012 03:27 PM, Og Maciel wrote: > Loaded plugins: product-id, security, subscription-manager > Updating certificate-based repositories. > http://fedorapeople.org/groups/katello/releases/yum/katello-foreman/%40SUBDIR%40/6Server/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404" https://github.com/Katello/katello/pull/486 -- Miroslav Suchy Red Hat Systems Management Engineering From vvaldez at redhat.com Mon Aug 20 15:33:16 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Mon, 20 Aug 2012 10:33:16 -0500 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <5030F45F.3050907@redhat.com> References: <5006F35F.60008@redhat.com> <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> <5030F45F.3050907@redhat.com> Message-ID: <49F51B77-CCA8-4478-A1F6-4E6C8BCF6618@redhat.com> On Aug 19, 2012, at 9:12 AM, Bryan Kearney wrote: > On 08/18/2012 04:48 PM, Vinny Valdez wrote: >> On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: >> >>> Team, >>> >>> I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts >>> >>> We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. >>> >>> Thanks, >>> >>> Vinny >>> >>> >>> On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: >>> >>>> Do you want to be a star, and help promote Katello. Have we got a deal for you: >>>> >>>> https://fedorahosted.org/katello/wiki/Screencasts >>>> >>>> -- bk >>>> >>> >>> >> >> The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. >> >> http://people.redhat.com/vvaldez/videos/katello/ >> >> Regards, >> >> Vinny >> > This looks good! what software did you use to create this? There appears to be some text at the bottom when you log in which talks about the CLI? Is this the "how to do it in the CLI" version? > > -- bk > > Thanks everyone, I used ScreenFlow: http://www.telestream.net/screen-flow/ for recording and editing, Audacity for audio, and Openshot/Inkscape for the intro/outros. Yes, I was attempting to combine both the UI and CLI videos in one. I wasn't very explicit, but was trying to show the CLI commands at the same time the action was performed from the UI. Thoughts on that? Vinny From ehelms at redhat.com Mon Aug 20 15:38:23 2012 From: ehelms at redhat.com (Eric Helms) Date: Mon, 20 Aug 2012 11:38:23 -0400 (EDT) Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <49F51B77-CCA8-4478-A1F6-4E6C8BCF6618@redhat.com> Message-ID: <110687305.11601274.1345477103449.JavaMail.root@redhat.com> Vinny - if you will just let me know when you have the version you are satisfied with, I will download and upload and grant you the title of First Katello Screencaster. - Eric ----- Original Message ----- From: "Vinny Valdez" To: "Bryan Kearney" Cc: katello-devel at redhat.com Sent: Monday, August 20, 2012 11:33:16 AM Subject: Re: [katello-devel] Do you want to be a movie star? On Aug 19, 2012, at 9:12 AM, Bryan Kearney wrote: > On 08/18/2012 04:48 PM, Vinny Valdez wrote: >> On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: >> >>> Team, >>> >>> I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts >>> >>> We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. >>> >>> Thanks, >>> >>> Vinny >>> >>> >>> On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: >>> >>>> Do you want to be a star, and help promote Katello. Have we got a deal for you: >>>> >>>> https://fedorahosted.org/katello/wiki/Screencasts >>>> >>>> -- bk >>>> >>> >>> >> >> The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. >> >> http://people.redhat.com/vvaldez/videos/katello/ >> >> Regards, >> >> Vinny >> > This looks good! what software did you use to create this? There appears to be some text at the bottom when you log in which talks about the CLI? Is this the "how to do it in the CLI" version? > > -- bk > > Thanks everyone, I used ScreenFlow: http://www.telestream.net/screen-flow/ for recording and editing, Audacity for audio, and Openshot/Inkscape for the intro/outros. Yes, I was attempting to combine both the UI and CLI videos in one. I wasn't very explicit, but was trying to show the CLI commands at the same time the action was performed from the UI. Thoughts on that? Vinny _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Mon Aug 20 21:39:29 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 20 Aug 2012 14:39:29 -0700 Subject: [katello-devel] Content deletion merged to master Message-ID: <5032AE91.4000404@redhat.com> FYI this is merged: https://github.com/Katello/katello/pull/479 "NOTE: Once this is merged to master, developers must run 'rake db:migrate' to pick up the addition of 'type' to the changeset model. This is the initial merge of the content deletion feature to master. There is still more work to be done; however, we wanted to make the current functionality available to users. High-level summary: UI nav change - usage of 'Promotion' has been replaced with 'Changeset', since you may now create a promotion or deletion changeset. UI - ability to associate a type with a changeset (promotion/deletion) during changeset creation UI - ability to assign content to a changeset w/ behavior of content tree adjusting to the type of changeset being worked on UI - ability to support deletion of products, repos, pkgs, errata, distros and system templates UI - various changes to styling to handle the promotion vs deletion concept CLI/API - similar capabilities to the above, but from CLI/API point of view We do have some more testing/hardening to do; however, we'll address that with up upcoming pull requests. " -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From msuchy at redhat.com Tue Aug 21 07:01:15 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Tue, 21 Aug 2012 09:01:15 +0200 Subject: [katello-devel] Fwd: Re: is-it-fedora-ruby update In-Reply-To: <5032823E.40601@redhat.com> References: <5032823E.40601@redhat.com> Message-ID: <5033323B.8020605@redhat.com> FYI - I find it very useful. Mirek -------- Original Message -------- Subject: Re: is-it-fedora-ruby update Date: Mon, 20 Aug 2012 14:30:22 -0400 From: Mo Morsi Reply-To: Ruby SIG mailing list To: Ruby SIG mailing list CC: Zuhao On 07/16/2012 04:04 PM, Mo Morsi wrote: > Just a quick update regarding the Fedora/Ruby project Zuhao has been > working on as part of the Google Summer of Code. > > As many of you may remember, Zuhao has been working on a rails based > site to highlight the ruby sig's community's effort in packaging ruby > gems, developing ruby software, and overall improving the Ruby > experience on Fedora. Zuhao has made great headway with the project so > far, implementing Rake modules that allows us to pull the gem and rpm > packages into the local db as well as various frontend interfaces which > to display and cross-reference the gem / rpm metadata and other info > [1][2]. > > We just pushed the latest codebase to the site including the following features: - RPMs / Gems are now referenced by their name in the url, no need to remember the associated id: http://isitfedoraruby.com/fedorarpms/rubygem-activesupport - d3.js is used to render dependency and dependent packages: http://isitfedoraruby.com/fedorarpms/rubygem-actionmailer/full_deps (tree is clickable) - tool to compare an uploaded Gemfile / Gemfile.lock against Fedora: http://isitfedoraruby.com/stats/gemfile_tool - many ui improvements including sortable columns, Fedora / Ruby stats on the homepage, and more! As always, feedback and patches are more than welcome, -Mo _______________________________________________ ruby-sig mailing list ruby-sig at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig From lzap at redhat.com Tue Aug 21 07:12:17 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 21 Aug 2012 09:12:17 +0200 Subject: [katello-devel] Non-RHEL clients and bootstrapping In-Reply-To: <50322405.4000607@redhat.com> References: <20120820102419.GH3593@lzapx.brq.redhat.com> <50322405.4000607@redhat.com> Message-ID: <20120821071217.GB3972@lzapx.brq.redhat.com> On Mon, Aug 20, 2012 at 07:48:21AM -0400, Bryan Kearney wrote: > On 08/20/2012 06:24 AM, Lukas Zapletal wrote: > >Hello, > > > >on the user list there is a report from Scientific Linux. The bootstrap > >RPM cannot configure rhsm, I guess its because there is none on his > >system. > > > >So to support RHEL clones, we need to ask users to install both rhsm and > >katello client. We have not been telling this in our client installation > >wiki page, so I did this (quite a huge) change: > > > >https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient > > > >https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient?action=diff&version=27&old_version=26 > > > >Please test. > > > >I will also add a test in the post RPM script - if one of the components > >is not found, warning will be issued (currently it exits with error > >only). > > > >LZ > > > Should the configrpm require subscription-manager? No cos we do not deliver it and for RHEL clones this would give you error during install (unless there is a repo). What we could do is to deliver rhsm in our client Katello repository. Then it would work. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Aug 21 07:15:29 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 21 Aug 2012 09:15:29 +0200 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <49F51B77-CCA8-4478-A1F6-4E6C8BCF6618@redhat.com> References: <5006F35F.60008@redhat.com> <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> <5030F45F.3050907@redhat.com> <49F51B77-CCA8-4478-A1F6-4E6C8BCF6618@redhat.com> Message-ID: <20120821071529.GC3972@lzapx.brq.redhat.com> On Mon, Aug 20, 2012 at 10:33:16AM -0500, Vincent Valdez wrote: > Yes, I was attempting to combine both the UI and CLI videos in one. I > wasn't very explicit, but was trying to show the CLI commands at the > same time the action was performed from the UI. Thoughts on that? > Love that idea. -- Later, Lukas "lzap" Zapletal #katello #systemengine From ewoud+katello at kohlvanwijngaarden.nl Tue Aug 21 08:24:54 2012 From: ewoud+katello at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Tue, 21 Aug 2012 10:24:54 +0200 Subject: [katello-devel] Non-RHEL clients and bootstrapping In-Reply-To: <20120821071217.GB3972@lzapx.brq.redhat.com> References: <20120820102419.GH3593@lzapx.brq.redhat.com> <50322405.4000607@redhat.com> <20120821071217.GB3972@lzapx.brq.redhat.com> Message-ID: <20120821082454.GA9201@bogey.xentower.nl> On Tue, Aug 21, 2012 at 09:12:17AM +0200, Lukas Zapletal wrote: > On Mon, Aug 20, 2012 at 07:48:21AM -0400, Bryan Kearney wrote: > > On 08/20/2012 06:24 AM, Lukas Zapletal wrote: > > >Hello, > > > > > >on the user list there is a report from Scientific Linux. The bootstrap > > >RPM cannot configure rhsm, I guess its because there is none on his > > >system. > > > > > >So to support RHEL clones, we need to ask users to install both rhsm and > > >katello client. We have not been telling this in our client installation > > >wiki page, so I did this (quite a huge) change: > > > > > >https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient > > > > > >https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient?action=diff&version=27&old_version=26 > > > > > >Please test. > > > > > >I will also add a test in the post RPM script - if one of the components > > >is not found, warning will be issued (currently it exits with error > > >only). > > > > > >LZ > > > > > Should the configrpm require subscription-manager? > > No cos we do not deliver it and for RHEL clones this would give you > error during install (unless there is a repo). Why shouldn't it depend on it? The product does not work without subscription-manager and an error is imho a more user friendly. I'm a user and I would want my warning signs early on and it can't come earlier than the package manager. In fact, it's something that you also have to solve on the package manager level by adding a repository. From lzap at redhat.com Tue Aug 21 08:38:40 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 21 Aug 2012 10:38:40 +0200 Subject: [katello-devel] Planned Katello 1.0 update Message-ID: <20120821083840.GD3972@lzapx.brq.redhat.com> Hello, until now, we have discovered two blocker issues that breaks Katello functionality. They are listed at: https://fedorahosted.org/katello/wiki/ReleaseNotes10#KnownIssues The plan is to release an update of Katello 1.0 in near term. If you have any bug that is somehow blocking Katello users from doing what they need to do, please add them to the Known Issues section of the Release Notes with workaround description and BZ number and our release nanny for 1.0 will backport that fix into 1.0. :-) Typical issues are: - installation failure - registration/subscription error - login or major UI bugs Thanks! -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Aug 21 08:45:59 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 21 Aug 2012 10:45:59 +0200 Subject: [katello-devel] Non-RHEL clients and bootstrapping In-Reply-To: <20120821082454.GA9201@bogey.xentower.nl> References: <20120820102419.GH3593@lzapx.brq.redhat.com> <50322405.4000607@redhat.com> <20120821071217.GB3972@lzapx.brq.redhat.com> <20120821082454.GA9201@bogey.xentower.nl> Message-ID: <20120821084559.GE3972@lzapx.brq.redhat.com> On Tue, Aug 21, 2012 at 10:24:54AM +0200, Ewoud Kohl van Wijngaarden wrote: > > No cos we do not deliver it and for RHEL clones this would give you > > error during install (unless there is a repo). > > Why shouldn't it depend on it? The product does not work without > subscription-manager and an error is imho a more user friendly. I'm a > user and I would want my warning signs early on and it can't come > earlier than the package manager. In fact, it's something that you also > have to solve on the package manager level by adding a repository. I am not saying we must not add it. Just saying, if we want to do it, we need to start delivering rhsm and it's dependencies (python-rhsm) in our client repo. And by the way, it wont be picked up in Fedora and RHEL, only RHEL clones will need it. On the other hand, this gives us assurance there is some minimum version of RHSM IF users will add the client repo. They don't need to if they don't want to use Package Management features of Katello (e.g. SAM-like installation - only subscriptions). Then they can rely on rhsm from RHEL (or Fedora). Since it won't hurt, I guess we could add this on the next sprint: As a user, I'd like to have rhsm in katello client repo: - build rhsm - edit SystemsRegistration wiki page LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Aug 21 11:29:56 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 21 Aug 2012 13:29:56 +0200 Subject: [katello-devel] Org switcher during sign-in Message-ID: <20120821112955.GF3972@lzapx.brq.redhat.com> Hello, I like the org switcher during login, it's definitely nifty. But are there plans to automatically select organization when there is only one, skipping this screen effectively? If not, I can make the patch if there are no objections. -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Tue Aug 21 12:13:25 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 21 Aug 2012 08:13:25 -0400 Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <20120821112955.GF3972@lzapx.brq.redhat.com> References: <20120821112955.GF3972@lzapx.brq.redhat.com> Message-ID: <50337B65.4010109@redhat.com> On 08/21/2012 07:29 AM, Lukas Zapletal wrote: > Hello, > > I like the org switcher during login, it's definitely nifty. But are > there plans to automatically select organization when there is only one, > skipping this screen effectively? > > If not, I can make the patch if there are no objections. > I could have sworn I put a bug in for this.. .but I guess not. I would love to see a patch for 0 or 1 orgs. -- bk From jrist at redhat.com Tue Aug 21 12:17:28 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 21 Aug 2012 08:17:28 -0400 (EDT) Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <50337B65.4010109@redhat.com> References: <20120821112955.GF3972@lzapx.brq.redhat.com> <50337B65.4010109@redhat.com> Message-ID: <45D5FB0B-1561-4A3A-BC1A-4EE502D699AB@redhat.com> It is on this sprint and almost ready but delayed by travel to Boston. -J On Aug 21, 2012, at 8:12, Bryan Kearney wrote: > On 08/21/2012 07:29 AM, Lukas Zapletal wrote: >> Hello, >> >> I like the org switcher during login, it's definitely nifty. But are >> there plans to automatically select organization when there is only one, >> skipping this screen effectively? >> >> If not, I can make the patch if there are no objections. >> > I could have sworn I put a bug in for this.. .but I guess not. I would love to see a patch for 0 or 1 orgs. > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From esammons at redhat.com Tue Aug 21 12:18:41 2012 From: esammons at redhat.com (Eric Sammons) Date: Tue, 21 Aug 2012 08:18:41 -0400 (EDT) Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <50337B65.4010109@redhat.com> Message-ID: <845812666.16368480.1345551521277.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/21/2012 07:29 AM, Lukas Zapletal wrote: > > Hello, > > > > I like the org switcher during login, it's definitely nifty. But > > are > > there plans to automatically select organization when there is only > > one, > > skipping this screen effectively? > > > > If not, I can make the patch if there are no objections. > > > I could have sworn I put a bug in for this.. .but I guess not. I > would > love to see a patch for 0 or 1 orgs. > > -- bk I would like to make sure that where a default org is set the org switcher is skipped and you are taken to your default, if due to roles restrictions you only have access to one org that the org switcher be skipped, and I'd like to see when only one org exists that the org switcher is skipped. In addition, and I need to open a bug for this, I would like feed back when I select an org. Today when you select an org the org field is not populated, instead the org switcher drop down remains open and the org hi-lighted will not remain hi-lighted thus no feedback that I actually have selected an org. --Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From bkearney at redhat.com Tue Aug 21 12:23:55 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 21 Aug 2012 08:23:55 -0400 Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <845812666.16368480.1345551521277.JavaMail.root@redhat.com> References: <845812666.16368480.1345551521277.JavaMail.root@redhat.com> Message-ID: <50337DDB.6030604@redhat.com> On 08/21/2012 08:18 AM, Eric Sammons wrote: > > > ----- Original Message ----- >> On 08/21/2012 07:29 AM, Lukas Zapletal wrote: >>> Hello, >>> >>> I like the org switcher during login, it's definitely nifty. But >>> are >>> there plans to automatically select organization when there is only >>> one, >>> skipping this screen effectively? >>> >>> If not, I can make the patch if there are no objections. >>> >> I could have sworn I put a bug in for this.. .but I guess not. I >> would >> love to see a patch for 0 or 1 orgs. >> >> -- bk > > I would like to make sure that where a default org is set the org switcher is skipped and you are taken to your default, if due to roles restrictions you only have access to one org that the org switcher be skipped, and I'd like to see when only one org exists that the org switcher is skipped. In addition, and I need to open a bug for this, I would like feed back when I select an org. Today when you select an org the org field is not populated, instead the org switcher drop down remains open and the org hi-lighted will not remain hi-lighted thus no feedback that I actually have selected an org. > I had not thought about the default org. Would that cause you to skip, or just select it? -- bk From bkearney at redhat.com Tue Aug 21 12:32:35 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 21 Aug 2012 08:32:35 -0400 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <49F51B77-CCA8-4478-A1F6-4E6C8BCF6618@redhat.com> References: <5006F35F.60008@redhat.com> <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> <5030F45F.3050907@redhat.com> <49F51B77-CCA8-4478-A1F6-4E6C8BCF6618@redhat.com> Message-ID: <50337FE3.9060302@redhat.com> On 08/20/2012 11:33 AM, Vinny Valdez wrote: > On Aug 19, 2012, at 9:12 AM, Bryan Kearney wrote: > >> On 08/18/2012 04:48 PM, Vinny Valdez wrote: >>> On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: >>> >>>> Team, >>>> >>>> I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts >>>> >>>> We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. >>>> >>>> Thanks, >>>> >>>> Vinny >>>> >>>> >>>> On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: >>>> >>>>> Do you want to be a star, and help promote Katello. Have we got a deal for you: >>>>> >>>>> https://fedorahosted.org/katello/wiki/Screencasts >>>>> >>>>> -- bk >>>>> >>>> >>>> >>> >>> The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. >>> >>> http://people.redhat.com/vvaldez/videos/katello/ >>> >>> Regards, >>> >>> Vinny >>> >> This looks good! what software did you use to create this? There appears to be some text at the bottom when you log in which talks about the CLI? Is this the "how to do it in the CLI" version? >> >> -- bk >> >> > > Thanks everyone, > > I used ScreenFlow: http://www.telestream.net/screen-flow/ for recording and editing, Audacity for audio, and Openshot/Inkscape for the intro/outros. So.. recorded on a mac? > > Yes, I was attempting to combine both the UI and CLI videos in one. I wasn't very explicit, but was trying to show the CLI commands at the same time the action was performed from the UI. Thoughts on that? I liked the model. -- bk From esammons at redhat.com Tue Aug 21 12:45:34 2012 From: esammons at redhat.com (Eric Sammons) Date: Tue, 21 Aug 2012 08:45:34 -0400 (EDT) Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <50337DDB.6030604@redhat.com> Message-ID: <715088857.16383206.1345553134982.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/21/2012 08:18 AM, Eric Sammons wrote: > > > > > > ----- Original Message ----- > >> On 08/21/2012 07:29 AM, Lukas Zapletal wrote: > >>> Hello, > >>> > >>> I like the org switcher during login, it's definitely nifty. But > >>> are > >>> there plans to automatically select organization when there is > >>> only > >>> one, > >>> skipping this screen effectively? > >>> > >>> If not, I can make the patch if there are no objections. > >>> > >> I could have sworn I put a bug in for this.. .but I guess not. I > >> would > >> love to see a patch for 0 or 1 orgs. > >> > >> -- bk > > > > I would like to make sure that where a default org is set the org > > switcher is skipped and you are taken to your default, if due to > > roles restrictions you only have access to one org that the org > > switcher be skipped, and I'd like to see when only one org exists > > that the org switcher is skipped. In addition, and I need to open > > a bug for this, I would like feed back when I select an org. > > Today when you select an org the org field is not populated, > > instead the org switcher drop down remains open and the org > > hi-lighted will not remain hi-lighted thus no feedback that I > > actually have selected an org. > > > I had not thought about the default org. Would that cause you to > skip, > or just select it? > > -- bk Because you can still switch your org from within the application, I would think that having a default org would put you in that org by default, thus skipping the org switcher. Again, once logged in and in your default org, if you are entitled to other orgs then you can switch to that org. --Eric From jrist at redhat.com Tue Aug 21 13:09:11 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 21 Aug 2012 09:09:11 -0400 Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <845812666.16368480.1345551521277.JavaMail.root@redhat.com> References: <845812666.16368480.1345551521277.JavaMail.root@redhat.com> Message-ID: <50338877.6010109@redhat.com> On 08/21/2012 08:18 AM, Eric Sammons wrote: > > > ----- Original Message ----- >> On 08/21/2012 07:29 AM, Lukas Zapletal wrote: >>> Hello, >>> >>> I like the org switcher during login, it's definitely nifty. But >>> are >>> there plans to automatically select organization when there is only >>> one, >>> skipping this screen effectively? >>> >>> If not, I can make the patch if there are no objections. >>> >> I could have sworn I put a bug in for this.. .but I guess not. I >> would >> love to see a patch for 0 or 1 orgs. >> >> -- bk > > I would like to make sure that where a default org is set the org switcher is skipped and you are taken to your default, if due to roles restrictions you only have access to one org that the org switcher be skipped, and I'd like to see when only one org exists that the org switcher is skipped. In addition, and I need to open a bug for this, I would like feed back when I select an org. Today when you select an org the org field is not populated, instead the org switcher drop down remains open and the org hi-lighted will not remain hi-lighted thus no feedback that I actually have selected an org. > > --Eric > > >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > There is now feedback as of current master, Eric. That bugged me too :) -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From hbrock at redhat.com Tue Aug 21 13:52:49 2012 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 21 Aug 2012 09:52:49 -0400 Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <1637699023.9372537.1344949971111.JavaMail.root@redhat.com> References: <502A499F.9050409@redhat.com> <1637699023.9372537.1344949971111.JavaMail.root@redhat.com> Message-ID: <20120821135249.GA15992@redhat.com> On Tue, Aug 14, 2012 at 09:12:51AM -0400, James Labocki wrote: > > ----- Original Message ----- > > From: "Bryan Kearney" > > To: aeolus-devel at lists.fedorahosted.org, katello-devel at redhat.com > > Sent: Tuesday, August 14, 2012 8:50:39 AM > > Subject: Re: [katello-devel] Deployable and System Template Portability > > > > On 08/14/2012 05:26 AM, Dmitri Dolguikh wrote: > > > On 13/08/12 07:30 PM, James Labocki wrote: > > >> Sorry for posting across both lists, but this involves both aeolus > > >> and katello. > > >> > > >> Last week a few of us were discussing the ability to import/export > > >> deployables within aeolus for sharing between differing > > >> implementations. > > >> > > >> The attached photo 1.JPG provides a high level diagram of some of > > >> the problems we believe exist in achieving this today. Please > > >> note that I used enterprise nomenclature, so I think that: > > >> > > >> - System Engine = Katello > > >> - Component Outline = Assembly > > >> - Blueprint = Deployable > > >> - AppForm = Deployment > > > > With Foreman Integration, the goal is to kill templates and model > > component outlines off of Foreman Host Groups. > > I'd like to see both these models supported in the future, is this the thinking behind using host groups or will it only support one of the scenarios? > > Description + Host Group ==> Build ==> Configured Image ==> Push to Provider > Configured Image at Provider ==> Launch ==> Connect back to Katello and make further changes to Host Group > > OR > > Description ==> Build ==> Unconfigured Image ==> Push to Provider > Unconfigured Image at Provider ==> Launch ==> Connect back to Katello and make all changes based on Host Group Hello James, thanks for bringing this stuff up. We need to support both of these cases, I am aware of specific customer demand for both. Bryan and I have been oversimplifying and referring to them as "image-based" (the first one) and "build-based" (the second one). > > >> We found the following areas differ between implementations and > > >> would need to be accounted for. Note this this was not an > > >> exhaustive exercise and I'm sure we missed some areas. > > >> > > >> - Providers paths are different in katello > > >> - Certificates are different in system templates > > >> - Repositories are different in system templates > > >> - Deployables and their services are tightly coupled (not > > >> shareable) > > >> - Clouds, Cloud Resource Zones, and Catalogs are different in > > >> aeolus > > >> > > > > Can you give examples of these issues? I would assume the TDL we are > > generating is valid. > > >From reply to Ivan earlier plus more information. > > Customer A installs katello and creates Custom ProviderX with ProductY and RepoZ > Customer B installs katello and creates Custom ProviderA with ProductB and RepoC > > Customer A creates system template which references RepoZ, hands system template to Customer B. > Customer B takes system template and imports it into his/her aeolus. The custom provider is does not exist in his system engine (assuming he changes the path the system engine host in the template) and the certs don't match. > > On the Aeolus side: > > Image ID's don't match in the application blueprint that Customer A would share with Customer B which would contain the multiple images that make up an application. Also, services in the application blueprint will likely call environment specific variables which are not abstracted from the service. We have been talking for a long time about the need for an image abstraction in Aeolus that would let you reference an image by name rather than UUID, such that as long as you have an image named "abc" in your environment, then a deployable can find that image and use it. Having said that, this image naming thing gets very quickly into service definitions, a la Cloud Formations. My Cloud Formations app might reference three services by well-known names, and it's the responsibility of the underlying infrastructure to either point the app to the right services or spin up instances that provide them. We don't have this capability right now with Aeolus, of course, but we are discussing various ways to get there. In the meantime I would at the very least like to see us look at some kind of abstraction for image names, repo names, and provider names. Does that seem like it would solve the majority of these issues? --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 mrao at redhat.com Tue Aug 21 14:32:24 2012 From: mrao at redhat.com (Malini Rao) Date: Tue, 21 Aug 2012 10:32:24 -0400 (EDT) Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <50338877.6010109@redhat.com> Message-ID: <1482273819.143364.1345559544001.JavaMail.root@redhat.com> ----- Original Message ----- From: "Jason Rist" To: katello-devel at redhat.com Sent: Tuesday, August 21, 2012 9:09:11 AM Subject: Re: [katello-devel] Org switcher during sign-in On 08/21/2012 08:18 AM, Eric Sammons wrote: > > > ----- Original Message ----- >> On 08/21/2012 07:29 AM, Lukas Zapletal wrote: >>> Hello, >>> >>> I like the org switcher during login, it's definitely nifty. But >>> are >>> there plans to automatically select organization when there is only >>> one, >>> skipping this screen effectively? >>> >>> If not, I can make the patch if there are no objections. >>> >> I could have sworn I put a bug in for this.. .but I guess not. I >> would >> love to see a patch for 0 or 1 orgs. >> >> -- bk > > I would like to make sure that where a default org is set the org switcher is skipped and you are taken to your default, if due to roles restrictions you only have access to one org that the org switcher be skipped, and I'd like to see when only one org exists that the org switcher is skipped. In addition, and I need to open a bug for this, I would like feed back when I select an org. Today when you select an org the org field is not populated, instead the org switcher drop down remains open and the org hi-lighted will not remain hi-lighted thus no feedback that I actually have selected an org. > > --Eric > > >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > There is now feedback as of current master, Eric. That bugged me too :) > -J +1 to these changes - When there is a default org set for a user, they should not have to choose it during log in or on the landing page. If there is only one org, they should not need to select it either. Less important but for fit and finish, can we adjust the minimum size of the Org drop down to fit exactly when there are less than 4 orgs ( which seems to be the current minimum height) - so if there is only one, there is no white space between it and the 'manage organizations' link? Also, when you do go to the manage organizations page and then drop the org switcher down, the org switcher panel is displaying behind the left panel of the 2 pane in the version I am accessing. This is clearly a bug and not sure if it is already logged. Thanks Malini -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From esammons at redhat.com Tue Aug 21 14:38:03 2012 From: esammons at redhat.com (Eric Sammons) Date: Tue, 21 Aug 2012 10:38:03 -0400 (EDT) Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <50338877.6010109@redhat.com> Message-ID: <1578989373.16484602.1345559883580.JavaMail.root@redhat.com> > > There is now feedback as of current master, Eric. That bugged me too > :) > -J > Well darn I just opened a bug... o'well I guess it will get closed quickly :-D --Eric From esammons at redhat.com Tue Aug 21 14:41:39 2012 From: esammons at redhat.com (Eric Sammons) Date: Tue, 21 Aug 2012 10:41:39 -0400 (EDT) Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <1482273819.143364.1345559544001.JavaMail.root@redhat.com> Message-ID: <1749029290.16486174.1345560099036.JavaMail.root@redhat.com> > > +1 to these changes - When there is a default org set for a user, > they should not have to choose it during log in or on the landing > page. If there is only one org, they should not need to select it > either. Less important but for fit and finish, can we adjust the > minimum size of the Org drop down to fit exactly when there are less > than 4 orgs ( which seems to be the current minimum height) - so if > there is only one, there is no white space between it and the > 'manage organizations' link? Also, when you do go to the manage > organizations page and then drop the org switcher down, the org > switcher panel is displaying behind the left panel of the 2 pane in > the version I am accessing. This is clearly a bug and not sure if it > is already logged. > > Thanks > Malini > As a side, I'm sure folks are aware of this, the org switcher is actually over-laying the login page. If I wanted to I believe I could actually use code to access the hidden password field and other elements that become hidden once the org switcher "rolls in". (I have not tested but I have seen the elements in firebug which means libraries like selenium, BeautifulSoup, etc... should be able to access them). --Eric From jrist at redhat.com Tue Aug 21 14:43:23 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 21 Aug 2012 10:43:23 -0400 Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <1749029290.16486174.1345560099036.JavaMail.root@redhat.com> References: <1482273819.143364.1345559544001.JavaMail.root@redhat.com> <1749029290.16486174.1345560099036.JavaMail.root@redhat.com> Message-ID: <50339E8B.1060406@redhat.com> On Tue 21 Aug 2012 10:41:39 AM EDT, Eric Sammons wrote: > >> >> +1 to these changes - When there is a default org set for a user, >> they should not have to choose it during log in or on the landing >> page. If there is only one org, they should not need to select it >> either. Less important but for fit and finish, can we adjust the >> minimum size of the Org drop down to fit exactly when there are less >> than 4 orgs ( which seems to be the current minimum height) - so if >> there is only one, there is no white space between it and the >> 'manage organizations' link? Also, when you do go to the manage >> organizations page and then drop the org switcher down, the org >> switcher panel is displaying behind the left panel of the 2 pane in >> the version I am accessing. This is clearly a bug and not sure if it >> is already logged. >> >> Thanks >> Malini >> > > As a side, I'm sure folks are aware of this, the org switcher is actually over-laying the login page. If I wanted to I believe I could actually use code to access the hidden password field and other elements that become hidden once the org switcher "rolls in". (I have not tested but I have seen the elements in firebug which means libraries like selenium, BeautifulSoup, etc... should be able to access them). > > --Eric Is this a problem? Should we be "deleting" that node from the view upon submission? -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From esammons at redhat.com Tue Aug 21 14:45:17 2012 From: esammons at redhat.com (Eric Sammons) Date: Tue, 21 Aug 2012 10:45:17 -0400 (EDT) Subject: [katello-devel] Org switcher during sign-in In-Reply-To: <50339E8B.1060406@redhat.com> Message-ID: <203557518.16489558.1345560317871.JavaMail.root@redhat.com> ----- Original Message ----- > On Tue 21 Aug 2012 10:41:39 AM EDT, Eric Sammons wrote: > > > >> > >> +1 to these changes - When there is a default org set for a user, > >> they should not have to choose it during log in or on the landing > >> page. If there is only one org, they should not need to select it > >> either. Less important but for fit and finish, can we adjust the > >> minimum size of the Org drop down to fit exactly when there are > >> less > >> than 4 orgs ( which seems to be the current minimum height) - so > >> if > >> there is only one, there is no white space between it and the > >> 'manage organizations' link? Also, when you do go to the manage > >> organizations page and then drop the org switcher down, the org > >> switcher panel is displaying behind the left panel of the 2 pane > >> in > >> the version I am accessing. This is clearly a bug and not sure if > >> it > >> is already logged. > >> > >> Thanks > >> Malini > >> > > > > As a side, I'm sure folks are aware of this, the org switcher is > > actually over-laying the login page. If I wanted to I believe I > > could actually use code to access the hidden password field and > > other elements that become hidden once the org switcher "rolls > > in". (I have not tested but I have seen the elements in firebug > > which means libraries like selenium, BeautifulSoup, etc... should > > be able to access them). > > > > --Eric > > Is this a problem? Should we be "deleting" that node from the view > upon > submission? I do not believe it to be a problem, at least I have not hit one yet, more of a FYI. I'm not a web security guy so not sure if it could be a issue or not from a security pov. --Eric From ehelms at redhat.com Tue Aug 21 15:31:43 2012 From: ehelms at redhat.com (Eric Helms) Date: Tue, 21 Aug 2012 11:31:43 -0400 (EDT) Subject: [katello-devel] Katello-Foreman Integration API Layer Question Message-ID: <1305621601.12178479.1345563103827.JavaMail.root@redhat.com> A question after seeing the current progress of the Foreman integration work around the API layer. This is inspired by some thoughts we've had around the Pulp v2 migrations. Has any thought been given to generating a separate library/gem/project for the API part? Since this would be a re-usable component by potentially other communities and present a nice, clean set of ruby bindings for the Foreman APIs that we could consume (as well as others). - Eric From vvaldez at redhat.com Tue Aug 21 15:33:40 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Tue, 21 Aug 2012 10:33:40 -0500 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <50337FE3.9060302@redhat.com> References: <5006F35F.60008@redhat.com> <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> <5030F45F.3050907@redhat.com> <49F51B77-CCA8-4478-A1F6-4E6C8BCF6618@redhat.com> <50337FE3.9060302@redhat.com> Message-ID: On Aug 21, 2012, at 7:32 AM, Bryan Kearney wrote: > On 08/20/2012 11:33 AM, Vinny Valdez wrote: >> On Aug 19, 2012, at 9:12 AM, Bryan Kearney wrote: >> >>> On 08/18/2012 04:48 PM, Vinny Valdez wrote: >>>> On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: >>>> >>>>> Team, >>>>> >>>>> I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts >>>>> >>>>> We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. >>>>> >>>>> Thanks, >>>>> >>>>> Vinny >>>>> >>>>> >>>>> On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: >>>>> >>>>>> Do you want to be a star, and help promote Katello. Have we got a deal for you: >>>>>> >>>>>> https://fedorahosted.org/katello/wiki/Screencasts >>>>>> >>>>>> -- bk >>>>>> >>>>> >>>>> >>>> >>>> The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. >>>> >>>> http://people.redhat.com/vvaldez/videos/katello/ >>>> >>>> Regards, >>>> >>>> Vinny >>>> >>> This looks good! what software did you use to create this? There appears to be some text at the bottom when you log in which talks about the CLI? Is this the "how to do it in the CLI" version? >>> >>> -- bk >>> >>> >> >> Thanks everyone, >> >> I used ScreenFlow: http://www.telestream.net/screen-flow/ for recording and editing, Audacity for audio, and Openshot/Inkscape for the intro/outros. > So.. recorded on a mac? > Yes, I used a F16 VM to do everything, and just cropped out the rest of the desktop. Is that an issue? I can re-record in RecordMyDesktop or ffmpeg directly, but there will be very few effects I can replicate, and the entire process will take much longer. >> >> Yes, I was attempting to combine both the UI and CLI videos in one. I wasn't very explicit, but was trying to show the CLI commands at the same time the action was performed from the UI. Thoughts on that? > > I liked the model. > Great, I'll move forward on the others the same way. Vinny > -- bk > From bkearney at redhat.com Tue Aug 21 16:03:01 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 21 Aug 2012 12:03:01 -0400 Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <1305621601.12178479.1345563103827.JavaMail.root@redhat.com> References: <1305621601.12178479.1345563103827.JavaMail.root@redhat.com> Message-ID: <5033B135.2050403@redhat.com> On 08/21/2012 11:31 AM, Eric Helms wrote: > A question after seeing the current progress of the Foreman integration work around the API layer. This is inspired by some thoughts we've had around the Pulp v2 migrations. > > Has any thought been given to generating a separate library/gem/project for the API part? Since this would be a re-usable component by potentially other communities and present a nice, clean set of ruby bindings for the Foreman APIs that we could consume (as well as others). > > - Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > Yes, this work is resulting in a new /api namespace and new ruby bindings. -- bk From bkearney at redhat.com Tue Aug 21 16:05:36 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 21 Aug 2012 12:05:36 -0400 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: References: <5006F35F.60008@redhat.com> <344DA588-EC04-4299-A242-5FE69D6C354A@redhat.com> <5030F45F.3050907@redhat.com> <49F51B77-CCA8-4478-A1F6-4E6C8BCF6618@redhat.com> <50337FE3.9060302@redhat.com> Message-ID: <5033B1D0.6090608@redhat.com> On 08/21/2012 11:33 AM, Vinny Valdez wrote: > On Aug 21, 2012, at 7:32 AM, Bryan Kearney wrote: > >> On 08/20/2012 11:33 AM, Vinny Valdez wrote: >>> On Aug 19, 2012, at 9:12 AM, Bryan Kearney wrote: >>> >>>> On 08/18/2012 04:48 PM, Vinny Valdez wrote: >>>>> On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: >>>>> >>>>>> Team, >>>>>> >>>>>> I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts >>>>>> >>>>>> We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Vinny >>>>>> >>>>>> >>>>>> On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: >>>>>> >>>>>>> Do you want to be a star, and help promote Katello. Have we got a deal for you: >>>>>>> >>>>>>> https://fedorahosted.org/katello/wiki/Screencasts >>>>>>> >>>>>>> -- bk >>>>>>> >>>>>> >>>>>> >>>>> >>>>> The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. >>>>> >>>>> http://people.redhat.com/vvaldez/videos/katello/ >>>>> >>>>> Regards, >>>>> >>>>> Vinny >>>>> >>>> This looks good! what software did you use to create this? There appears to be some text at the bottom when you log in which talks about the CLI? Is this the "how to do it in the CLI" version? >>>> >>>> -- bk >>>> >>>> >>> >>> Thanks everyone, >>> >>> I used ScreenFlow: http://www.telestream.net/screen-flow/ for recording and editing, Audacity for audio, and Openshot/Inkscape for the intro/outros. >> So.. recorded on a mac? >> > Yes, I used a F16 VM to do everything, and just cropped out the rest of the desktop. Is that an issue? I can re-record in RecordMyDesktop or ffmpeg directly, but there will be very few effects I can replicate, and the entire process will take much longer. Not an issue, was just curious. > >>> >>> Yes, I was attempting to combine both the UI and CLI videos in one. I wasn't very explicit, but was trying to show the CLI commands at the same time the action was performed from the UI. Thoughts on that? >> >> I liked the model. >> > Great, I'll move forward on the others the same way. Cool! Eric, have we posted this yet? -- bk From ehelms at redhat.com Tue Aug 21 16:17:27 2012 From: ehelms at redhat.com (Eric Helms) Date: Tue, 21 Aug 2012 12:17:27 -0400 (EDT) Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <5033B1D0.6090608@redhat.com> Message-ID: <1394860223.12209501.1345565847192.JavaMail.root@redhat.com> We have not - was waiting on the green light from Vinny. - Eric ----- Original Message ----- From: "Bryan Kearney" To: "Vinny Valdez" Cc: katello-devel at redhat.com Sent: Tuesday, August 21, 2012 12:05:36 PM Subject: Re: [katello-devel] Do you want to be a movie star? On 08/21/2012 11:33 AM, Vinny Valdez wrote: > On Aug 21, 2012, at 7:32 AM, Bryan Kearney wrote: > >> On 08/20/2012 11:33 AM, Vinny Valdez wrote: >>> On Aug 19, 2012, at 9:12 AM, Bryan Kearney wrote: >>> >>>> On 08/18/2012 04:48 PM, Vinny Valdez wrote: >>>>> On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: >>>>> >>>>>> Team, >>>>>> >>>>>> I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts >>>>>> >>>>>> We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Vinny >>>>>> >>>>>> >>>>>> On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: >>>>>> >>>>>>> Do you want to be a star, and help promote Katello. Have we got a deal for you: >>>>>>> >>>>>>> https://fedorahosted.org/katello/wiki/Screencasts >>>>>>> >>>>>>> -- bk >>>>>>> >>>>>> >>>>>> >>>>> >>>>> The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. >>>>> >>>>> http://people.redhat.com/vvaldez/videos/katello/ >>>>> >>>>> Regards, >>>>> >>>>> Vinny >>>>> >>>> This looks good! what software did you use to create this? There appears to be some text at the bottom when you log in which talks about the CLI? Is this the "how to do it in the CLI" version? >>>> >>>> -- bk >>>> >>>> >>> >>> Thanks everyone, >>> >>> I used ScreenFlow: http://www.telestream.net/screen-flow/ for recording and editing, Audacity for audio, and Openshot/Inkscape for the intro/outros. >> So.. recorded on a mac? >> > Yes, I used a F16 VM to do everything, and just cropped out the rest of the desktop. Is that an issue? I can re-record in RecordMyDesktop or ffmpeg directly, but there will be very few effects I can replicate, and the entire process will take much longer. Not an issue, was just curious. > >>> >>> Yes, I was attempting to combine both the UI and CLI videos in one. I wasn't very explicit, but was trying to show the CLI commands at the same time the action was performed from the UI. Thoughts on that? >> >> I liked the model. >> > Great, I'll move forward on the others the same way. Cool! Eric, have we posted this yet? -- bk _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From vvaldez at redhat.com Tue Aug 21 17:05:32 2012 From: vvaldez at redhat.com (Vincent Valdez) Date: Tue, 21 Aug 2012 13:05:32 -0400 (EDT) Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <1394860223.12209501.1345565847192.JavaMail.root@redhat.com> References: <1394860223.12209501.1345565847192.JavaMail.root@redhat.com> Message-ID: <740C557F-F7C5-487A-BFD5-E620114D04EC@redhat.com> I'm tweaking a couple things, should be ready tonight. Vinny On Aug 21, 2012, at 11:17 AM, Eric Helms wrote: > We have not - was waiting on the green light from Vinny. > > - Eric > > ----- Original Message ----- > From: "Bryan Kearney" > To: "Vinny Valdez" > Cc: katello-devel at redhat.com > Sent: Tuesday, August 21, 2012 12:05:36 PM > Subject: Re: [katello-devel] Do you want to be a movie star? > > On 08/21/2012 11:33 AM, Vinny Valdez wrote: >> On Aug 21, 2012, at 7:32 AM, Bryan Kearney wrote: >> >>> On 08/20/2012 11:33 AM, Vinny Valdez wrote: >>>> On Aug 19, 2012, at 9:12 AM, Bryan Kearney wrote: >>>> >>>>> On 08/18/2012 04:48 PM, Vinny Valdez wrote: >>>>>> On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: >>>>>> >>>>>>> Team, >>>>>>> >>>>>>> I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts >>>>>>> >>>>>>> We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Vinny >>>>>>> >>>>>>> >>>>>>> On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: >>>>>>> >>>>>>>> Do you want to be a star, and help promote Katello. Have we got a deal for you: >>>>>>>> >>>>>>>> https://fedorahosted.org/katello/wiki/Screencasts >>>>>>>> >>>>>>>> -- bk >>>>>> >>>>>> The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. >>>>>> >>>>>> http://people.redhat.com/vvaldez/videos/katello/ >>>>>> >>>>>> Regards, >>>>>> >>>>>> Vinny >>>>> This looks good! what software did you use to create this? There appears to be some text at the bottom when you log in which talks about the CLI? Is this the "how to do it in the CLI" version? >>>>> >>>>> -- bk >>>> >>>> Thanks everyone, >>>> >>>> I used ScreenFlow: http://www.telestream.net/screen-flow/ for recording and editing, Audacity for audio, and Openshot/Inkscape for the intro/outros. >>> So.. recorded on a mac? >> Yes, I used a F16 VM to do everything, and just cropped out the rest of the desktop. Is that an issue? I can re-record in RecordMyDesktop or ffmpeg directly, but there will be very few effects I can replicate, and the entire process will take much longer. > > Not an issue, was just curious. > >> >>>> >>>> Yes, I was attempting to combine both the UI and CLI videos in one. I wasn't very explicit, but was trying to show the CLI commands at the same time the action was performed from the UI. Thoughts on that? >>> >>> I liked the model. >> Great, I'll move forward on the others the same way. > > Cool! Eric, have we posted this yet? > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From ehelms at redhat.com Tue Aug 21 18:44:14 2012 From: ehelms at redhat.com (Eric Helms) Date: Tue, 21 Aug 2012 14:44:14 -0400 (EDT) Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <5033B135.2050403@redhat.com> Message-ID: <1858040011.12284235.1345574654206.JavaMail.root@redhat.com> To clarify a bit, in Katello today, the ruby bindings (for both Pulp and Candlepin) are tied to Katello code and we are working to change that as we do our Pulp V2 migration work. I.E. create a stand-alone set of ruby-bindings to Pulp that Katello can consume. But are we doing the same with Foreman? A good example of what I mean is Funzo's project deadwood for Katello - https://github.com/calfonso/deadwood -Eric ----- Original Message ----- From: "Bryan Kearney" To: katello-devel at redhat.com Sent: Tuesday, August 21, 2012 12:03:01 PM Subject: Re: [katello-devel] Katello-Foreman Integration API Layer Question On 08/21/2012 11:31 AM, Eric Helms wrote: > A question after seeing the current progress of the Foreman integration work around the API layer. This is inspired by some thoughts we've had around the Pulp v2 migrations. > > Has any thought been given to generating a separate library/gem/project for the API part? Since this would be a re-usable component by potentially other communities and present a nice, clean set of ruby bindings for the Foreman APIs that we could consume (as well as others). > > - Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > Yes, this work is resulting in a new /api namespace and new ruby bindings. -- bk _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From jsherril at redhat.com Tue Aug 21 18:48:56 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 21 Aug 2012 14:48:56 -0400 Subject: [katello-devel] Foreman integration model question Message-ID: <5033D818.5090203@redhat.com> Hi All, After the demo this morning I got the hankering to look at some of the integration code, which I believe is in the foreman_architectures branch. Poking around the models (https://github.com/Katello/katello/tree/foreman_architectures/src/app/models) I see an entirely different way of orchestrating things than we have done for pulp/candlepin. Taking user for example we would have: user.rb glue/pulp/user.rb Where the katello user object would include the glue/pulp/user module. The orchestration would all be there, but it would really be a single class for user that spans both systems. What I see with foreman is: user.rb glue/foreman/user.rb foreman/user.rb Where foreman/user is a second class that can be instantiated and used on its own, while glue/foreman/user.rb is simply the orchestration to create that object. I see the use of Resources::ForemanModel, but in this user instance the foreman user could be manipulated completely apart from the katello user (which is bad IMHO). This also is completely different from our existing orchestration methods. User is just the best example, but really everything in src/models/foreman/ seems like it should be in src/models/glue/foreman/ . -Justin From bkearney at redhat.com Tue Aug 21 18:51:38 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 21 Aug 2012 14:51:38 -0400 Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <1858040011.12284235.1345574654206.JavaMail.root@redhat.com> References: <1858040011.12284235.1345574654206.JavaMail.root@redhat.com> Message-ID: <5033D8BA.1070000@redhat.com> On 08/21/2012 02:44 PM, Eric Helms wrote: > To clarify a bit, in Katello today, the ruby bindings (for both Pulp and Candlepin) are tied to Katello code and we are working to change that as we do our Pulp V2 migration work. I.E. create a stand-alone set of ruby-bindings to Pulp that Katello can consume. But are we doing the same with Foreman? > > A good example of what I mean is Funzo's project deadwood for Katello - https://github.com/calfonso/deadwood > Understood, this is being added to foreman along with using that code in katello. -- bk From hbrock at redhat.com Tue Aug 21 19:11:01 2012 From: hbrock at redhat.com (Hugh Brock) Date: Tue, 21 Aug 2012 15:11:01 -0400 Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <5033D8BA.1070000@redhat.com> References: <1858040011.12284235.1345574654206.JavaMail.root@redhat.com> <5033D8BA.1070000@redhat.com> Message-ID: <20120821191101.GF15992@redhat.com> On Tue, Aug 21, 2012 at 02:51:38PM -0400, Bryan Kearney wrote: > > On 08/21/2012 02:44 PM, Eric Helms wrote: > >To clarify a bit, in Katello today, the ruby bindings (for both Pulp and Candlepin) are tied to Katello code and we are working to change that as we do our Pulp V2 migration work. I.E. create a stand-alone set of ruby-bindings to Pulp that Katello can consume. But are we doing the same with Foreman? > > > >A good example of what I mean is Funzo's project deadwood for Katello - https://github.com/calfonso/deadwood > > > > Understood, this is being added to foreman along with using that > code in katello. Don't forget to reference http://www.funzo.me --H -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From calfonso at redhat.com Tue Aug 21 19:37:23 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Tue, 21 Aug 2012 15:37:23 -0400 Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <20120821191101.GF15992@redhat.com> References: <1858040011.12284235.1345574654206.JavaMail.root@redhat.com> <5033D8BA.1070000@redhat.com> <20120821191101.GF15992@redhat.com> Message-ID: <20120821193723.GA31912@dhcp-230-220.rdu.redhat.com> On 21/08/12 15:11 -0400, Hugh Brock wrote: >Don't forget to reference http://www.funzo.me That's a marquee, you guys. > >--H > >-- >== Hugh Brock, hbrock at redhat.com == -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From inecas at redhat.com Wed Aug 22 07:12:27 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 22 Aug 2012 09:12:27 +0200 Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <1305621601.12178479.1345563103827.JavaMail.root@redhat.com> References: <1305621601.12178479.1345563103827.JavaMail.root@redhat.com> Message-ID: <5034865B.90402@redhat.com> On Tue 21 Aug 2012 05:31:43 PM CEST, Eric Helms wrote: > A question after seeing the current progress of the Foreman integration work around the API layer. This is inspired by some thoughts we've had around the Pulp v2 migrations. > > Has any thought been given to generating a separate library/gem/project for the API part? Since this would be a re-usable component by potentially other communities and present a nice, clean set of ruby bindings for the Foreman APIs that we could consume (as well as others). Is this the answer? https://github.com/mbacovsky/foreman_api -- Ivan > > - Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From lzap at redhat.com Wed Aug 22 08:19:50 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 10:19:50 +0200 Subject: [katello-devel] Foreman integration model question In-Reply-To: <5033D818.5090203@redhat.com> References: <5033D818.5090203@redhat.com> Message-ID: <20120822081950.GA3044@lzapx.brq.redhat.com> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: > Taking user for example we would have: > > user.rb > glue/pulp/user.rb But you are missing one piece of the puzzle: lib/resources/pulp.rb (class User) And that is the piece which you can find in foreman/user.rb. > What I see with foreman is: > > user.rb > glue/foreman/user.rb > foreman/user.rb So instead having all the resources in a single class (lib/resources/foreman.rb), we are going to have (or better - generate) all resource (read also as "dumb") classes. Each in separate file. > Where foreman/user is a second class that can be instantiated and > used on its own, while glue/foreman/user.rb is simply the > orchestration to create that object. I see the use of > Resources::ForemanModel, but in this user instance the foreman user > could be manipulated completely apart from the katello user (which > is bad IMHO). This also is completely different from our existing > orchestration methods. Yes, it is different. I like this approach more. Creating a one instance per request is nothing, while the code is definitely better than eight hundred lines long pulp.rb with all the resources there as "class" methods. I think this is the correct approach and we may discuss splitting those big resource files in future into smaller pieces for other backend engines too. If we write a similar generator, we wont longer need to write them manually (and we will be able to track API changes too). I was not writing the code, but I believe those instances are treated like singletons, so you do not need to create instances by yourself: https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb Guys please elaborate what the intentions are. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Aug 22 08:22:46 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 10:22:46 +0200 Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <1858040011.12284235.1345574654206.JavaMail.root@redhat.com> References: <5033B135.2050403@redhat.com> <1858040011.12284235.1345574654206.JavaMail.root@redhat.com> Message-ID: <20120822082246.GB3044@lzapx.brq.redhat.com> On Tue, Aug 21, 2012 at 02:44:14PM -0400, Eric Helms wrote: > To clarify a bit, in Katello today, the ruby bindings (for both Pulp and Candlepin) are tied to Katello code and we are working to change that as we do our Pulp V2 migration work. I.E. create a stand-alone set of ruby-bindings to Pulp that Katello can consume. But are we doing the same with Foreman? > > A good example of what I mean is Funzo's project deadwood for Katello - https://github.com/calfonso/deadwood Well, the best approach would be to generate those automatically. That makes big difference. -- Later, Lukas "lzap" Zapletal #katello #systemengine From mbacovsk at redhat.com Wed Aug 22 08:23:10 2012 From: mbacovsk at redhat.com (Martin Bacovsky) Date: Wed, 22 Aug 2012 10:23:10 +0200 Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <5034865B.90402@redhat.com> References: <1305621601.12178479.1345563103827.JavaMail.root@redhat.com> <5034865B.90402@redhat.com> Message-ID: <503496EE.4070407@redhat.com> On 08/22/2012 09:12 AM, Ivan Ne?as wrote: > On Tue 21 Aug 2012 05:31:43 PM CEST, Eric Helms wrote: >> A question after seeing the current progress of the Foreman >> integration work around the API layer. This is inspired by some >> thoughts we've had around the Pulp v2 migrations. >> >> Has any thought been given to generating a separate >> library/gem/project for the API part? Since this would be a re-usable >> component by potentially other communities and present a nice, clean >> set of ruby bindings for the Foreman APIs that we could consume (as >> well as others). > > Is this the answer? > > https://github.com/mbacovsky/foreman_api > > -- Ivan The foreman_api is generated from API documentation using the Apipie tool [1]. The tool's other nice feature is that you can generate simple CLI client, but as the new API is still far from complete neither we nor the foreman community provide one. The foreman_api is available in git repo [3] (most fresh version is usually on the link Ivan provided), as a gem on rubygems.org and also in our katello-thirdparty repo as a rpm. It should be available soon as a rpm and deb for the Foreman community by their own means. Here is short wiki [2] on how we use the bindings in katello. If you find anything you need to add there, let me know. Martin [1] https://github.com/Pajk/apipie-rails [2] https://fedorahosted.org/katello/wiki/ForemanIntegrationAPI [3] https://github.com/theforeman/foreman_api >> >> - Eric >> >> _______________________________________________ >> 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 pchalupa at redhat.com Wed Aug 22 08:39:18 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 10:39:18 +0200 Subject: [katello-devel] Bundler vs rpm-gems Message-ID: <50349AB6.8060505@redhat.com> Hi, as Ivan and Lukas said on mail-list, I had some ideas how to solve our bundler/rpm issues. Then I had discussion with Ivan and Mirek and here is the proposed solution. == Requirements When installing on fedora/rhel in production. Do not mess with the production setup, rpm gems are used, 'bundle install' wont install anything else. When installing on fedora/rhel in development. 'bundle install' prefers rpm-gems even if there is a newer gem in our gem-repo [2]. Additional development dependencies are installed. When installing on any other system (Debian, Ubuntu, Mac, ...) in development. 'bundle install' installs the same versions of gems as would be installed on fedora. Optionally (at least made it possible in the future) 'bundle install' installs not only the same versions but also gems including security fixes included in rpm-gems. == Proposal I'll add monkey patch to katello/master for bundler which will ensure that rpm-gems are preferred (even if they are older than gems in a gem-repo). It's based on bkabrda's patch [1]. I'll ensure that our gem repo [2] contains all gems needed for katello development (some are still missing). This enables katello (rails app) to be installed on any system without rubygems.org. I would like to work on this in the next iteration. Also I would like to explore how difficult would be to create gem versions with security patches (which is important for non fedora development - me). We also discussed it would be nice to move our gem-repo to github a publish it on pages.github. The repo would be more visible. It would allow us to use pull-requests for tracking new gem-dependencies. It would be on one place. Petr [1] https://gist.github.com/2875212 [2] http://repos.fedorapeople.org/repos/katello/gems/ From dmitri at redhat.com Wed Aug 22 08:48:11 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 09:48:11 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <50349AB6.8060505@redhat.com> References: <50349AB6.8060505@redhat.com> Message-ID: <50349CCB.70603@redhat.com> Hey Petr, I have a fix for this in my local branch, using aeolus' bundler_ext [1] (which is now a gem). The only thing remaining is to create an rpm for the gem, and make some minor changes to katello.spec. We can chat more if you'd like... [1] https://github.com/aeolus-incubator/bundler_ext -d On 22/08/12 09:39 AM, Petr Chalupa wrote: > Hi, > > as Ivan and Lukas said on mail-list, I had some ideas how to solve our > bundler/rpm issues. Then I had discussion with Ivan and Mirek and here > is the proposed solution. > > == Requirements > > When installing on fedora/rhel in production. Do not mess with the > production setup, rpm gems are used, 'bundle install' wont install > anything else. > > When installing on fedora/rhel in development. 'bundle install' > prefers rpm-gems even if there is a newer gem in our gem-repo [2]. > Additional development dependencies are installed. > > When installing on any other system (Debian, Ubuntu, Mac, ...) in > development. 'bundle install' installs the same versions of gems as > would be installed on fedora. Optionally (at least made it possible in > the future) 'bundle install' installs not only the same versions but > also gems including security fixes included in rpm-gems. > > == Proposal > > I'll add monkey patch to katello/master for bundler which will ensure > that rpm-gems are preferred (even if they are older than gems in a > gem-repo). It's based on bkabrda's patch [1]. > > I'll ensure that our gem repo [2] contains all gems needed for katello > development (some are still missing). This enables katello (rails app) > to be installed on any system without rubygems.org. > > I would like to work on this in the next iteration. Also I would like > to explore how difficult would be to create gem versions with security > patches (which is important for non fedora development - me). > > We also discussed it would be nice to move our gem-repo to github a > publish it on pages.github. The repo would be more visible. It would > allow us to use pull-requests for tracking new gem-dependencies. It > would be on one place. > > Petr > > [1] https://gist.github.com/2875212 > [2] http://repos.fedorapeople.org/repos/katello/gems/ > > _______________________________________________ > 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 dmitri at redhat.com Wed Aug 22 08:54:06 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 09:54:06 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <50349AB6.8060505@redhat.com> References: <50349AB6.8060505@redhat.com> Message-ID: <50349E2E.8070101@redhat.com> On 22/08/12 09:39 AM, Petr Chalupa wrote: > Hi, > > as Ivan and Lukas said on mail-list, I had some ideas how to solve our > bundler/rpm issues. Then I had discussion with Ivan and Mirek and here > is the proposed solution. > > == Requirements > > When installing on fedora/rhel in production. Do not mess with the > production setup, rpm gems are used, 'bundle install' wont install > anything else. > > When installing on fedora/rhel in development. 'bundle install' > prefers rpm-gems even if there is a newer gem in our gem-repo [2]. > Additional development dependencies are installed. > > When installing on any other system (Debian, Ubuntu, Mac, ...) in > development. 'bundle install' installs the same versions of gems as > would be installed on fedora. Optionally (at least made it possible in > the future) 'bundle install' installs not only the same versions but > also gems including security fixes included in rpm-gems. > > == Proposal > > I'll add monkey patch to katello/master for bundler which will ensure > that rpm-gems are preferred (even if they are older than gems in a > gem-repo). It's based on bkabrda's patch [1]. > > I'll ensure that our gem repo [2] contains all gems needed for katello > development (some are still missing). This enables katello (rails app) > to be installed on any system without rubygems.org. > > I would like to work on this in the next iteration. Also I would like > to explore how difficult would be to create gem versions with security > patches (which is important for non fedora development - me). > > We also discussed it would be nice to move our gem-repo to github a > publish it on pages.github. The repo would be more visible. It would > allow us to use pull-requests for tracking new gem-dependencies. It > would be on one place. I'm going to suggest that we stop maintaining katello-specific gem repository, and for a few reasons: - it's redundant - we should make more effort to work with upstream, esp. if this concerns security issues - current katello gem repository is not sufficient to be used with bundler, as it lacks some of the gems -d > > Petr > > [1] https://gist.github.com/2875212 > [2] http://repos.fedorapeople.org/repos/katello/gems/ > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jlabocki at redhat.com Wed Aug 22 11:10:03 2012 From: jlabocki at redhat.com (James Labocki) Date: Wed, 22 Aug 2012 07:10:03 -0400 (EDT) Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <20120821135249.GA15992@redhat.com> Message-ID: <646595102.12493319.1345633803576.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Hugh Brock" > To: "James Labocki" > Cc: "Bryan Kearney" , aeolus-devel at lists.fedorahosted.org, katello-devel at redhat.com > Sent: Tuesday, August 21, 2012 10:52:49 AM > Subject: Re: [katello-devel] Deployable and System Template Portability > > On Tue, Aug 14, 2012 at 09:12:51AM -0400, James Labocki wrote: > > > > ----- Original Message ----- > > > From: "Bryan Kearney" > > > To: aeolus-devel at lists.fedorahosted.org, katello-devel at redhat.com > > > Sent: Tuesday, August 14, 2012 8:50:39 AM > > > Subject: Re: [katello-devel] Deployable and System Template > > > Portability > > > > > > On 08/14/2012 05:26 AM, Dmitri Dolguikh wrote: > > > > On 13/08/12 07:30 PM, James Labocki wrote: > > > >> Sorry for posting across both lists, but this involves both > > > >> aeolus > > > >> and katello. > > > >> > > > >> Last week a few of us were discussing the ability to > > > >> import/export > > > >> deployables within aeolus for sharing between differing > > > >> implementations. > > > >> > > > >> The attached photo 1.JPG provides a high level diagram of some > > > >> of > > > >> the problems we believe exist in achieving this today. Please > > > >> note that I used enterprise nomenclature, so I think that: > > > >> > > > >> - System Engine = Katello > > > >> - Component Outline = Assembly > > > >> - Blueprint = Deployable > > > >> - AppForm = Deployment > > > > > > With Foreman Integration, the goal is to kill templates and model > > > component outlines off of Foreman Host Groups. > > > > I'd like to see both these models supported in the future, is this > > the thinking behind using host groups or will it only support one > > of the scenarios? > > > > Description + Host Group ==> Build ==> Configured Image ==> Push > > to Provider > > Configured Image at Provider ==> Launch ==> Connect back to Katello > > and make further changes to Host Group > > > > OR > > > > Description ==> Build ==> Unconfigured Image ==> Push to Provider > > Unconfigured Image at Provider ==> Launch ==> Connect back to > > Katello and make all changes based on Host Group > > Hello James, thanks for bringing this stuff up. > > We need to support both of these cases, I am aware of specific > customer > demand for both. Bryan and I have been oversimplifying and referring > to > them as "image-based" (the first one) and "build-based" (the second > one). Me too. In recent times when I begin to discuss both build-time configuration, run-time configuration, and incorporating drift management into the ability to automatically generate configuration content, changesets, and promotions (Dev-Ops with control?) users and customers get really excited. My perfect world would go something like this. * Developer deploys an application via aeolus-conductor * Developer makes change to httpd.conf (for example) * Katello using Foreman and Puppet discovers the change was made * Katello notifies SysAdmin about the change and presents a piece of puppet that would apply the change * SysAdmin accepts the change and a new changeset is created with the piece of puppet content * SysAdmin promotes changeset to the next environment * httpd.conf file is altered in next environment To me, this use case is VERY powerful because developers can simply go about configuring an application and aeolus/katello are generating content based on the changes. I'm sure I oversimplified the process. > > > > >> We found the following areas differ between implementations > > > >> and > > > >> would need to be accounted for. Note this this was not an > > > >> exhaustive exercise and I'm sure we missed some areas. > > > >> > > > >> - Providers paths are different in katello > > > >> - Certificates are different in system templates > > > >> - Repositories are different in system templates > > > >> - Deployables and their services are tightly coupled (not > > > >> shareable) > > > >> - Clouds, Cloud Resource Zones, and Catalogs are different in > > > >> aeolus > > > >> > > > > > > Can you give examples of these issues? I would assume the TDL we > > > are > > > generating is valid. > > > > >From reply to Ivan earlier plus more information. > > > > Customer A installs katello and creates Custom ProviderX with > > ProductY and RepoZ > > Customer B installs katello and creates Custom ProviderA with > > ProductB and RepoC > > > > Customer A creates system template which references RepoZ, hands > > system template to Customer B. > > Customer B takes system template and imports it into his/her > > aeolus. The custom provider is does not exist in his system engine > > (assuming he changes the path the system engine host in the > > template) and the certs don't match. > > > > On the Aeolus side: > > > > Image ID's don't match in the application blueprint that Customer A > > would share with Customer B which would contain the multiple > > images that make up an application. Also, services in the > > application blueprint will likely call environment specific > > variables which are not abstracted from the service. > > We have been talking for a long time about the need for an image > abstraction in Aeolus that would let you reference an image by name > rather than UUID, such that as long as you have an image named "abc" > in > your environment, then a deployable can find that image and use it. > > Having said that, this image naming thing gets very quickly into > service > definitions, a la Cloud Formations. My Cloud Formations app might > reference three services by well-known names, and it's the > responsibility of the underlying infrastructure to either point the > app > to the right services or spin up instances that provide them. We > don't > have this capability right now with Aeolus, of course, but we are > discussing various ways to get there. > > In the meantime I would at the very least like to see us look at some > kind of abstraction for image names, repo names, and provider > names. Does that seem like it would solve the majority of these > issues? It sounds like a good idea at first glance, but I would be worried that all implementations would differ so widely. Maybe if when an application blueprint is imported in aeolus it could check if all the proper images exist (sort of like a checksum for a system image) and also could provide guidance on what packages are needed in each image? This would require aeolus having a deeper understanding of the katello environment. > > --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 Wed Aug 22 11:29:13 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 22 Aug 2012 13:29:13 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <50349AB6.8060505@redhat.com> References: <50349AB6.8060505@redhat.com> Message-ID: <5034C289.3050502@redhat.com> On 08/22/2012 10:39 AM, Petr Chalupa wrote: > Hi, > > as Ivan and Lukas said on mail-list, I had some ideas how to solve our > bundler/rpm issues. Then I had discussion with Ivan and Mirek and here > is the proposed solution. > > == Requirements > > When installing on fedora/rhel in production. Do not mess with the > production setup, rpm gems are used, 'bundle install' wont install > anything else. > > When installing on fedora/rhel in development. 'bundle install' > prefers rpm-gems even if there is a newer gem in our gem-repo [2]. > Additional development dependencies are installed. > > When installing on any other system (Debian, Ubuntu, Mac, ...) in > development. 'bundle install' installs the same versions of gems as > would be installed on fedora. Optionally (at least made it possible in > the future) 'bundle install' installs not only the same versions but > also gems including security fixes included in rpm-gems. > > == Proposal > > I'll add monkey patch to katello/master for bundler which will ensure > that rpm-gems are preferred (even if they are older than gems in a > gem-repo). It's based on bkabrda's patch [1]. > > I'll ensure that our gem repo [2] contains all gems needed for katello > development (some are still missing). This enables katello (rails app) > to be installed on any system without rubygems.org. > > I would like to work on this in the next iteration. Also I would like > to explore how difficult would be to create gem versions with security > patches (which is important for non fedora development - me). > > We also discussed it would be nice to move our gem-repo to github a > publish it on pages.github. The repo would be more visible. It would > allow us to use pull-requests for tracking new gem-dependencies. It > would be on one place. I'm all for this change. This is a good compromise for yum-based development vs. rest of the world, as it brings the good parts from both worlds (stability of production dependencies vs. comfort of using other gems for easier development). The main problem with the custom gem repo was the way it was prepared, but that's not a reason why not to use it. I vote for every improvement that doesn't prevent me developing on the same stack we're running and supporting for production. It's also the fastest way to get a development environment on yum-based machine: katello-install, bundle install. Ready to go. -- Ivan > > Petr > > [1] https://gist.github.com/2875212 > [2] http://repos.fedorapeople.org/repos/katello/gems/ > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From tkolhar at redhat.com Wed Aug 22 11:39:13 2012 From: tkolhar at redhat.com (Tazim Kolhar) Date: Wed, 22 Aug 2012 07:39:13 -0400 (EDT) Subject: [katello-devel] Doubts In-Reply-To: <1260903678.7688518.1345221026781.JavaMail.root@redhat.com> Message-ID: <1660785863.5172767.1345635553298.JavaMail.root@redhat.com> Hi, I did use --force open when re-subscribing the systems. an received no errors during register/subscribe process. I did not use subscription-manager clean since I had no idea about it. Thanks & Regards, Tazim ----- Original Message ----- From: "Eric Sammons" To: "Tazim Kolhar" Cc: katello-devel at redhat.com Sent: Friday, August 17, 2012 10:00:26 PM Subject: Re: Doubts ----- Original Message ----- cc'ing katello-devel here for transparency and they may have some input here. > Hi, > > > 1. I uploaded a manifests which was valid on one of the servers. > 2. the rpm packages installed is as follows : > [root at dell-pesc1435-01 ~]# rpm -qa | grep katello > katello-all-1.0.5-1.fc16.noarch > katello-glue-candlepin-1.0.5-1.fc16.noarch > katello-configure-1.1.3-1.fc16.noarch > katello-glue-pulp-1.0.5-1.fc16.noarch > katello-1.0.5-1.fc16.noarch > katello-candlepin-cert-key-pair-1.0-1.noarch > katello-selinux-1.0.1-1.fc16.noarch > katello-cli-headpin-1.1.0-1.git.14.d10e8a3.fc16.noarch > katello-glue-foreman-1.0.5-1.fc16.noarch > katello-certs-tools-1.1.8-1.fc16.noarch > katello-cli-common-1.1.1-1.fc16.noarch > katello-common-1.0.5-1.fc16.noarch > > 3. Later, I subscribed few systems to the subscriptions > uploaded. > > 4. Uploaded another manifests created from the same distributor > . > 5. subscribed the systems again with the new subscriptions. > > 6. Subscriptions appear to be invalid although they are valid. For the above, I will try and reproduce as I have not tried this; however, my first question is did you use the --force open when re-subscribing the systems? Did you receive any errors during the register/subscribe process? And finally, did you do a subscription-manager clean first (--force I believe will take care of this for you)? > > 7. Also, when I tried to upload the very first manifest again it > failed with errors. This behavior here is expected as the manifest is in fact older than the manifest you have currently loaded. > Please, let me know if its a bug so that can be filed accordingly. > > > Thanks & Regards, > Tazim --Eric From dmitri at redhat.com Wed Aug 22 12:04:20 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 13:04:20 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034C289.3050502@redhat.com> References: <50349AB6.8060505@redhat.com> <5034C289.3050502@redhat.com> Message-ID: <5034CAC4.5070809@redhat.com> On 22/08/12 12:29 PM, Ivan Ne?as wrote: > On 08/22/2012 10:39 AM, Petr Chalupa wrote: >> Hi, >> >> as Ivan and Lukas said on mail-list, I had some ideas how to solve >> our bundler/rpm issues. Then I had discussion with Ivan and Mirek and >> here is the proposed solution. >> >> == Requirements >> >> When installing on fedora/rhel in production. Do not mess with the >> production setup, rpm gems are used, 'bundle install' wont install >> anything else. >> >> When installing on fedora/rhel in development. 'bundle install' >> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >> Additional development dependencies are installed. >> >> When installing on any other system (Debian, Ubuntu, Mac, ...) in >> development. 'bundle install' installs the same versions of gems as >> would be installed on fedora. Optionally (at least made it possible >> in the future) 'bundle install' installs not only the same versions >> but also gems including security fixes included in rpm-gems. >> >> == Proposal >> >> I'll add monkey patch to katello/master for bundler which will ensure >> that rpm-gems are preferred (even if they are older than gems in a >> gem-repo). It's based on bkabrda's patch [1]. >> >> I'll ensure that our gem repo [2] contains all gems needed for >> katello development (some are still missing). This enables katello >> (rails app) to be installed on any system without rubygems.org. >> >> I would like to work on this in the next iteration. Also I would like >> to explore how difficult would be to create gem versions with >> security patches (which is important for non fedora development - me). >> >> We also discussed it would be nice to move our gem-repo to github a >> publish it on pages.github. The repo would be more visible. It would >> allow us to use pull-requests for tracking new gem-dependencies. It >> would be on one place. > I'm all for this change. This is a good compromise for yum-based > development vs. rest of the world, as it brings the good parts from > both worlds (stability of production dependencies vs. comfort of using > other gems for easier development). The main problem with the custom > gem repo was the way it was prepared, but that's not a reason why not > to use it. I vote for every improvement that doesn't prevent me > developing on the same stack we're running and supporting for production. The main problem with custom gem repo is that it not very useful outside of rhel/fedora world at best, and can be an actual downside. I know that foreman users/devs running on debian use debian-provided dependencies. How does a custom repo help them? What if someone wants to use katello as part of their project, how do custom dependencies help them? -d > It's also the fastest way to get a development environment on > yum-based machine: katello-install, bundle install. Ready to go. > > -- Ivan >> >> Petr >> >> [1] https://gist.github.com/2875212 >> [2] http://repos.fedorapeople.org/repos/katello/gems/ >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > From bkearney at redhat.com Wed Aug 22 12:12:28 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 22 Aug 2012 08:12:28 -0400 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <50349E2E.8070101@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> Message-ID: <5034CCAC.1060003@redhat.com> On 08/22/2012 04:54 AM, Dmitri Dolguikh wrote: > On 22/08/12 09:39 AM, Petr Chalupa wrote: >> Hi, >> >> as Ivan and Lukas said on mail-list, I had some ideas how to solve our >> bundler/rpm issues. Then I had discussion with Ivan and Mirek and here >> is the proposed solution. >> >> == Requirements >> >> When installing on fedora/rhel in production. Do not mess with the >> production setup, rpm gems are used, 'bundle install' wont install >> anything else. >> >> When installing on fedora/rhel in development. 'bundle install' >> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >> Additional development dependencies are installed. >> >> When installing on any other system (Debian, Ubuntu, Mac, ...) in >> development. 'bundle install' installs the same versions of gems as >> would be installed on fedora. Optionally (at least made it possible in >> the future) 'bundle install' installs not only the same versions but >> also gems including security fixes included in rpm-gems. >> >> == Proposal >> >> I'll add monkey patch to katello/master for bundler which will ensure >> that rpm-gems are preferred (even if they are older than gems in a >> gem-repo). It's based on bkabrda's patch [1]. >> >> I'll ensure that our gem repo [2] contains all gems needed for katello >> development (some are still missing). This enables katello (rails app) >> to be installed on any system without rubygems.org. >> >> I would like to work on this in the next iteration. Also I would like >> to explore how difficult would be to create gem versions with security >> patches (which is important for non fedora development - me). >> >> We also discussed it would be nice to move our gem-repo to github a >> publish it on pages.github. The repo would be more visible. It would >> allow us to use pull-requests for tracking new gem-dependencies. It >> would be on one place. > I'm going to suggest that we stop maintaining katello-specific gem > repository, and for a few reasons: > - it's redundant > - we should make more effort to work with upstream, esp. if this > concerns security issues > - current katello gem repository is not sufficient to be used with > bundler, as it lacks some of the gems > I agree... except that we will want to ensure that we stay on a specific version of the gems so we are not always repackaging. - bk From bkearney at redhat.com Wed Aug 22 12:17:57 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 22 Aug 2012 08:17:57 -0400 Subject: [katello-devel] Doubts In-Reply-To: <1660785863.5172767.1345635553298.JavaMail.root@redhat.com> References: <1660785863.5172767.1345635553298.JavaMail.root@redhat.com> Message-ID: <5034CDF5.4090304@redhat.com> If auto-subscribe is on, it should JustWork(tm). -- bk On 08/22/2012 07:39 AM, Tazim Kolhar wrote: > Hi, > > I did use --force open when re-subscribing the systems. > an received no errors during register/subscribe process. > > I did not use subscription-manager clean since I had no idea about it. > > Thanks & Regards, > Tazim > > ----- Original Message ----- > From: "Eric Sammons" > To: "Tazim Kolhar" > Cc: katello-devel at redhat.com > Sent: Friday, August 17, 2012 10:00:26 PM > Subject: Re: Doubts > > > ----- Original Message ----- > > cc'ing katello-devel here for transparency and they may have some input here. > >> Hi, >> >> >> 1. I uploaded a manifests which was valid on one of the servers. >> 2. the rpm packages installed is as follows : >> [root at dell-pesc1435-01 ~]# rpm -qa | grep katello >> katello-all-1.0.5-1.fc16.noarch >> katello-glue-candlepin-1.0.5-1.fc16.noarch >> katello-configure-1.1.3-1.fc16.noarch >> katello-glue-pulp-1.0.5-1.fc16.noarch >> katello-1.0.5-1.fc16.noarch >> katello-candlepin-cert-key-pair-1.0-1.noarch >> katello-selinux-1.0.1-1.fc16.noarch >> katello-cli-headpin-1.1.0-1.git.14.d10e8a3.fc16.noarch >> katello-glue-foreman-1.0.5-1.fc16.noarch >> katello-certs-tools-1.1.8-1.fc16.noarch >> katello-cli-common-1.1.1-1.fc16.noarch >> katello-common-1.0.5-1.fc16.noarch >> >> 3. Later, I subscribed few systems to the subscriptions >> uploaded. >> >> 4. Uploaded another manifests created from the same distributor >> . >> 5. subscribed the systems again with the new subscriptions. >> >> 6. Subscriptions appear to be invalid although they are valid. > > For the above, I will try and reproduce as I have not tried this; however, my first question is did you use the --force open when re-subscribing the systems? Did you receive any errors during the register/subscribe process? And finally, did you do a subscription-manager clean first (--force I believe will take care of this for you)? > >> >> 7. Also, when I tried to upload the very first manifest again it >> failed with errors. > > This behavior here is expected as the manifest is in fact older than the manifest you have currently loaded. > >> Please, let me know if its a bug so that can be filed accordingly. >> >> >> Thanks & Regards, >> Tazim > > --Eric > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From pchalupa at redhat.com Wed Aug 22 12:26:13 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 14:26:13 +0200 Subject: [katello-devel] Foreman integration model question In-Reply-To: <20120822081950.GA3044@lzapx.brq.redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> Message-ID: <5034CFE5.1080702@redhat.com> Lukas is right, our motivation was to break the code into smaller pieces (I am big fan of SOLID and 'single responsibility principle' in particular). If you write code this way, you can then move things around very quickly so you can develop features and fix bugs faster. No to mention it can be testes more easily. app/models/user.rb (User) is representation of katello user which mixes (if foreman is installed) foreman orchestration app/models/glue/forema/user.rb. Orchestration is working with foreman through children of ForemanModel which are representation of remote resources app/models/foreman/user.rb (Foreman::User). Foreman::User is using foreman-api bindings which are defined as singletons in lib/resources/foreman.rb. So there are 4 layers: - katello model - foreman-katello orchestration - foreman model (remote resource) - foreman bindings (gem foreman-api) I also for splitting up big parts. Petr On 22.08.12 10:19, Lukas Zapletal wrote: > On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: >> Taking user for example we would have: >> >> user.rb >> glue/pulp/user.rb > > But you are missing one piece of the puzzle: > > lib/resources/pulp.rb (class User) > > And that is the piece which you can find in foreman/user.rb. > >> What I see with foreman is: >> >> user.rb >> glue/foreman/user.rb >> foreman/user.rb > > So instead having all the resources in a single class > (lib/resources/foreman.rb), we are going to have (or better - generate) > all resource (read also as "dumb") classes. Each in separate file. > >> Where foreman/user is a second class that can be instantiated and >> used on its own, while glue/foreman/user.rb is simply the >> orchestration to create that object. I see the use of >> Resources::ForemanModel, but in this user instance the foreman user >> could be manipulated completely apart from the katello user (which >> is bad IMHO). This also is completely different from our existing >> orchestration methods. > > Yes, it is different. I like this approach more. Creating a one instance > per request is nothing, while the code is definitely better than eight > hundred lines long pulp.rb with all the resources there as "class" > methods. > > I think this is the correct approach and we may discuss splitting those > big resource files in future into smaller pieces for other backend > engines too. If we write a similar generator, we wont longer need to > write them manually (and we will be able to track API changes too). > > I was not writing the code, but I believe those instances are treated > like singletons, so you do not need to create instances by yourself: > > https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb > > Guys please elaborate what the intentions are. > From pchalupa at redhat.com Wed Aug 22 12:32:27 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 14:32:27 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034CCAC.1060003@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <5034CCAC.1060003@redhat.com> Message-ID: <5034D15B.3090408@redhat.com> We should not drop our gem-repo, we would not be able to provide gem with patches from rpms to non fedora/rhel systems (I and any other non fedora developer need those to be able to reasonable fix bugs). Petr On 22.08.12 14:12, Bryan Kearney wrote: > On 08/22/2012 04:54 AM, Dmitri Dolguikh wrote: >> On 22/08/12 09:39 AM, Petr Chalupa wrote: >>> Hi, >>> >>> as Ivan and Lukas said on mail-list, I had some ideas how to solve our >>> bundler/rpm issues. Then I had discussion with Ivan and Mirek and here >>> is the proposed solution. >>> >>> == Requirements >>> >>> When installing on fedora/rhel in production. Do not mess with the >>> production setup, rpm gems are used, 'bundle install' wont install >>> anything else. >>> >>> When installing on fedora/rhel in development. 'bundle install' >>> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >>> Additional development dependencies are installed. >>> >>> When installing on any other system (Debian, Ubuntu, Mac, ...) in >>> development. 'bundle install' installs the same versions of gems as >>> would be installed on fedora. Optionally (at least made it possible in >>> the future) 'bundle install' installs not only the same versions but >>> also gems including security fixes included in rpm-gems. >>> >>> == Proposal >>> >>> I'll add monkey patch to katello/master for bundler which will ensure >>> that rpm-gems are preferred (even if they are older than gems in a >>> gem-repo). It's based on bkabrda's patch [1]. >>> >>> I'll ensure that our gem repo [2] contains all gems needed for katello >>> development (some are still missing). This enables katello (rails app) >>> to be installed on any system without rubygems.org. >>> >>> I would like to work on this in the next iteration. Also I would like >>> to explore how difficult would be to create gem versions with security >>> patches (which is important for non fedora development - me). >>> >>> We also discussed it would be nice to move our gem-repo to github a >>> publish it on pages.github. The repo would be more visible. It would >>> allow us to use pull-requests for tracking new gem-dependencies. It >>> would be on one place. >> I'm going to suggest that we stop maintaining katello-specific gem >> repository, and for a few reasons: >> - it's redundant >> - we should make more effort to work with upstream, esp. if this >> concerns security issues >> - current katello gem repository is not sufficient to be used with >> bundler, as it lacks some of the gems >> > > I agree... except that we will want to ensure that we stay on a specific > version of the gems so we are not always repackaging. > > - bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Wed Aug 22 12:42:55 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 14:42:55 +0200 Subject: [katello-devel] Consumer and goferd Message-ID: <20120822124255.GD3044@lzapx.brq.redhat.com> Hello, I noticed when we install katello-cert-consumer bootstrap RPM which deploys Katello server certificate (also used for Katello Agent), it does not restart goferd when it is not running. It only restarts it when it is running. Now, I wonder if we want to keep this. Because then the client bootstrap process is missing one step - by default goferd is turned off and not started (after provisioning). Currently, to write correct bootstrap script that can be used to provision systems, you need several actions: * Make sure a time synchronizer is installed and enabled on a provisioned system * Install all Katello client components (*) * Configure the client (using RPM bootstrap package preferably) * Register the client (with activation keys preferably) * Optionally subscribe to repositories (when immediate content consumption is necessary) (*) - these steps are not necessary for RHEL systems, albeit this does not apply to RHEL clones. I found we are missing one another step: * Make sure goferd daemon is started to use Katello Agent It looks like a decent amount of work to bootstrap a system now. Isn't a time to start a bootstrap script that would be distributed in the /pub/html directory (maybe as an example too)? -- Later, Lukas "lzap" Zapletal #katello #systemengine From vondruch at redhat.com Wed Aug 22 12:44:23 2012 From: vondruch at redhat.com (=?ISO-8859-1?Q?V=EDt_Ondruch?=) Date: Wed, 22 Aug 2012 14:44:23 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034D15B.3090408@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <5034CCAC.1060003@redhat.com> <5034D15B.3090408@redhat.com> Message-ID: <5034D427.5070809@redhat.com> Dne 22.8.2012 14:32, Petr Chalupa napsal(a): > We should not drop our gem-repo, we would not be able to provide gem > with patches from rpms to non fedora/rhel systems (I and any other non > fedora developer need those to be able to reasonable fix bugs). > > Petr > Please excuse me, but what is the purpose of gem-repo *with patches*? Security issues are typically fixed in latest versions of gems, which in turn should be available in Fedora Rawhide, so am I missing something? Vit From lzap at redhat.com Wed Aug 22 12:50:45 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 14:50:45 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034D427.5070809@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <5034CCAC.1060003@redhat.com> <5034D15B.3090408@redhat.com> <5034D427.5070809@redhat.com> Message-ID: <20120822125045.GE3044@lzapx.brq.redhat.com> On Wed, Aug 22, 2012 at 02:44:23PM +0200, Vit Ondruch wrote: > Dne 22.8.2012 14:32, Petr Chalupa napsal(a): > >We should not drop our gem-repo, we would not be able to provide > >gem with patches from rpms to non fedora/rhel systems (I and any > >other non fedora developer need those to be able to reasonable fix > >bugs). > > > >Petr > > > > Please excuse me, but what is the purpose of gem-repo *with > patches*? Security issues are typically fixed in latest versions of > gems, which in turn should be available in Fedora Rawhide, so am I > missing something? > +1 I also think we don't need it. We provide Fedora/RHEL builds and support for community for free. If anyone (from our community) is willing to operate Katello on gems, no issues from our side. We will support them to maintain gems, do security patches or whatever they need. But we will carry on with providing security patches the usual way via RPMs. -- Later, Lukas "lzap" Zapletal #katello #systemengine From pchalupa at redhat.com Wed Aug 22 12:54:46 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 14:54:46 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034D427.5070809@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <5034CCAC.1060003@redhat.com> <5034D15B.3090408@redhat.com> <5034D427.5070809@redhat.com> Message-ID: <5034D696.3060202@redhat.com> I know but those new versions sometimes have different behavior than the old version. As a developer I would like to be as close as possible to fedora environment even if I am on mac/ubuntu/debian. It's particularly useful when you bug-fixing and you avoid situations when you unintentionally use a feature from the new version of gem which will break katello on fedora/rhel. Petr On 22.08.12 14:44, V?t Ondruch wrote: > Dne 22.8.2012 14:32, Petr Chalupa napsal(a): >> We should not drop our gem-repo, we would not be able to provide gem >> with patches from rpms to non fedora/rhel systems (I and any other non >> fedora developer need those to be able to reasonable fix bugs). >> >> Petr >> > > Please excuse me, but what is the purpose of gem-repo *with patches*? > Security issues are typically fixed in latest versions of gems, which in > turn should be available in Fedora Rawhide, so am I missing something? > > > Vit > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Wed Aug 22 12:55:33 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 14:55:33 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <50349E2E.8070101@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> Message-ID: <20120822125533.GF3044@lzapx.brq.redhat.com> On Wed, Aug 22, 2012 at 09:54:06AM +0100, Dmitri Dolguikh wrote: > I'm going to suggest that we stop maintaining katello-specific gem > repository, and for a few reasons: > - it's redundant > - we should make more effort to work with upstream, esp. if this > concerns security issues > - current katello gem repository is not sufficient to be used with > bundler, as it lacks some of the gems > > I would also love to get rid of it. My assumtion is Gemfile.lock would be THE THING that should keep the correct versions of all gems. But there are questions? A) Which version is the correct one? The one from Fedora 16? 17? Or RHEL6? I would like to have ability to generate the lock file somehow, so devs would be able to start Katello with various "environments". Sometimes you have Fedora only bug. Sometimes you introduce RHEL6 bug (because you develop only on Fedora). B) How would folks update those lock files. I mean if you want to add new dependency, bundle install would bump all the versions there. Once we start to rely on the Gemfile.lock, we will see folks bumping versions randomly in the git. So I say - if to get rid of it - why not. But let's somehow generate the lock file so we all stay on the exact same versions with ability to switch from Fedoras to RHEL and back. And basically having our gem repo is one way of achieving that. We are making sure, that if you do "bundle install" you wont bump versions to some super-duper new that are totally different from those in the oldest Fedora or RHEL supported version. -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Wed Aug 22 13:00:50 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 14:00:50 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822125533.GF3044@lzapx.brq.redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> Message-ID: <5034D802.7080809@redhat.com> On 22/08/12 01:55 PM, Lukas Zapletal wrote: > On Wed, Aug 22, 2012 at 09:54:06AM +0100, Dmitri Dolguikh wrote: >> I'm going to suggest that we stop maintaining katello-specific gem >> repository, and for a few reasons: >> - it's redundant >> - we should make more effort to work with upstream, esp. if this >> concerns security issues >> - current katello gem repository is not sufficient to be used with >> bundler, as it lacks some of the gems >> >> > I would also love to get rid of it. My assumtion is Gemfile.lock would > be THE THING that should keep the correct versions of all gems. But > there are questions? > > A) Which version is the correct one? The one from Fedora 16? 17? Or > RHEL6? I would like to have ability to generate the lock file somehow, > so devs would be able to start Katello with various "environments". > Sometimes you have Fedora only bug. Sometimes you introduce RHEL6 bug > (because you develop only on Fedora). i'd treat all platforms with the exception of latest fedora as production-platforms (in a sense that they are running with w/e system gems are available to them). In this case we can simply ignore versions part of gem specification in Gemfile. > > B) How would folks update those lock files. I mean if you want to add > new dependency, bundle install would bump all the versions there. Once > we start to rely on the Gemfile.lock, we will see folks bumping versions > randomly in the git. Again, not an issue on deployment platforms. They either use rpms, or Bundler. -d > > So I say - if to get rid of it - why not. But let's somehow generate the > lock file so we all stay on the exact same versions with ability to > switch from Fedoras to RHEL and back. > > And basically having our gem repo is one way of achieving that. We are > making sure, that if you do "bundle install" you wont bump versions to > some super-duper new that are totally different from those in the oldest > Fedora or RHEL supported version. > From lzap at redhat.com Wed Aug 22 13:03:14 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 15:03:14 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <50349AB6.8060505@redhat.com> References: <50349AB6.8060505@redhat.com> Message-ID: <20120822130314.GG3044@lzapx.brq.redhat.com> On Wed, Aug 22, 2012 at 10:39:18AM +0200, Petr Chalupa wrote: > == Requirements > > When installing on fedora/rhel in production. Do not mess with the > production setup, rpm gems are used, 'bundle install' wont install > anything else. > > When installing on fedora/rhel in development. 'bundle install' > prefers rpm-gems even if there is a newer gem in our gem-repo [2]. > Additional development dependencies are installed. > > When installing on any other system (Debian, Ubuntu, Mac, ...) in > development. 'bundle install' installs the same versions of gems as > would be installed on fedora. Optionally (at least made it possible > in the future) 'bundle install' installs not only the same versions > but also gems including security fixes included in rpm-gems. > Question - the very same version from which fedora version? I would like to see four gem repos instead of one. Fedora 16/17 (two last stable versions) and RHEL6. Plus one repo with development gems (versions does not matter here - we do not deploy them to the users). Then we would have something like: source 'http://fedorapeople.org/groups/katello/gems/f16' #source 'http://fedorapeople.org/groups/katello/gems/f17' #source 'http://fedorapeople.org/groups/katello/gems/el6' source 'http://fedorapeople.org/groups/katello/gems/dev' Everyone could uncomment the version that should be used. > == Proposal > > I'll add monkey patch to katello/master for bundler which will > ensure that rpm-gems are preferred (even if they are older than gems > in a gem-repo). It's based on bkabrda's patch [1]. > > I'll ensure that our gem repo [2] contains all gems needed for > katello development (some are still missing). This enables katello > (rails app) to be installed on any system without rubygems.org. > How are you going to ensure this? This MUST be some kind of automatic process. I am for unpacking gems from our RPMs with a script or something. > I would like to work on this in the next iteration. Also I would > like to explore how difficult would be to create gem versions with > security patches (which is important for non fedora development - > me). Please do not try to solve security patches - it's out of the scope (another sub-thread started in regard to this topic). We simply do not support running Katello on pure gems. > We also discussed it would be nice to move our gem-repo to github a > publish it on pages.github. The repo would be more visible. It would > allow us to use pull-requests for tracking new gem-dependencies. It > would be on one place. I strongly suggest our Fedorahosted shared account. Everyone from katello-git FAC group has read/write access there, no limits and also everyone with FAC has shell on fedorapeople.org with cron. Can you describe in more detail how are you going to achieve all of the above? -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Aug 22 13:05:42 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 15:05:42 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034D696.3060202@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <5034CCAC.1060003@redhat.com> <5034D15B.3090408@redhat.com> <5034D427.5070809@redhat.com> <5034D696.3060202@redhat.com> Message-ID: <20120822130542.GH3044@lzapx.brq.redhat.com> Well, this is *very* rare. The alpha and omega of security patch is that you always patch the absolute minimum, just to avoid the security problem. No functionality should be changed. I think we can perfectly live without security patches. I bet we wont hit any problem in regard to this in five years. But Vit should confirm this, he is the right guy :-) LZ On Wed, Aug 22, 2012 at 02:54:46PM +0200, Petr Chalupa wrote: > I know but those new versions sometimes have different behavior than > the old version. As a developer I would like to be as close as > possible to fedora environment even if I am on mac/ubuntu/debian. > It's particularly useful when you bug-fixing and you avoid > situations when you unintentionally use a feature from the new > version of gem which will break katello on fedora/rhel. > > Petr > > On 22.08.12 14:44, V?t Ondruch wrote: > >Dne 22.8.2012 14:32, Petr Chalupa napsal(a): > >>We should not drop our gem-repo, we would not be able to provide gem > >>with patches from rpms to non fedora/rhel systems (I and any other non > >>fedora developer need those to be able to reasonable fix bugs). > >> > >>Petr > >> > > > >Please excuse me, but what is the purpose of gem-repo *with patches*? > >Security issues are typically fixed in latest versions of gems, which in > >turn should be available in Fedora Rawhide, so am I missing something? > > > > > >Vit > > > >_______________________________________________ > >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 dmitri at redhat.com Wed Aug 22 13:10:06 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 14:10:06 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822130314.GG3044@lzapx.brq.redhat.com> References: <50349AB6.8060505@redhat.com> <20120822130314.GG3044@lzapx.brq.redhat.com> Message-ID: <5034DA2E.9080604@redhat.com> On 22/08/12 02:03 PM, Lukas Zapletal wrote: > On Wed, Aug 22, 2012 at 10:39:18AM +0200, Petr Chalupa wrote: >> == Requirements >> >> When installing on fedora/rhel in production. Do not mess with the >> production setup, rpm gems are used, 'bundle install' wont install >> anything else. >> >> When installing on fedora/rhel in development. 'bundle install' >> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >> Additional development dependencies are installed. >> >> When installing on any other system (Debian, Ubuntu, Mac, ...) in >> development. 'bundle install' installs the same versions of gems as >> would be installed on fedora. Optionally (at least made it possible >> in the future) 'bundle install' installs not only the same versions >> but also gems including security fixes included in rpm-gems. >> > Question - the very same version from which fedora version? > > I would like to see four gem repos instead of one. Fedora 16/17 (two > last stable versions) and RHEL6. Plus one repo with development gems > (versions does not matter here - we do not deploy them to the users). > Then we would have something like: > > source 'http://fedorapeople.org/groups/katello/gems/f16' > #source 'http://fedorapeople.org/groups/katello/gems/f17' > #source 'http://fedorapeople.org/groups/katello/gems/el6' > source 'http://fedorapeople.org/groups/katello/gems/dev' are we developing on all of those???? or simply deploying on those? -d > > Everyone could uncomment the version that should be used. > >> == Proposal >> >> I'll add monkey patch to katello/master for bundler which will >> ensure that rpm-gems are preferred (even if they are older than gems >> in a gem-repo). It's based on bkabrda's patch [1]. >> >> I'll ensure that our gem repo [2] contains all gems needed for >> katello development (some are still missing). This enables katello >> (rails app) to be installed on any system without rubygems.org. >> > How are you going to ensure this? This MUST be some kind of automatic > process. I am for unpacking gems from our RPMs with a script or > something. > >> I would like to work on this in the next iteration. Also I would >> like to explore how difficult would be to create gem versions with >> security patches (which is important for non fedora development - >> me). > Please do not try to solve security patches - it's out of the scope > (another sub-thread started in regard to this topic). We simply do not > support running Katello on pure gems. > >> We also discussed it would be nice to move our gem-repo to github a >> publish it on pages.github. The repo would be more visible. It would >> allow us to use pull-requests for tracking new gem-dependencies. It >> would be on one place. > I strongly suggest our Fedorahosted shared account. Everyone from > katello-git FAC group has read/write access there, no limits and also > everyone with FAC has shell on fedorapeople.org with cron. > > Can you describe in more detail how are you going to achieve all of the > above? > From lzap at redhat.com Wed Aug 22 13:12:43 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 15:12:43 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034D802.7080809@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <5034D802.7080809@redhat.com> Message-ID: <20120822131242.GI3044@lzapx.brq.redhat.com> On Wed, Aug 22, 2012 at 02:00:50PM +0100, Dmitri Dolguikh wrote: > >A) Which version is the correct one? The one from Fedora 16? 17? Or > >RHEL6? I would like to have ability to generate the lock file somehow, > >so devs would be able to start Katello with various "environments". > >Sometimes you have Fedora only bug. Sometimes you introduce RHEL6 bug > >(because you develop only on Fedora). > i'd treat all platforms with the exception of latest fedora as > production-platforms (in a sense that they are running with w/e > system gems are available to them). In this case we can simply > ignore versions part of gem specification in Gemfile. You'd treat them as production platform. I see. But I ask: which gem versions would you use for developing on MacOS or Debian? And I answer: a random set instead of predictable one. > >B) How would folks update those lock files. I mean if you want to add > >new dependency, bundle install would bump all the versions there. Once > >we start to rely on the Gemfile.lock, we will see folks bumping versions > >randomly in the git. > Again, not an issue on deployment platforms. They either use rpms, > or Bundler. But the whole discussion is about development, not deployment. Folks will start committing Gemfile.lock changes as "bundle install" will be issued shortly. And we will have this out of control. I wonder the simplest solution is to provide our own gem repos. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Aug 22 13:15:41 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 15:15:41 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034DA2E.9080604@redhat.com> References: <50349AB6.8060505@redhat.com> <20120822130314.GG3044@lzapx.brq.redhat.com> <5034DA2E.9080604@redhat.com> Message-ID: <20120822131541.GJ3044@lzapx.brq.redhat.com> On Wed, Aug 22, 2012 at 02:10:06PM +0100, Dmitri Dolguikh wrote: > >source 'http://fedorapeople.org/groups/katello/gems/f16' > >#source 'http://fedorapeople.org/groups/katello/gems/f17' > >#source 'http://fedorapeople.org/groups/katello/gems/el6' > >source 'http://fedorapeople.org/groups/katello/gems/dev' > are we developing on all of those???? or simply deploying on those? We should all be able to develop/test on those. Let's say you have Fedora 17 only bug and you need to start it with F17 gems (because you can't reproduce it on your setup). If we are going to generate those gem repos, I'd like to have such a chance. It's for free. -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Wed Aug 22 13:16:51 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 14:16:51 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822131242.GI3044@lzapx.brq.redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <5034D802.7080809@redhat.com> <20120822131242.GI3044@lzapx.brq.redhat.com> Message-ID: <5034DBC3.9060004@redhat.com> On 22/08/12 02:12 PM, Lukas Zapletal wrote: > On Wed, Aug 22, 2012 at 02:00:50PM +0100, Dmitri Dolguikh wrote: >>> A) Which version is the correct one? The one from Fedora 16? 17? Or >>> RHEL6? I would like to have ability to generate the lock file somehow, >>> so devs would be able to start Katello with various "environments". >>> Sometimes you have Fedora only bug. Sometimes you introduce RHEL6 bug >>> (because you develop only on Fedora). >> i'd treat all platforms with the exception of latest fedora as >> production-platforms (in a sense that they are running with w/e >> system gems are available to them). In this case we can simply >> ignore versions part of gem specification in Gemfile. > You'd treat them as production platform. I see. But I ask: which > gem versions would you use for developing on MacOS or Debian? And I > answer: a random set instead of predictable one. sorry, I only meant rpm platforms in that comment. We don't have much choice with non-rpm platforms: use bundler. > >>> B) How would folks update those lock files. I mean if you want to add >>> new dependency, bundle install would bump all the versions there. Once >>> we start to rely on the Gemfile.lock, we will see folks bumping versions >>> randomly in the git. >> Again, not an issue on deployment platforms. They either use rpms, >> or Bundler. > But the whole discussion is about development, not deployment. Folks > will start committing Gemfile.lock changes as "bundle install" will be > issued shortly. And we will have this out of control. Which platforms are for development (among rpm-based ones)? -d > > I wonder the simplest solution is to provide our own gem repos. > From dmitri at redhat.com Wed Aug 22 13:39:46 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 14:39:46 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822131541.GJ3044@lzapx.brq.redhat.com> References: <50349AB6.8060505@redhat.com> <20120822130314.GG3044@lzapx.brq.redhat.com> <5034DA2E.9080604@redhat.com> <20120822131541.GJ3044@lzapx.brq.redhat.com> Message-ID: <5034E122.1090009@redhat.com> On 22/08/12 02:15 PM, Lukas Zapletal wrote: > On Wed, Aug 22, 2012 at 02:10:06PM +0100, Dmitri Dolguikh wrote: >>> source 'http://fedorapeople.org/groups/katello/gems/f16' >>> #source 'http://fedorapeople.org/groups/katello/gems/f17' >>> #source 'http://fedorapeople.org/groups/katello/gems/el6' >>> source 'http://fedorapeople.org/groups/katello/gems/dev' >> are we developing on all of those???? or simply deploying on those? > We should all be able to develop/test on those. Let's say you have > Fedora 17 only bug and you need to start it with F17 gems (because you > can't reproduce it on your setup). > > If we are going to generate those gem repos, I'd like to have such a > chance. It's for free. if active development is happening on all of those, it's going to be a problem: those have different versions of gems (and that's not taking into account 1.9.3) - I don't think we can manage that using Bundler (in fact, that's against Bundler's goals). We could use platform-specific branches though? -d From hbrock at redhat.com Wed Aug 22 13:44:58 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 22 Aug 2012 09:44:58 -0400 Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: <646595102.12493319.1345633803576.JavaMail.root@redhat.com> References: <20120821135249.GA15992@redhat.com> <646595102.12493319.1345633803576.JavaMail.root@redhat.com> Message-ID: <20120822134458.GI15992@redhat.com> On Wed, Aug 22, 2012 at 07:10:03AM -0400, James Labocki wrote: > > ----- Original Message ----- > > From: "Hugh Brock" > > To: "James Labocki" > > Cc: "Bryan Kearney" , aeolus-devel at lists.fedorahosted.org, katello-devel at redhat.com > > Sent: Tuesday, August 21, 2012 10:52:49 AM > > Subject: Re: [katello-devel] Deployable and System Template Portability > > > > On Tue, Aug 14, 2012 at 09:12:51AM -0400, James Labocki wrote: > > > > > > > Hello James, thanks for bringing this stuff up. > > > > We need to support both of these cases, I am aware of specific > > customer > > demand for both. Bryan and I have been oversimplifying and referring > > to > > them as "image-based" (the first one) and "build-based" (the second > > one). > > Me too. In recent times when I begin to discuss both build-time configuration, run-time configuration, and incorporating drift management into the ability to automatically generate configuration content, changesets, and promotions (Dev-Ops with control?) users and customers get really excited. My perfect world would go something like this. > > * Developer deploys an application via aeolus-conductor > * Developer makes change to httpd.conf (for example) > * Katello using Foreman and Puppet discovers the change was made > * Katello notifies SysAdmin about the change and presents a piece of puppet that would apply the change > * SysAdmin accepts the change and a new changeset is created with the piece of puppet content > * SysAdmin promotes changeset to the next environment > * httpd.conf file is altered in next environment > > To me, this use case is VERY powerful because developers can simply go about configuring an application and aeolus/katello are generating content based on the changes. I'm sure I oversimplified the process. Yep. This where we want to get. I'm not clear how automated we can make the changes to the app bludprint, but it would be pretty cool to do so... > > > > > > >> We found the following areas differ between implementations > > > > >> and > > > > >> would need to be accounted for. Note this this was not an > > > > >> exhaustive exercise and I'm sure we missed some areas. > > > > >> > > > > >> - Providers paths are different in katello > > > > >> - Certificates are different in system templates > > > > >> - Repositories are different in system templates > > > > >> - Deployables and their services are tightly coupled (not > > > > >> shareable) > > > > >> - Clouds, Cloud Resource Zones, and Catalogs are different in > > > > >> aeolus > > > > >> > > > > > > > > Can you give examples of these issues? I would assume the TDL we > > > > are > > > > generating is valid. > > > > > > >From reply to Ivan earlier plus more information. > > > > > > Customer A installs katello and creates Custom ProviderX with > > > ProductY and RepoZ > > > Customer B installs katello and creates Custom ProviderA with > > > ProductB and RepoC > > > > > > Customer A creates system template which references RepoZ, hands > > > system template to Customer B. > > > Customer B takes system template and imports it into his/her > > > aeolus. The custom provider is does not exist in his system engine > > > (assuming he changes the path the system engine host in the > > > template) and the certs don't match. > > > > > > On the Aeolus side: > > > > > > Image ID's don't match in the application blueprint that Customer A > > > would share with Customer B which would contain the multiple > > > images that make up an application. Also, services in the > > > application blueprint will likely call environment specific > > > variables which are not abstracted from the service. > > > > We have been talking for a long time about the need for an image > > abstraction in Aeolus that would let you reference an image by name > > rather than UUID, such that as long as you have an image named "abc" > > in > > your environment, then a deployable can find that image and use it. > > > > Having said that, this image naming thing gets very quickly into > > service > > definitions, a la Cloud Formations. My Cloud Formations app might > > reference three services by well-known names, and it's the > > responsibility of the underlying infrastructure to either point the > > app > > to the right services or spin up instances that provide them. We > > don't > > have this capability right now with Aeolus, of course, but we are > > discussing various ways to get there. > > > > In the meantime I would at the very least like to see us look at some > > kind of abstraction for image names, repo names, and provider > > names. Does that seem like it would solve the majority of these > > issues? > > It sounds like a good idea at first glance, but I would be worried that all implementations would differ so widely. Maybe if when an application blueprint is imported in aeolus it could check if all the proper images exist (sort of like a checksum for a system image) and also could provide guidance on what packages are needed in each image? This would require aeolus having a deeper understanding of the katello environment. The issue here is that we identify images by UUID, so no image is ever going to match from one Conductor setup to another. IOW there is no way Conductor *could* check to see "if the proper images exist" on importing a blueprint, given the current setup. We'd need to have two things to fix this: 1. A way to guarantee image equivalence. Katello will have this before all that long with content views 2. Given 1, a way to identify images that actually are equivalent. These things are doable but not necessarily easy. Doesn't mean we shouldn't do them of course... --H -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From hbrock at redhat.com Wed Aug 22 13:49:06 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 22 Aug 2012 09:49:06 -0400 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822125533.GF3044@lzapx.brq.redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> Message-ID: <20120822134905.GJ15992@redhat.com> On Wed, Aug 22, 2012 at 02:55:33PM +0200, Lukas Zapletal wrote: > On Wed, Aug 22, 2012 at 09:54:06AM +0100, Dmitri Dolguikh wrote: > > I'm going to suggest that we stop maintaining katello-specific gem > > repository, and for a few reasons: > > - it's redundant > > - we should make more effort to work with upstream, esp. if this > > concerns security issues > > - current katello gem repository is not sufficient to be used with > > bundler, as it lacks some of the gems > > > > > > I would also love to get rid of it. My assumtion is Gemfile.lock would > be THE THING that should keep the correct versions of all gems. But > there are questions? > > A) Which version is the correct one? The one from Fedora 16? 17? Or > RHEL6? I would like to have ability to generate the lock file somehow, > so devs would be able to start Katello with various "environments". > Sometimes you have Fedora only bug. Sometimes you introduce RHEL6 bug > (because you develop only on Fedora). > > B) How would folks update those lock files. I mean if you want to add > new dependency, bundle install would bump all the versions there. Once > we start to rely on the Gemfile.lock, we will see folks bumping versions > randomly in the git. > > So I say - if to get rid of it - why not. But let's somehow generate the > lock file so we all stay on the exact same versions with ability to > switch from Fedoras to RHEL and back. > > And basically having our gem repo is one way of achieving that. We are > making sure, that if you do "bundle install" you wont bump versions to > some super-duper new that are totally different from those in the oldest > Fedora or RHEL supported version. FWIW, our Gemfile.lock is in git. We don't accept changes to it without patch review, etc. etc. Seems to work reasonably well. --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 ehelms at redhat.com Wed Aug 22 14:10:33 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 22 Aug 2012 10:10:33 -0400 (EDT) Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <503496EE.4070407@redhat.com> Message-ID: <1109139362.12559597.1345644633125.JavaMail.root@redhat.com> Excellent - this is exactly what I was looking for and missed that there was a separate set of API bindings in a gem due to no requires at the top of the file in lib/resources. Looking closer at the lib/resources/foreman_model.rb this mostly seems like a generic layer for interacting with a set of Ruby API bindings and could be re-purposed to used by any of the glue layers. Keeping in mind I am pondering this with regards to our migration to Pulp V2 and the re-factoring and work that will be associated with it. How much in this file is Foreman specific? -Eric ----- Original Message ----- From: "Martin Bacovsky" To: katello-devel at redhat.com Sent: Wednesday, August 22, 2012 4:23:10 AM Subject: Re: [katello-devel] Katello-Foreman Integration API Layer Question On 08/22/2012 09:12 AM, Ivan Ne?as wrote: > On Tue 21 Aug 2012 05:31:43 PM CEST, Eric Helms wrote: >> A question after seeing the current progress of the Foreman >> integration work around the API layer. This is inspired by some >> thoughts we've had around the Pulp v2 migrations. >> >> Has any thought been given to generating a separate >> library/gem/project for the API part? Since this would be a re-usable >> component by potentially other communities and present a nice, clean >> set of ruby bindings for the Foreman APIs that we could consume (as >> well as others). > > Is this the answer? > > https://github.com/mbacovsky/foreman_api > > -- Ivan The foreman_api is generated from API documentation using the Apipie tool [1]. The tool's other nice feature is that you can generate simple CLI client, but as the new API is still far from complete neither we nor the foreman community provide one. The foreman_api is available in git repo [3] (most fresh version is usually on the link Ivan provided), as a gem on rubygems.org and also in our katello-thirdparty repo as a rpm. It should be available soon as a rpm and deb for the Foreman community by their own means. Here is short wiki [2] on how we use the bindings in katello. If you find anything you need to add there, let me know. Martin [1] https://github.com/Pajk/apipie-rails [2] https://fedorahosted.org/katello/wiki/ForemanIntegrationAPI [3] https://github.com/theforeman/foreman_api >> >> - Eric >> >> _______________________________________________ >> 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 From pchalupa at redhat.com Wed Aug 22 14:11:44 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 16:11:44 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822130542.GH3044@lzapx.brq.redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <5034CCAC.1060003@redhat.com> <5034D15B.3090408@redhat.com> <5034D427.5070809@redhat.com> <5034D696.3060202@redhat.com> <20120822130542.GH3044@lzapx.brq.redhat.com> Message-ID: <5034E8A0.4010106@redhat.com> How much you would bet me? :) I'll already hit problems related to this. That's why I think its important. Petr On 22.08.12 15:05, Lukas Zapletal wrote: > Well, this is *very* rare. The alpha and omega of security patch is that > you always patch the absolute minimum, just to avoid the security > problem. No functionality should be changed. > > I think we can perfectly live without security patches. I bet we wont > hit any problem in regard to this in five years. But Vit should confirm > this, he is the right guy :-) > > LZ > > On Wed, Aug 22, 2012 at 02:54:46PM +0200, Petr Chalupa wrote: >> I know but those new versions sometimes have different behavior than >> the old version. As a developer I would like to be as close as >> possible to fedora environment even if I am on mac/ubuntu/debian. >> It's particularly useful when you bug-fixing and you avoid >> situations when you unintentionally use a feature from the new >> version of gem which will break katello on fedora/rhel. >> >> Petr >> >> On 22.08.12 14:44, V?t Ondruch wrote: >>> Dne 22.8.2012 14:32, Petr Chalupa napsal(a): >>>> We should not drop our gem-repo, we would not be able to provide gem >>>> with patches from rpms to non fedora/rhel systems (I and any other non >>>> fedora developer need those to be able to reasonable fix bugs). >>>> >>>> Petr >>>> >>> >>> Please excuse me, but what is the purpose of gem-repo *with patches*? >>> Security issues are typically fixed in latest versions of gems, which in >>> turn should be available in Fedora Rawhide, so am I missing something? >>> >>> >>> Vit >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Wed Aug 22 14:14:16 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 16:14:16 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822134905.GJ15992@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> Message-ID: <20120822141416.GN3044@lzapx.brq.redhat.com> On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote: > FWIW, our Gemfile.lock is in git. We don't accept changes to it without > patch review, etc. etc. Seems to work reasonably well. Our first experience was not that good, but truth is, now we do use github.com and pull requests. On the other hand, the lock file looks very messy. You guys are able to track it all? The general rule could be - no changes at all except adding new dependencies (after discussion on the list of course :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Aug 22 14:15:01 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 22 Aug 2012 16:15:01 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034E8A0.4010106@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <5034CCAC.1060003@redhat.com> <5034D15B.3090408@redhat.com> <5034D427.5070809@redhat.com> <5034D696.3060202@redhat.com> <20120822130542.GH3044@lzapx.brq.redhat.com> <5034E8A0.4010106@redhat.com> Message-ID: <20120822141501.GO3044@lzapx.brq.redhat.com> On Wed, Aug 22, 2012 at 04:11:44PM +0200, Petr Chalupa wrote: > How much you would bet me? :) I'll already hit problems related to > this. That's why I think its important. What was it? -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Wed Aug 22 14:16:24 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 15:16:24 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <50349AB6.8060505@redhat.com> References: <50349AB6.8060505@redhat.com> Message-ID: <5034E9B8.5090205@redhat.com> On 22/08/12 09:39 AM, Petr Chalupa wrote: > Hi, > > as Ivan and Lukas said on mail-list, I had some ideas how to solve our > bundler/rpm issues. Then I had discussion with Ivan and Mirek and here > is the proposed solution. > > == Requirements > > When installing on fedora/rhel in production. Do not mess with the > production setup, rpm gems are used, 'bundle install' wont install > anything else. > > When installing on fedora/rhel in development. 'bundle install' > prefers rpm-gems even if there is a newer gem in our gem-repo [2]. > Additional development dependencies are installed. > > When installing on any other system (Debian, Ubuntu, Mac, ...) in > development. 'bundle install' installs the same versions of gems as > would be installed on fedora. Optionally (at least made it possible in > the future) 'bundle install' installs not only the same versions but > also gems including security fixes included in rpm-gems. > > == Proposal > > I'll add monkey patch to katello/master for bundler which will ensure > that rpm-gems are preferred (even if they are older than gems in a > gem-repo). It's based on bkabrda's patch [1]. I don't think the patch does exactly that. It reshuffles dependencies so that local ones are looked at first. That includes *any* local dependency, of which there can be several. Probably what's going to happen is that it's going to pick the latest local dependency that satisfies gem spec. I don't think this is what you want, however... -d > > > I'll ensure that our gem repo [2] contains all gems needed for katello > development (some are still missing). This enables katello (rails app) > to be installed on any system without rubygems.org. > > I would like to work on this in the next iteration. Also I would like > to explore how difficult would be to create gem versions with security > patches (which is important for non fedora development - me). > > We also discussed it would be nice to move our gem-repo to github a > publish it on pages.github. The repo would be more visible. It would > allow us to use pull-requests for tracking new gem-dependencies. It > would be on one place. > > Petr > > [1] https://gist.github.com/2875212 > [2] http://repos.fedorapeople.org/repos/katello/gems/ > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From pchalupa at redhat.com Wed Aug 22 14:16:56 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 16:16:56 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822141501.GO3044@lzapx.brq.redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <5034CCAC.1060003@redhat.com> <5034D15B.3090408@redhat.com> <5034D427.5070809@redhat.com> <5034D696.3060202@redhat.com> <20120822130542.GH3044@lzapx.brq.redhat.com> <5034E8A0.4010106@redhat.com> <20120822141501.GO3044@lzapx.brq.redhat.com> Message-ID: <5034E9D8.809@redhat.com> I think it was in active_support. Patch broke some monkey-patch in i18n. It was related to string interpolation. Petr On 22.08.12 16:15, Lukas Zapletal wrote: > On Wed, Aug 22, 2012 at 04:11:44PM +0200, Petr Chalupa wrote: >> How much you would bet me? :) I'll already hit problems related to >> this. That's why I think its important. > > What was it? > From pchalupa at redhat.com Wed Aug 22 14:28:13 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 16:28:13 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822141416.GN3044@lzapx.brq.redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> <20120822141416.GN3044@lzapx.brq.redhat.com> Message-ID: <5034EC7D.1030000@redhat.com> We already discussed solution with Gemfile.lock. There are issues. - You would have to have Gemfile.lock for f16, f17, el62, el63 - You would habe to have Gemfile.lock for production and development - You will have update it every time when some version of gem or rpm change in some of f16, f17, el62, el63 It seems to me quite clumsy. Petr On 22.08.12 16:14, Lukas Zapletal wrote: > On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote: >> FWIW, our Gemfile.lock is in git. We don't accept changes to it without >> patch review, etc. etc. Seems to work reasonably well. > > Our first experience was not that good, but truth is, now we do use > github.com and pull requests. On the other hand, the lock file looks > very messy. You guys are able to track it all? > > The general rule could be - no changes at all except adding new > dependencies (after discussion on the list of course :-) > From inecas at redhat.com Wed Aug 22 14:36:34 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 22 Aug 2012 16:36:34 +0200 Subject: [katello-devel] Foreman installation through katello-configure now in master Message-ID: <5034EE72.4070803@redhat.com> Hi all, I've just merged the katello-configure and katello-all changes so that Foreman gets installed and configured to be on the same stack as Katello. The code should be available in the following nightly build. katello-all now has the dependency on foreman and foreman-postresql. Thes packages are available in [1] repo. The easiest way to get all the things should be: 1. Install katello-repos-latest.rpm (for your OS) (or add [1] to /etc/yum.repos.d/) 2. yum install katello-all 3. katello-configure After that you should see Foreman running on https://your.server.org/foreman and Katello on https://your.server.org/katello Right now the configuration is really raw and basically it doesn't provide you to do some real stuff right now. But it's the first step to get Katello and Foreman working together. More interesting things are coming. The foreman packages are built based on the the upstream code. The hash in the release number will tell you what the Foreman code revision it was. [1] - http://fedorapeople.org/groups/katello/releases/yum/katello-foreman [2] - http://fedorapeople.org/groups/katello/releases/yum/nightly/RHEL/6Server/x86_64/katello-repos-latest.rpm -- Ivan From pchalupa at redhat.com Wed Aug 22 14:36:43 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 16:36:43 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034E9B8.5090205@redhat.com> References: <50349AB6.8060505@redhat.com> <5034E9B8.5090205@redhat.com> Message-ID: <5034EE7B.5090603@redhat.com> Good point, I'll fix it. Petr On 22.08.12 16:16, Dmitri Dolguikh wrote: > On 22/08/12 09:39 AM, Petr Chalupa wrote: >> Hi, >> >> as Ivan and Lukas said on mail-list, I had some ideas how to solve our >> bundler/rpm issues. Then I had discussion with Ivan and Mirek and here >> is the proposed solution. >> >> == Requirements >> >> When installing on fedora/rhel in production. Do not mess with the >> production setup, rpm gems are used, 'bundle install' wont install >> anything else. >> >> When installing on fedora/rhel in development. 'bundle install' >> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >> Additional development dependencies are installed. >> >> When installing on any other system (Debian, Ubuntu, Mac, ...) in >> development. 'bundle install' installs the same versions of gems as >> would be installed on fedora. Optionally (at least made it possible in >> the future) 'bundle install' installs not only the same versions but >> also gems including security fixes included in rpm-gems. >> >> == Proposal >> >> I'll add monkey patch to katello/master for bundler which will ensure >> that rpm-gems are preferred (even if they are older than gems in a >> gem-repo). It's based on bkabrda's patch [1]. > > I don't think the patch does exactly that. It reshuffles dependencies so > that local ones are looked at first. That includes *any* local > dependency, of which there can be several. Probably what's going to > happen is that it's going to pick the latest local dependency that > satisfies gem spec. I don't think this is what you want, however... > > -d >> >> >> I'll ensure that our gem repo [2] contains all gems needed for katello >> development (some are still missing). This enables katello (rails app) >> to be installed on any system without rubygems.org. >> >> I would like to work on this in the next iteration. Also I would like >> to explore how difficult would be to create gem versions with security >> patches (which is important for non fedora development - me). >> >> We also discussed it would be nice to move our gem-repo to github a >> publish it on pages.github. The repo would be more visible. It would >> allow us to use pull-requests for tracking new gem-dependencies. It >> would be on one place. >> >> Petr >> >> [1] https://gist.github.com/2875212 >> [2] http://repos.fedorapeople.org/repos/katello/gems/ >> >> _______________________________________________ >> 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 Wed Aug 22 14:37:00 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 15:37:00 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034EC7D.1030000@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> <20120822141416.GN3044@lzapx.brq.redhat.com> <5034EC7D.1030000@redhat.com> Message-ID: <5034EE8C.5080306@redhat.com> On 22/08/12 03:28 PM, Petr Chalupa wrote: > We already discussed solution with Gemfile.lock. There are issues. > > - You would have to have Gemfile.lock for f16, f17, el62, el63 > - You would habe to have Gemfile.lock for production and development > - You will have update it every time when some version of gem or rpm > change in some of f16, f17, el62, el63 Hmmm. What if we bundled dependencies when we are tagging for a specific platform (and stripped them when packaging into rpm)? Troubleshooting would be quite simple then - we could even look at rhel issues on fedora... -d > > > It seems to me quite clumsy. > > Petr > > On 22.08.12 16:14, Lukas Zapletal wrote: >> On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote: >>> FWIW, our Gemfile.lock is in git. We don't accept changes to it without >>> patch review, etc. etc. Seems to work reasonably well. >> >> Our first experience was not that good, but truth is, now we do use >> github.com and pull requests. On the other hand, the lock file looks >> very messy. You guys are able to track it all? >> >> The general rule could be - no changes at all except adding new >> dependencies (after discussion on the list of course :-) >> > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From dmitri at redhat.com Wed Aug 22 14:38:26 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 15:38:26 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034EE7B.5090603@redhat.com> References: <50349AB6.8060505@redhat.com> <5034E9B8.5090205@redhat.com> <5034EE7B.5090603@redhat.com> Message-ID: <5034EEE2.7020206@redhat.com> On 22/08/12 03:36 PM, Petr Chalupa wrote: > Good point, I'll fix it. I'd like to know how you are going to discriminate between rpm-installed dependencies and bundler-installed dependencies across platforms. -d > > Petr > > On 22.08.12 16:16, Dmitri Dolguikh wrote: >> On 22/08/12 09:39 AM, Petr Chalupa wrote: >>> Hi, >>> >>> as Ivan and Lukas said on mail-list, I had some ideas how to solve our >>> bundler/rpm issues. Then I had discussion with Ivan and Mirek and here >>> is the proposed solution. >>> >>> == Requirements >>> >>> When installing on fedora/rhel in production. Do not mess with the >>> production setup, rpm gems are used, 'bundle install' wont install >>> anything else. >>> >>> When installing on fedora/rhel in development. 'bundle install' >>> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >>> Additional development dependencies are installed. >>> >>> When installing on any other system (Debian, Ubuntu, Mac, ...) in >>> development. 'bundle install' installs the same versions of gems as >>> would be installed on fedora. Optionally (at least made it possible in >>> the future) 'bundle install' installs not only the same versions but >>> also gems including security fixes included in rpm-gems. >>> >>> == Proposal >>> >>> I'll add monkey patch to katello/master for bundler which will ensure >>> that rpm-gems are preferred (even if they are older than gems in a >>> gem-repo). It's based on bkabrda's patch [1]. >> >> I don't think the patch does exactly that. It reshuffles dependencies so >> that local ones are looked at first. That includes *any* local >> dependency, of which there can be several. Probably what's going to >> happen is that it's going to pick the latest local dependency that >> satisfies gem spec. I don't think this is what you want, however... >> >> -d >>> >>> >>> I'll ensure that our gem repo [2] contains all gems needed for katello >>> development (some are still missing). This enables katello (rails app) >>> to be installed on any system without rubygems.org. >>> >>> I would like to work on this in the next iteration. Also I would like >>> to explore how difficult would be to create gem versions with security >>> patches (which is important for non fedora development - me). >>> >>> We also discussed it would be nice to move our gem-repo to github a >>> publish it on pages.github. The repo would be more visible. It would >>> allow us to use pull-requests for tracking new gem-dependencies. It >>> would be on one place. >>> >>> Petr >>> >>> [1] https://gist.github.com/2875212 >>> [2] http://repos.fedorapeople.org/repos/katello/gems/ >>> >>> _______________________________________________ >>> 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 hbrock at redhat.com Wed Aug 22 14:46:58 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 22 Aug 2012 10:46:58 -0400 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034EE8C.5080306@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> <20120822141416.GN3044@lzapx.brq.redhat.com> <5034EC7D.1030000@redhat.com> <5034EE8C.5080306@redhat.com> Message-ID: <20120822144657.GM15992@redhat.com> On Wed, Aug 22, 2012 at 03:37:00PM +0100, Dmitri Dolguikh wrote: > On 22/08/12 03:28 PM, Petr Chalupa wrote: > >We already discussed solution with Gemfile.lock. There are issues. > > > >- You would have to have Gemfile.lock for f16, f17, el62, el63 > >- You would habe to have Gemfile.lock for production and development > >- You will have update it every time when some version of gem or > >rpm change in some of f16, f17, el62, el63 > > Hmmm. What if we bundled dependencies when we are tagging for a > specific platform (and stripped them when packaging into rpm)? > Troubleshooting would be quite simple then - we could even look at > rhel issues on fedora... > > -d Could work, definitely worth looking into. Our solution thus far has been: Upstream deployment with gem-only uses Gemfile.lock and user-space gems. We control Gemfile.lock pretty tightly and we really only need one version across platforms given a standard .rvmrc that also specifies the Ruby version we use. For RHEL deployment we move away Gemfile.lock altogether and bundler uses system-installed RPM-based gems. I would contend that system packaging details like this -- i.e. what RPMs are required on a particular platform, the associated spec files, etc. -- are packaging details that do *not* belong in the upstream project tree. This is the standard for most upstream projects in the C world -- libvirt, for example, does not maintain RPM specfiles for Fedora or RHEL in its upstream tree and the standard upstream install is via ./configure; make; make install. The RPM specs and build dependencies are tracked separately, as are .deb packaging scripts, etc. I'm not saying this is the only way to handle this situation but it is the standard for many upstream projects. Take care, --Hugh > > > >It seems to me quite clumsy. > > > >Petr > > > >On 22.08.12 16:14, Lukas Zapletal wrote: > >>On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote: > >>>FWIW, our Gemfile.lock is in git. We don't accept changes to it without > >>>patch review, etc. etc. Seems to work reasonably well. > >> > >>Our first experience was not that good, but truth is, now we do use > >>github.com and pull requests. On the other hand, the lock file looks > >>very messy. You guys are able to track it all? > >> > >>The general rule could be - no changes at all except adding new > >>dependencies (after discussion on the list of course :-) > >> > > > >_______________________________________________ > >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 pchalupa at redhat.com Wed Aug 22 14:58:16 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 16:58:16 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034EE8C.5080306@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> <20120822141416.GN3044@lzapx.brq.redhat.com> <5034EC7D.1030000@redhat.com> <5034EE8C.5080306@redhat.com> Message-ID: <5034F388.20703@redhat.com> This would give you only a production dependencies but not the development one. Imho it would not work. Petr On 22.08.12 16:37, Dmitri Dolguikh wrote: > On 22/08/12 03:28 PM, Petr Chalupa wrote: >> We already discussed solution with Gemfile.lock. There are issues. >> >> - You would have to have Gemfile.lock for f16, f17, el62, el63 >> - You would habe to have Gemfile.lock for production and development >> - You will have update it every time when some version of gem or rpm >> change in some of f16, f17, el62, el63 > > Hmmm. What if we bundled dependencies when we are tagging for a specific > platform (and stripped them when packaging into rpm)? Troubleshooting > would be quite simple then - we could even look at rhel issues on fedora... > > -d > >> >> >> It seems to me quite clumsy. >> >> Petr >> >> On 22.08.12 16:14, Lukas Zapletal wrote: >>> On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote: >>>> FWIW, our Gemfile.lock is in git. We don't accept changes to it without >>>> patch review, etc. etc. Seems to work reasonably well. >>> >>> Our first experience was not that good, but truth is, now we do use >>> github.com and pull requests. On the other hand, the lock file looks >>> very messy. You guys are able to track it all? >>> >>> The general rule could be - no changes at all except adding new >>> dependencies (after discussion on the list of course :-) >>> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From pchalupa at redhat.com Wed Aug 22 15:02:18 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 17:02:18 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822144657.GM15992@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> <20120822141416.GN3044@lzapx.brq.redhat.com> <5034EC7D.1030000@redhat.com> <5034EE8C.5080306@redhat.com> <20120822144657.GM15992@redhat.com> Message-ID: <5034F47A.8010508@redhat.com> For RHEL deployment we move away Gemfile.lock altogether, this will work. But you do not have a way how to install rest of the development dependencies on RHEL, keep the older rpm-gems and install corecct versions of development gems. Petr On 22.08.12 16:46, Hugh Brock wrote: > On Wed, Aug 22, 2012 at 03:37:00PM +0100, Dmitri Dolguikh wrote: >> On 22/08/12 03:28 PM, Petr Chalupa wrote: >>> We already discussed solution with Gemfile.lock. There are issues. >>> >>> - You would have to have Gemfile.lock for f16, f17, el62, el63 >>> - You would habe to have Gemfile.lock for production and development >>> - You will have update it every time when some version of gem or >>> rpm change in some of f16, f17, el62, el63 >> >> Hmmm. What if we bundled dependencies when we are tagging for a >> specific platform (and stripped them when packaging into rpm)? >> Troubleshooting would be quite simple then - we could even look at >> rhel issues on fedora... >> >> -d > > Could work, definitely worth looking into. > > Our solution thus far has been: Upstream deployment with gem-only uses > Gemfile.lock and user-space gems. We control Gemfile.lock pretty tightly > and we really only need one version across platforms given a standard > .rvmrc that also specifies the Ruby version we use. > > For RHEL deployment we move away Gemfile.lock altogether and bundler > uses system-installed RPM-based gems. I would contend that system > packaging details like this -- i.e. what RPMs are required on a > particular platform, the associated spec files, etc. -- are packaging > details that do *not* belong in the upstream project tree. This is the > standard for most upstream projects in the C world -- libvirt, for > example, does not maintain RPM specfiles for Fedora or RHEL in its > upstream tree and the standard upstream install is via ./configure; > make; make install. The RPM specs and build dependencies are tracked > separately, as are .deb packaging scripts, etc. > > I'm not saying this is the only way to handle this situation but it is > the standard for many upstream projects. > > Take care, > --Hugh > >>> >>> It seems to me quite clumsy. >>> >>> Petr >>> >>> On 22.08.12 16:14, Lukas Zapletal wrote: >>>> On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote: >>>>> FWIW, our Gemfile.lock is in git. We don't accept changes to it without >>>>> patch review, etc. etc. Seems to work reasonably well. >>>> >>>> Our first experience was not that good, but truth is, now we do use >>>> github.com and pull requests. On the other hand, the lock file looks >>>> very messy. You guys are able to track it all? >>>> >>>> The general rule could be - no changes at all except adding new >>>> dependencies (after discussion on the list of course :-) >>>> >>> >>> _______________________________________________ >>> 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 vvaldez at redhat.com Wed Aug 22 15:04:56 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Wed, 22 Aug 2012 10:04:56 -0500 Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: <740C557F-F7C5-487A-BFD5-E620114D04EC@redhat.com> References: <1394860223.12209501.1345565847192.JavaMail.root@redhat.com> <740C557F-F7C5-487A-BFD5-E620114D04EC@redhat.com> Message-ID: Eric, This version is ready to publish: http://people.redhat.com/vvaldez/videos/katello/katello-01-setup.mov I added some more detail to the install, a bit more audio, a cleaner exit, as well as replaced all the terminal footage with larger text so it would be more readable (thanks to Scott Collier for detailed review). The only request I have is that when you upload this to the youtube channel, if you can add annotations to a spot at the beginning that points the viewer to katello.org and at the end that points to the other katello URLs (I can assist with this when the time comes). I'll work on the rest of the videos as time permits. Regards, Vinny On Aug 21, 2012, at 12:05 PM, Vincent Valdez wrote: > I'm tweaking a couple things, should be ready tonight. > > Vinny > > On Aug 21, 2012, at 11:17 AM, Eric Helms wrote: > >> We have not - was waiting on the green light from Vinny. >> >> - Eric >> >> ----- Original Message ----- >> From: "Bryan Kearney" >> To: "Vinny Valdez" >> Cc: katello-devel at redhat.com >> Sent: Tuesday, August 21, 2012 12:05:36 PM >> Subject: Re: [katello-devel] Do you want to be a movie star? >> >> On 08/21/2012 11:33 AM, Vinny Valdez wrote: >>> On Aug 21, 2012, at 7:32 AM, Bryan Kearney wrote: >>> >>>> On 08/20/2012 11:33 AM, Vinny Valdez wrote: >>>>> On Aug 19, 2012, at 9:12 AM, Bryan Kearney wrote: >>>>> >>>>>> On 08/18/2012 04:48 PM, Vinny Valdez wrote: >>>>>>> On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: >>>>>>> >>>>>>>> Team, >>>>>>>> >>>>>>>> I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts >>>>>>>> >>>>>>>> We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Vinny >>>>>>>> >>>>>>>> >>>>>>>> On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: >>>>>>>> >>>>>>>>> Do you want to be a star, and help promote Katello. Have we got a deal for you: >>>>>>>>> >>>>>>>>> https://fedorahosted.org/katello/wiki/Screencasts >>>>>>>>> >>>>>>>>> -- bk >>>>>>> >>>>>>> The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. >>>>>>> >>>>>>> http://people.redhat.com/vvaldez/videos/katello/ >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Vinny >>>>>> This looks good! what software did you use to create this? There appears to be some text at the bottom when you log in which talks about the CLI? Is this the "how to do it in the CLI" version? >>>>>> >>>>>> -- bk >>>>> >>>>> Thanks everyone, >>>>> >>>>> I used ScreenFlow: http://www.telestream.net/screen-flow/ for recording and editing, Audacity for audio, and Openshot/Inkscape for the intro/outros. >>>> So.. recorded on a mac? >>> Yes, I used a F16 VM to do everything, and just cropped out the rest of the desktop. Is that an issue? I can re-record in RecordMyDesktop or ffmpeg directly, but there will be very few effects I can replicate, and the entire process will take much longer. >> >> Not an issue, was just curious. >> >>> >>>>> >>>>> Yes, I was attempting to combine both the UI and CLI videos in one. I wasn't very explicit, but was trying to show the CLI commands at the same time the action was performed from the UI. Thoughts on that? >>>> >>>> I liked the model. >>> Great, I'll move forward on the others the same way. >> >> Cool! Eric, have we posted this yet? >> >> -- 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 msuchy at redhat.com Wed Aug 22 15:15:52 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 22 Aug 2012 17:15:52 +0200 Subject: [katello-devel] Consumer and goferd In-Reply-To: <20120822124255.GD3044@lzapx.brq.redhat.com> References: <20120822124255.GD3044@lzapx.brq.redhat.com> Message-ID: <5034F7A8.7000003@redhat.com> On 08/22/2012 02:42 PM, Lukas Zapletal wrote: > I found we are missing one another step: > > * Make sure goferd daemon is started to use Katello Agent > > It looks like a decent amount of work to bootstrap a system now. Isn't > a time to start a bootstrap script that would be distributed in the > /pub/html directory (maybe as an example too) +1 -- Miroslav Suchy Red Hat Systems Management Engineering From pchalupa at redhat.com Wed Aug 22 15:19:43 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 17:19:43 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034E122.1090009@redhat.com> References: <50349AB6.8060505@redhat.com> <20120822130314.GG3044@lzapx.brq.redhat.com> <5034DA2E.9080604@redhat.com> <20120822131541.GJ3044@lzapx.brq.redhat.com> <5034E122.1090009@redhat.com> Message-ID: <5034F88F.3080204@redhat.com> I didn't go that far for 'bundle install' to be able to install gems as on on any of these platforms. But it could be done. This solution allows you to have one repository. In it would contain all gems corresponding with f16 deployment and all development gems. When you bundle install on non-rpm machine you get same result as on f16 including development dependencies. When you bundle install on fedora 16 rpm-gems are used instead of gems and same development dependencies are installed. When you bundle install on rhel rpm-gems are used instead of gems (some will be older than on fedora) and same development dependencies are installed. Petr On 22.08.12 15:39, Dmitri Dolguikh wrote: > On 22/08/12 02:15 PM, Lukas Zapletal wrote: >> On Wed, Aug 22, 2012 at 02:10:06PM +0100, Dmitri Dolguikh wrote: >>>> source 'http://fedorapeople.org/groups/katello/gems/f16' >>>> #source 'http://fedorapeople.org/groups/katello/gems/f17' >>>> #source 'http://fedorapeople.org/groups/katello/gems/el6' >>>> source 'http://fedorapeople.org/groups/katello/gems/dev' >>> are we developing on all of those???? or simply deploying on those? >> We should all be able to develop/test on those. Let's say you have >> Fedora 17 only bug and you need to start it with F17 gems (because you >> can't reproduce it on your setup). >> >> If we are going to generate those gem repos, I'd like to have such a >> chance. It's for free. > if active development is happening on all of those, it's going to be a > problem: those have different versions of gems (and that's not taking > into account 1.9.3) - I don't think we can manage that using Bundler (in > fact, that's against Bundler's goals). > > We could use platform-specific branches though? > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From ehelms at redhat.com Wed Aug 22 15:20:25 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 22 Aug 2012 11:20:25 -0400 (EDT) Subject: [katello-devel] Do you want to be a movie star? In-Reply-To: Message-ID: <405800938.12586023.1345648825533.JavaMail.root@redhat.com> This is awesome Vinny! I am taking care of adding it as I type this and will send an annoucement email with links once it is up and running. -Eric ----- Original Message ----- From: "Vinny Valdez" To: "Eric Helms" Cc: katello-devel at redhat.com, "Scott Collier" Sent: Wednesday, August 22, 2012 11:04:56 AM Subject: Re: [katello-devel] Do you want to be a movie star? Eric, This version is ready to publish: http://people.redhat.com/vvaldez/videos/katello/katello-01-setup.mov I added some more detail to the install, a bit more audio, a cleaner exit, as well as replaced all the terminal footage with larger text so it would be more readable (thanks to Scott Collier for detailed review). The only request I have is that when you upload this to the youtube channel, if you can add annotations to a spot at the beginning that points the viewer to katello.org and at the end that points to the other katello URLs (I can assist with this when the time comes). I'll work on the rest of the videos as time permits. Regards, Vinny On Aug 21, 2012, at 12:05 PM, Vincent Valdez wrote: > I'm tweaking a couple things, should be ready tonight. > > Vinny > > On Aug 21, 2012, at 11:17 AM, Eric Helms wrote: > >> We have not - was waiting on the green light from Vinny. >> >> - Eric >> >> ----- Original Message ----- >> From: "Bryan Kearney" >> To: "Vinny Valdez" >> Cc: katello-devel at redhat.com >> Sent: Tuesday, August 21, 2012 12:05:36 PM >> Subject: Re: [katello-devel] Do you want to be a movie star? >> >> On 08/21/2012 11:33 AM, Vinny Valdez wrote: >>> On Aug 21, 2012, at 7:32 AM, Bryan Kearney wrote: >>> >>>> On 08/20/2012 11:33 AM, Vinny Valdez wrote: >>>>> On Aug 19, 2012, at 9:12 AM, Bryan Kearney wrote: >>>>> >>>>>> On 08/18/2012 04:48 PM, Vinny Valdez wrote: >>>>>>> On Aug 15, 2012, at 3:02 PM, Vinny Valdez wrote: >>>>>>> >>>>>>>> Team, >>>>>>>> >>>>>>>> I started working on these screencasts. Scott Collier and myself are going to split the work and try to get these done soon. I already have some footage of the initial setup, but wanted to request a review on the outlines I put together (taken from the fedorahosted wiki page). Everything is here: https://github.com/vvaldez/katello-screencasts >>>>>>>> >>>>>>>> We're hoping for some feedback on exactly what kind of user/role setup should be shown, maybe some assistance on system groups. Currently I recorded creating a "template admin" user and role, but I can certainly expand this more. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Vinny >>>>>>>> >>>>>>>> >>>>>>>> On Jul 18, 2012, at 12:33 PM, Bryan Kearney wrote: >>>>>>>> >>>>>>>>> Do you want to be a star, and help promote Katello. Have we got a deal for you: >>>>>>>>> >>>>>>>>> https://fedorahosted.org/katello/wiki/Screencasts >>>>>>>>> >>>>>>>>> -- bk >>>>>>> >>>>>>> The first video is ready for review. Please let me know if the volume is too low, if there are any issues with playback on any devices, codec preferences, quality issues, suggestions, etc. >>>>>>> >>>>>>> http://people.redhat.com/vvaldez/videos/katello/ >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Vinny >>>>>> This looks good! what software did you use to create this? There appears to be some text at the bottom when you log in which talks about the CLI? Is this the "how to do it in the CLI" version? >>>>>> >>>>>> -- bk >>>>> >>>>> Thanks everyone, >>>>> >>>>> I used ScreenFlow: http://www.telestream.net/screen-flow/ for recording and editing, Audacity for audio, and Openshot/Inkscape for the intro/outros. >>>> So.. recorded on a mac? >>> Yes, I used a F16 VM to do everything, and just cropped out the rest of the desktop. Is that an issue? I can re-record in RecordMyDesktop or ffmpeg directly, but there will be very few effects I can replicate, and the entire process will take much longer. >> >> Not an issue, was just curious. >> >>> >>>>> >>>>> Yes, I was attempting to combine both the UI and CLI videos in one. I wasn't very explicit, but was trying to show the CLI commands at the same time the action was performed from the UI. Thoughts on that? >>>> >>>> I liked the model. >>> Great, I'll move forward on the others the same way. >> >> Cool! Eric, have we posted this yet? >> >> -- 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 dmitri at redhat.com Wed Aug 22 15:21:12 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 16:21:12 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <50349CCB.70603@redhat.com> References: <50349AB6.8060505@redhat.com> <50349CCB.70603@redhat.com> Message-ID: <5034F8E8.2020702@redhat.com> On 22/08/12 09:48 AM, Dmitri Dolguikh wrote: > Hey Petr, > I have a fix for this in my local branch, using aeolus' bundler_ext > [1] (which is now a gem). The only thing remaining is to create an rpm > for the gem, and make some minor changes to katello.spec. > > We can chat more if you'd like... > > [1] https://github.com/aeolus-incubator/bundler_ext > > -d > > On 22/08/12 09:39 AM, Petr Chalupa wrote: >> Hi, >> >> as Ivan and Lukas said on mail-list, I had some ideas how to solve >> our bundler/rpm issues. Then I had discussion with Ivan and Mirek and >> here is the proposed solution. >> >> == Requirements >> >> When installing on fedora/rhel in production. Do not mess with the >> production setup, rpm gems are used, 'bundle install' wont install >> anything else. >> >> When installing on fedora/rhel in development. 'bundle install' >> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >> Additional development dependencies are installed. Just realized that bundler supports this too. Create a group for development dependencies, install katello from rpm, run 'bundler install development' to install development-only gems. -d >> >> When installing on any other system (Debian, Ubuntu, Mac, ...) in >> development. 'bundle install' installs the same versions of gems as >> would be installed on fedora. Optionally (at least made it possible >> in the future) 'bundle install' installs not only the same versions >> but also gems including security fixes included in rpm-gems. >> >> == Proposal >> >> I'll add monkey patch to katello/master for bundler which will ensure >> that rpm-gems are preferred (even if they are older than gems in a >> gem-repo). It's based on bkabrda's patch [1]. >> >> I'll ensure that our gem repo [2] contains all gems needed for >> katello development (some are still missing). This enables katello >> (rails app) to be installed on any system without rubygems.org. >> >> I would like to work on this in the next iteration. Also I would like >> to explore how difficult would be to create gem versions with >> security patches (which is important for non fedora development - me). >> >> We also discussed it would be nice to move our gem-repo to github a >> publish it on pages.github. The repo would be more visible. It would >> allow us to use pull-requests for tracking new gem-dependencies. It >> would be on one place. >> >> Petr >> >> [1] https://gist.github.com/2875212 >> [2] http://repos.fedorapeople.org/repos/katello/gems/ >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From omaciel at redhat.com Wed Aug 22 15:24:33 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 22 Aug 2012 11:24:33 -0400 (EDT) Subject: [katello-devel] Consumer and goferd In-Reply-To: <5034F7A8.7000003@redhat.com> Message-ID: <1063617212.17239432.1345649073800.JavaMail.root@redhat.com> > On 08/22/2012 02:42 PM, Lukas Zapletal wrote: > > I found we are missing one another step: > > > > * Make sure goferd daemon is started to use Katello Agent A while back I had suggested we automatically got goferd started if someone installed katello-agent but those who replied told me we should do it... which I never agreed :) I feel that as an end user, I want to subscribe my system and automatically be able to use the web ui to install/remove and manage content. -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From pchalupa at redhat.com Wed Aug 22 15:25:58 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 17:25:58 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034F8E8.2020702@redhat.com> References: <50349AB6.8060505@redhat.com> <50349CCB.70603@redhat.com> <5034F8E8.2020702@redhat.com> Message-ID: <5034FA06.40808@redhat.com> Interesting :), did you try to: - yum install katello-all - run bundle install development - run katello I am not sure if bundler finds rpm-gems because they are not in Gemfile.lock, from bundlers point of view they are not present. Petr On 22.08.12 17:21, Dmitri Dolguikh wrote: > On 22/08/12 09:48 AM, Dmitri Dolguikh wrote: >> Hey Petr, >> I have a fix for this in my local branch, using aeolus' bundler_ext >> [1] (which is now a gem). The only thing remaining is to create an rpm >> for the gem, and make some minor changes to katello.spec. >> >> We can chat more if you'd like... >> >> [1] https://github.com/aeolus-incubator/bundler_ext >> >> -d >> >> On 22/08/12 09:39 AM, Petr Chalupa wrote: >>> Hi, >>> >>> as Ivan and Lukas said on mail-list, I had some ideas how to solve >>> our bundler/rpm issues. Then I had discussion with Ivan and Mirek and >>> here is the proposed solution. >>> >>> == Requirements >>> >>> When installing on fedora/rhel in production. Do not mess with the >>> production setup, rpm gems are used, 'bundle install' wont install >>> anything else. >>> >>> When installing on fedora/rhel in development. 'bundle install' >>> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >>> Additional development dependencies are installed. > > Just realized that bundler supports this too. Create a group for > development dependencies, install katello from rpm, run 'bundler install > development' to install development-only gems. > > -d > >>> >>> When installing on any other system (Debian, Ubuntu, Mac, ...) in >>> development. 'bundle install' installs the same versions of gems as >>> would be installed on fedora. Optionally (at least made it possible >>> in the future) 'bundle install' installs not only the same versions >>> but also gems including security fixes included in rpm-gems. >>> >>> == Proposal >>> >>> I'll add monkey patch to katello/master for bundler which will ensure >>> that rpm-gems are preferred (even if they are older than gems in a >>> gem-repo). It's based on bkabrda's patch [1]. >>> >>> I'll ensure that our gem repo [2] contains all gems needed for >>> katello development (some are still missing). This enables katello >>> (rails app) to be installed on any system without rubygems.org. >>> >>> I would like to work on this in the next iteration. Also I would like >>> to explore how difficult would be to create gem versions with >>> security patches (which is important for non fedora development - me). >>> >>> We also discussed it would be nice to move our gem-repo to github a >>> publish it on pages.github. The repo would be more visible. It would >>> allow us to use pull-requests for tracking new gem-dependencies. It >>> would be on one place. >>> >>> Petr >>> >>> [1] https://gist.github.com/2875212 >>> [2] http://repos.fedorapeople.org/repos/katello/gems/ >>> >>> _______________________________________________ >>> 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 hbrock at redhat.com Wed Aug 22 15:26:26 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 22 Aug 2012 11:26:26 -0400 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034F47A.8010508@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> <20120822141416.GN3044@lzapx.brq.redhat.com> <5034EC7D.1030000@redhat.com> <5034EE8C.5080306@redhat.com> <20120822144657.GM15992@redhat.com> <5034F47A.8010508@redhat.com> Message-ID: <20120822152625.GN15992@redhat.com> On Wed, Aug 22, 2012 at 05:02:18PM +0200, Petr Chalupa wrote: > For RHEL deployment we move away Gemfile.lock altogether, this will > work. But you do not have a way how to install rest of the > development dependencies on RHEL, keep the older rpm-gems and > install corecct versions of development gems. Hmm... well, OK, I think we need to get precise about exactly what the goal is here. Should you want to develop on RHEL -- fix bugs, do new work, whatever -- I believe the best way to do that going forward is going to be via a DSC. In other words, forget the native RHEL stack altogether since it will be of no help. We don't currently have a blessed DSC for Cloudforms on RHEL but I believe we need to get there ASAP. Given a suitable RHEL production DSC and a parallel development DSC, you can develop nicely on an RPM-based system without having to worry so much about getting packages into RHEL proper. Should you want to develop on Fedora or another non-production platform, use gems, and ideally the packaged versions of your dependencies for that platform. I would like to have a DSC that would work on fedora as well, since I don't believe the native Fedora ruby platform offers much more value than the antiquated one in RHEL. Happy to hear what's wrong with this, but just keep in mind that we want to keep packaging overhead to an absolute minimum. --Hugh > > On 22.08.12 16:46, Hugh Brock wrote: > >On Wed, Aug 22, 2012 at 03:37:00PM +0100, Dmitri Dolguikh wrote: > >>On 22/08/12 03:28 PM, Petr Chalupa wrote: > >>>We already discussed solution with Gemfile.lock. There are issues. > >>> > >>>- You would have to have Gemfile.lock for f16, f17, el62, el63 > >>>- You would habe to have Gemfile.lock for production and development > >>>- You will have update it every time when some version of gem or > >>>rpm change in some of f16, f17, el62, el63 > >> > >>Hmmm. What if we bundled dependencies when we are tagging for a > >>specific platform (and stripped them when packaging into rpm)? > >>Troubleshooting would be quite simple then - we could even look at > >>rhel issues on fedora... > >> > >>-d > > > >Could work, definitely worth looking into. > > > >Our solution thus far has been: Upstream deployment with gem-only uses > >Gemfile.lock and user-space gems. We control Gemfile.lock pretty tightly > >and we really only need one version across platforms given a standard > >.rvmrc that also specifies the Ruby version we use. > > > >For RHEL deployment we move away Gemfile.lock altogether and bundler > >uses system-installed RPM-based gems. I would contend that system > >packaging details like this -- i.e. what RPMs are required on a > >particular platform, the associated spec files, etc. -- are packaging > >details that do *not* belong in the upstream project tree. This is the > >standard for most upstream projects in the C world -- libvirt, for > >example, does not maintain RPM specfiles for Fedora or RHEL in its > >upstream tree and the standard upstream install is via ./configure; > >make; make install. The RPM specs and build dependencies are tracked > >separately, as are .deb packaging scripts, etc. > > > >I'm not saying this is the only way to handle this situation but it is > >the standard for many upstream projects. > > > >Take care, > >--Hugh > > > >>> > >>>It seems to me quite clumsy. > >>> > >>>Petr > >>> > >>>On 22.08.12 16:14, Lukas Zapletal wrote: > >>>>On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote: > >>>>>FWIW, our Gemfile.lock is in git. We don't accept changes to it without > >>>>>patch review, etc. etc. Seems to work reasonably well. > >>>> > >>>>Our first experience was not that good, but truth is, now we do use > >>>>github.com and pull requests. On the other hand, the lock file looks > >>>>very messy. You guys are able to track it all? > >>>> > >>>>The general rule could be - no changes at all except adding new > >>>>dependencies (after discussion on the list of course :-) > >>>> > >>> > >>>_______________________________________________ > >>>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 -- == 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 dmitri at redhat.com Wed Aug 22 15:29:40 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 16:29:40 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034FA06.40808@redhat.com> References: <50349AB6.8060505@redhat.com> <50349CCB.70603@redhat.com> <5034F8E8.2020702@redhat.com> <5034FA06.40808@redhat.com> Message-ID: <5034FAE4.5010604@redhat.com> On 22/08/12 04:25 PM, Petr Chalupa wrote: > Interesting :), did you try to: > > - yum install katello-all > - run bundle install development > - run katello > > I am not sure if bundler finds rpm-gems because they are not in > Gemfile.lock, from bundlers point of view they are not present. bundle install development --without deployment -d > > Petr > > On 22.08.12 17:21, Dmitri Dolguikh wrote: >> On 22/08/12 09:48 AM, Dmitri Dolguikh wrote: >>> Hey Petr, >>> I have a fix for this in my local branch, using aeolus' bundler_ext >>> [1] (which is now a gem). The only thing remaining is to create an rpm >>> for the gem, and make some minor changes to katello.spec. >>> >>> We can chat more if you'd like... >>> >>> [1] https://github.com/aeolus-incubator/bundler_ext >>> >>> -d >>> >>> On 22/08/12 09:39 AM, Petr Chalupa wrote: >>>> Hi, >>>> >>>> as Ivan and Lukas said on mail-list, I had some ideas how to solve >>>> our bundler/rpm issues. Then I had discussion with Ivan and Mirek and >>>> here is the proposed solution. >>>> >>>> == Requirements >>>> >>>> When installing on fedora/rhel in production. Do not mess with the >>>> production setup, rpm gems are used, 'bundle install' wont install >>>> anything else. >>>> >>>> When installing on fedora/rhel in development. 'bundle install' >>>> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >>>> Additional development dependencies are installed. >> >> Just realized that bundler supports this too. Create a group for >> development dependencies, install katello from rpm, run 'bundler install >> development' to install development-only gems. >> >> -d >> >>>> >>>> When installing on any other system (Debian, Ubuntu, Mac, ...) in >>>> development. 'bundle install' installs the same versions of gems as >>>> would be installed on fedora. Optionally (at least made it possible >>>> in the future) 'bundle install' installs not only the same versions >>>> but also gems including security fixes included in rpm-gems. >>>> >>>> == Proposal >>>> >>>> I'll add monkey patch to katello/master for bundler which will ensure >>>> that rpm-gems are preferred (even if they are older than gems in a >>>> gem-repo). It's based on bkabrda's patch [1]. >>>> >>>> I'll ensure that our gem repo [2] contains all gems needed for >>>> katello development (some are still missing). This enables katello >>>> (rails app) to be installed on any system without rubygems.org. >>>> >>>> I would like to work on this in the next iteration. Also I would like >>>> to explore how difficult would be to create gem versions with >>>> security patches (which is important for non fedora development - me). >>>> >>>> We also discussed it would be nice to move our gem-repo to github a >>>> publish it on pages.github. The repo would be more visible. It would >>>> allow us to use pull-requests for tracking new gem-dependencies. It >>>> would be on one place. >>>> >>>> Petr >>>> >>>> [1] https://gist.github.com/2875212 >>>> [2] http://repos.fedorapeople.org/repos/katello/gems/ >>>> >>>> _______________________________________________ >>>> 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 msuchy at redhat.com Wed Aug 22 15:32:58 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Wed, 22 Aug 2012 17:32:58 +0200 Subject: [katello-devel] Consumer and goferd In-Reply-To: <1063617212.17239432.1345649073800.JavaMail.root@redhat.com> References: <1063617212.17239432.1345649073800.JavaMail.root@redhat.com> Message-ID: <5034FBAA.2090502@redhat.com> On 08/22/2012 05:24 PM, Og Maciel wrote: >> On 08/22/2012 02:42 PM, Lukas Zapletal wrote: >>> I found we are missing one another step: >>> >>> * Make sure goferd daemon is started to use Katello Agent > > A while back I had suggested we automatically got goferd started if someone installed katello-agent but those who replied told me we should do it... which I never agreed :) I feel that as an end user, I want to subscribe my system and automatically be able to use the web ui to install/remove and manage content. > http://fedoraproject.org/wiki/Packaging:SysVInitScript#Why_don.27t_we.... Why don't we.... start the service after installation? Installations can be in changeroots, in an installer context, or in other situations where you don't want the services started. -- Miroslav Suchy Red Hat Systems Management Engineering From pchalupa at redhat.com Wed Aug 22 15:39:50 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 22 Aug 2012 17:39:50 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034FAE4.5010604@redhat.com> References: <50349AB6.8060505@redhat.com> <50349CCB.70603@redhat.com> <5034F8E8.2020702@redhat.com> <5034FA06.40808@redhat.com> <5034FAE4.5010604@redhat.com> Message-ID: <5034FD46.9050001@redhat.com> Sorry we probably misunderstood each other, I think the problem will be when you try run the server. When bundler tries to require gems, it wont know which gems to require because deployment gems weren't installed and theirs dependencies weren't resolved when 'bundle install development --without deployment' is run. Petr On 22.08.12 17:29, Dmitri Dolguikh wrote: > On 22/08/12 04:25 PM, Petr Chalupa wrote: >> Interesting :), did you try to: >> >> - yum install katello-all >> - run bundle install development >> - run katello >> >> I am not sure if bundler finds rpm-gems because they are not in >> Gemfile.lock, from bundlers point of view they are not present. > bundle install development --without deployment > -d > >> >> Petr >> >> On 22.08.12 17:21, Dmitri Dolguikh wrote: >>> On 22/08/12 09:48 AM, Dmitri Dolguikh wrote: >>>> Hey Petr, >>>> I have a fix for this in my local branch, using aeolus' bundler_ext >>>> [1] (which is now a gem). The only thing remaining is to create an rpm >>>> for the gem, and make some minor changes to katello.spec. >>>> >>>> We can chat more if you'd like... >>>> >>>> [1] https://github.com/aeolus-incubator/bundler_ext >>>> >>>> -d >>>> >>>> On 22/08/12 09:39 AM, Petr Chalupa wrote: >>>>> Hi, >>>>> >>>>> as Ivan and Lukas said on mail-list, I had some ideas how to solve >>>>> our bundler/rpm issues. Then I had discussion with Ivan and Mirek and >>>>> here is the proposed solution. >>>>> >>>>> == Requirements >>>>> >>>>> When installing on fedora/rhel in production. Do not mess with the >>>>> production setup, rpm gems are used, 'bundle install' wont install >>>>> anything else. >>>>> >>>>> When installing on fedora/rhel in development. 'bundle install' >>>>> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >>>>> Additional development dependencies are installed. >>> >>> Just realized that bundler supports this too. Create a group for >>> development dependencies, install katello from rpm, run 'bundler install >>> development' to install development-only gems. >>> >>> -d >>> >>>>> >>>>> When installing on any other system (Debian, Ubuntu, Mac, ...) in >>>>> development. 'bundle install' installs the same versions of gems as >>>>> would be installed on fedora. Optionally (at least made it possible >>>>> in the future) 'bundle install' installs not only the same versions >>>>> but also gems including security fixes included in rpm-gems. >>>>> >>>>> == Proposal >>>>> >>>>> I'll add monkey patch to katello/master for bundler which will ensure >>>>> that rpm-gems are preferred (even if they are older than gems in a >>>>> gem-repo). It's based on bkabrda's patch [1]. >>>>> >>>>> I'll ensure that our gem repo [2] contains all gems needed for >>>>> katello development (some are still missing). This enables katello >>>>> (rails app) to be installed on any system without rubygems.org. >>>>> >>>>> I would like to work on this in the next iteration. Also I would like >>>>> to explore how difficult would be to create gem versions with >>>>> security patches (which is important for non fedora development - me). >>>>> >>>>> We also discussed it would be nice to move our gem-repo to github a >>>>> publish it on pages.github. The repo would be more visible. It would >>>>> allow us to use pull-requests for tracking new gem-dependencies. It >>>>> would be on one place. >>>>> >>>>> Petr >>>>> >>>>> [1] https://gist.github.com/2875212 >>>>> [2] http://repos.fedorapeople.org/repos/katello/gems/ >>>>> >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From omaciel at redhat.com Wed Aug 22 15:48:08 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 22 Aug 2012 11:48:08 -0400 (EDT) Subject: [katello-devel] Consumer and goferd In-Reply-To: <5034FBAA.2090502@redhat.com> Message-ID: <1340859379.17256613.1345650488767.JavaMail.root@redhat.com> > http://fedoraproject.org/wiki/Packaging:SysVInitScript#Why_don.27t_we.... > > > Why don't we.... start the service after installation? > > Installations can be in changeroots, in an installer context, or in > other situations where you don't want the services started. But what is the most likely scenario? I'm thinking that enterprise would expect things to just work if I install katello-agent *specially* if this for deploying systems that I just created. -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From msuchy at redhat.com Wed Aug 22 15:52:54 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Wed, 22 Aug 2012 17:52:54 +0200 Subject: [katello-devel] Consumer and goferd In-Reply-To: <1340859379.17256613.1345650488767.JavaMail.root@redhat.com> References: <1340859379.17256613.1345650488767.JavaMail.root@redhat.com> Message-ID: <50350056.7050608@redhat.com> On 08/22/2012 05:48 PM, Og Maciel wrote: > But what is the most likely scenario? If you are building community release, you may target "most likely scenario". But enterprise solution should work "always". > I'm thinking that enterprise would expect things to just work if I install katello-agent*specially* if this for deploying systems that I just created. I agree. Jut it should not be enabled in rpm %post scriplet, but in bootstrap script, rhsm, %post of kickstart or firstboot. Whatever. But not rpm %post scriplet. -- Miroslav Suchy Red Hat Systems Management Engineering From dmitri at redhat.com Wed Aug 22 15:53:51 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 22 Aug 2012 16:53:51 +0100 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034FD46.9050001@redhat.com> References: <50349AB6.8060505@redhat.com> <50349CCB.70603@redhat.com> <5034F8E8.2020702@redhat.com> <5034FA06.40808@redhat.com> <5034FAE4.5010604@redhat.com> <5034FD46.9050001@redhat.com> Message-ID: <5035008F.6050106@redhat.com> On 22/08/12 04:39 PM, Petr Chalupa wrote: > Sorry we probably misunderstood each other, I think the problem will > be when you try run the server. When bundler tries to require gems, it > wont know which gems to require because deployment gems weren't > installed and theirs dependencies weren't resolved when 'bundle > install development --without deployment' is run. ahh, yes I was answering a different question. To answer yours - in some cases bundle install --local would work, but only if the dependencies available locally are satisfactory (have you looked into using this instead of your approach?). Otherwise bundler_ext would work too, since it simply ignores versioning, and "loads" (not in ruby sense of the word) the latest gem version available. -d > > Petr > > On 22.08.12 17:29, Dmitri Dolguikh wrote: >> On 22/08/12 04:25 PM, Petr Chalupa wrote: >>> Interesting :), did you try to: >>> >>> - yum install katello-all >>> - run bundle install development >>> - run katello >>> >>> I am not sure if bundler finds rpm-gems because they are not in >>> Gemfile.lock, from bundlers point of view they are not present. >> bundle install development --without deployment >> -d >> >>> >>> Petr >>> >>> On 22.08.12 17:21, Dmitri Dolguikh wrote: >>>> On 22/08/12 09:48 AM, Dmitri Dolguikh wrote: >>>>> Hey Petr, >>>>> I have a fix for this in my local branch, using aeolus' bundler_ext >>>>> [1] (which is now a gem). The only thing remaining is to create an >>>>> rpm >>>>> for the gem, and make some minor changes to katello.spec. >>>>> >>>>> We can chat more if you'd like... >>>>> >>>>> [1] https://github.com/aeolus-incubator/bundler_ext >>>>> >>>>> -d >>>>> >>>>> On 22/08/12 09:39 AM, Petr Chalupa wrote: >>>>>> Hi, >>>>>> >>>>>> as Ivan and Lukas said on mail-list, I had some ideas how to solve >>>>>> our bundler/rpm issues. Then I had discussion with Ivan and Mirek >>>>>> and >>>>>> here is the proposed solution. >>>>>> >>>>>> == Requirements >>>>>> >>>>>> When installing on fedora/rhel in production. Do not mess with the >>>>>> production setup, rpm gems are used, 'bundle install' wont install >>>>>> anything else. >>>>>> >>>>>> When installing on fedora/rhel in development. 'bundle install' >>>>>> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >>>>>> Additional development dependencies are installed. >>>> >>>> Just realized that bundler supports this too. Create a group for >>>> development dependencies, install katello from rpm, run 'bundler >>>> install >>>> development' to install development-only gems. >>>> >>>> -d >>>> >>>>>> >>>>>> When installing on any other system (Debian, Ubuntu, Mac, ...) in >>>>>> development. 'bundle install' installs the same versions of gems as >>>>>> would be installed on fedora. Optionally (at least made it possible >>>>>> in the future) 'bundle install' installs not only the same versions >>>>>> but also gems including security fixes included in rpm-gems. >>>>>> >>>>>> == Proposal >>>>>> >>>>>> I'll add monkey patch to katello/master for bundler which will >>>>>> ensure >>>>>> that rpm-gems are preferred (even if they are older than gems in a >>>>>> gem-repo). It's based on bkabrda's patch [1]. >>>>>> >>>>>> I'll ensure that our gem repo [2] contains all gems needed for >>>>>> katello development (some are still missing). This enables katello >>>>>> (rails app) to be installed on any system without rubygems.org. >>>>>> >>>>>> I would like to work on this in the next iteration. Also I would >>>>>> like >>>>>> to explore how difficult would be to create gem versions with >>>>>> security patches (which is important for non fedora development - >>>>>> me). >>>>>> >>>>>> We also discussed it would be nice to move our gem-repo to github a >>>>>> publish it on pages.github. The repo would be more visible. It would >>>>>> allow us to use pull-requests for tracking new gem-dependencies. It >>>>>> would be on one place. >>>>>> >>>>>> Petr >>>>>> >>>>>> [1] https://gist.github.com/2875212 >>>>>> [2] http://repos.fedorapeople.org/repos/katello/gems/ >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> _______________________________________________ >> 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 omaciel at redhat.com Wed Aug 22 15:54:47 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 22 Aug 2012 11:54:47 -0400 (EDT) Subject: [katello-devel] Consumer and goferd In-Reply-To: <50350056.7050608@redhat.com> Message-ID: <1296727853.17265061.1345650887761.JavaMail.root@redhat.com> Sounds like we're in agreement then :) -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From mmccune at redhat.com Wed Aug 22 16:39:23 2012 From: mmccune at redhat.com (Mike McCune) Date: Wed, 22 Aug 2012 09:39:23 -0700 Subject: [katello-devel] Consumer and goferd In-Reply-To: <50350056.7050608@redhat.com> References: <1340859379.17256613.1345650488767.JavaMail.root@redhat.com> <50350056.7050608@redhat.com> Message-ID: <50350B3B.2090404@redhat.com> On 08/22/2012 08:52 AM, Miroslav Such? wrote: > On 08/22/2012 05:48 PM, Og Maciel wrote: >> But what is the most likely scenario? > > If you are building community release, you may target "most likely > scenario". But enterprise solution should work "always". > >> I'm thinking that enterprise would expect things to just work if I install katello-agent*specially* if this for deploying systems that I just created. > > I agree. > > Jut it should not be enabled in rpm %post scriplet, but in bootstrap > script, rhsm, %post of kickstart or firstboot. Whatever. But not rpm > %post scriplet. > > +1 -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From jsherril at redhat.com Wed Aug 22 16:46:40 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 22 Aug 2012 12:46:40 -0400 Subject: [katello-devel] Consumer and goferd In-Reply-To: <20120822124255.GD3044@lzapx.brq.redhat.com> References: <20120822124255.GD3044@lzapx.brq.redhat.com> Message-ID: <50350CF0.9050306@redhat.com> On 08/22/2012 08:42 AM, Lukas Zapletal wrote: > Hello, > > I noticed when we install katello-cert-consumer bootstrap RPM which > deploys Katello server certificate (also used for Katello Agent), it > does not restart goferd when it is not running. It only restarts it when > it is running. > > Now, I wonder if we want to keep this. Because then the client bootstrap > process is missing one step - by default goferd is turned off and not > started (after provisioning). > > Currently, to write correct bootstrap script that can be used to > provision systems, you need several actions: > > * Make sure a time synchronizer is installed and enabled on a provisioned > system > * Install all Katello client components (*) > * Configure the client (using RPM bootstrap package preferably) > * Register the client (with activation keys preferably) > * Optionally subscribe to repositories (when immediate content consumption > is necessary) > > (*) - these steps are not necessary for RHEL systems, albeit this does > not apply to RHEL clones. > > I found we are missing one another step: > > * Make sure goferd daemon is started to use Katello Agent > > It looks like a decent amount of work to bootstrap a system now. Isn't > a time to start a bootstrap script that would be distributed in the > /pub/html directory (maybe as an example too)? > Any disadvantages to putting that script in the bootstrap rpm and having the user running it versus downloading a script from /pub/ and running that (in addition to installing the bootstrap rpm). I always felt the script in /pub was kinda hacky (although it got the job done). +1 to a script vs %post regardless. -Justin From jsherril at redhat.com Wed Aug 22 17:07:56 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 22 Aug 2012 13:07:56 -0400 Subject: [katello-devel] Foreman integration model question In-Reply-To: <5034CFE5.1080702@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> Message-ID: <503511EC.1060701@redhat.com> On 08/22/2012 08:26 AM, Petr Chalupa wrote: > Lukas is right, our motivation was to break the code into smaller > pieces (I am big fan of SOLID and 'single responsibility principle' in > particular). If you write code this way, you can then move things > around very quickly so you can develop features and fix bugs faster. > No to mention it can be testes more easily. > > app/models/user.rb (User) is representation of katello user which > mixes (if foreman is installed) foreman orchestration > app/models/glue/forema/user.rb. Orchestration is working with foreman > through children of ForemanModel which are representation of remote > resources app/models/foreman/user.rb (Foreman::User). Foreman::User is > using foreman-api bindings which are defined as singletons in > lib/resources/foreman.rb. > > So there are 4 layers: > - katello model > - foreman-katello orchestration > - foreman model (remote resource) > - foreman bindings (gem foreman-api) > > I also for splitting up big parts. I do like this auto generated api method better (aside from there being two distinct User models). To say a downside of the current model is a giant single file pulp.rb is kinda moot, as that was just how it was organized, we can organize it differently quite easily. What we are doing here with foreman is wayyyy more than just organizing it differently, its a fairly completely different way of orchestrating things, bypassing our lazy_accessor magic. For example, lets say we do the same with environment, where there is a katello environment and a foreman environment. And lets say there is some special piece of information only stored in foreman (this is not a far-fetched scenario). With our current orchestration you would do something like: a = KTEnvironment.find(3) print a.remote_attribute a.remote_attribute = "foo" a.save! whereas the way i see it now, we'd have to do: a = KTEnvironment.find(3) a.foreman_user.remote_attribute = "foo" a.save! I don't really like this better as you'd have to remember which backend engine a particular attribute is. Today you don't. I don't really expect any of these arguments to change the way we are doing anything, its just annoying to change our entire way of working with a backend engine without any discussion :) We need to be aware that doing it this way is creating a 2nd way with working with fully (or partially) remote objects and that needs to be clear and apparent. It also needs to be justified :) -Justin > > Petr > > On 22.08.12 10:19, Lukas Zapletal wrote: >> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: >>> Taking user for example we would have: >>> >>> user.rb >>> glue/pulp/user.rb >> >> But you are missing one piece of the puzzle: >> >> lib/resources/pulp.rb (class User) >> >> And that is the piece which you can find in foreman/user.rb. >> >>> What I see with foreman is: >>> >>> user.rb >>> glue/foreman/user.rb >>> foreman/user.rb >> >> So instead having all the resources in a single class >> (lib/resources/foreman.rb), we are going to have (or better - generate) >> all resource (read also as "dumb") classes. Each in separate file. >> >>> Where foreman/user is a second class that can be instantiated and >>> used on its own, while glue/foreman/user.rb is simply the >>> orchestration to create that object. I see the use of >>> Resources::ForemanModel, but in this user instance the foreman user >>> could be manipulated completely apart from the katello user (which >>> is bad IMHO). This also is completely different from our existing >>> orchestration methods. >> >> Yes, it is different. I like this approach more. Creating a one instance >> per request is nothing, while the code is definitely better than eight >> hundred lines long pulp.rb with all the resources there as "class" >> methods. >> >> I think this is the correct approach and we may discuss splitting those >> big resource files in future into smaller pieces for other backend >> engines too. If we write a similar generator, we wont longer need to >> write them manually (and we will be able to track API changes too). >> >> I was not writing the code, but I believe those instances are treated >> like singletons, so you do not need to create instances by yourself: >> >> https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb >> >> >> Guys please elaborate what the intentions are. >> > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From vvaldez at redhat.com Wed Aug 22 19:10:31 2012 From: vvaldez at redhat.com (Vinny Valdez) Date: Wed, 22 Aug 2012 14:10:31 -0500 Subject: [katello-devel] Katello screencast video series released Message-ID: The first video in the katello screencast series has been released. This video covers initial installation, katello-configure, setting up a default org, environments, users, and roles. Please share it out and look for additional videos soon. http://www.youtube.com/user/KatelloProject http://www.katello.org/videos/ Thanks, Vinny -------------- next part -------------- An HTML attachment was scrubbed... URL: From ehelms at redhat.com Wed Aug 22 19:30:20 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 22 Aug 2012 15:30:20 -0400 (EDT) Subject: [katello-devel] Foreman integration model question In-Reply-To: <503511EC.1060701@redhat.com> Message-ID: <1937152775.12679504.1345663820300.JavaMail.root@redhat.com> Given the scenario you proffered, Justin - I am going to agree-disagree with you on one point. These arguments SHOULD change the way we are approaching orchestration. If I am in an abstraction layer (e.g. a UI controller) I should not have to know about the underlying orchestration layers (i.e. I shouldn't have to know to look a.foreman_user). The whole point of layers of abstraction is to hide the magic and present a consistent way to interact with the layers below that is appropriate for the layer you are in at the time. Unless I missed something, the concept of Katello is to take backend services that do one thing really well, and provide a level of abstraction and a set of higher level concepts on top of these backend services to produce a cohesive application. Our layers and interactions should also reflect this architecture in a consistent manner. +1 to our orchestration approach (and thus architecture) should be consistent - Eric ----- Original Message ----- From: "Justin Sherrill" To: katello-devel at redhat.com Sent: Wednesday, August 22, 2012 1:07:56 PM Subject: Re: [katello-devel] Foreman integration model question On 08/22/2012 08:26 AM, Petr Chalupa wrote: > Lukas is right, our motivation was to break the code into smaller > pieces (I am big fan of SOLID and 'single responsibility principle' in > particular). If you write code this way, you can then move things > around very quickly so you can develop features and fix bugs faster. > No to mention it can be testes more easily. > > app/models/user.rb (User) is representation of katello user which > mixes (if foreman is installed) foreman orchestration > app/models/glue/forema/user.rb. Orchestration is working with foreman > through children of ForemanModel which are representation of remote > resources app/models/foreman/user.rb (Foreman::User). Foreman::User is > using foreman-api bindings which are defined as singletons in > lib/resources/foreman.rb. > > So there are 4 layers: > - katello model > - foreman-katello orchestration > - foreman model (remote resource) > - foreman bindings (gem foreman-api) > > I also for splitting up big parts. I do like this auto generated api method better (aside from there being two distinct User models). To say a downside of the current model is a giant single file pulp.rb is kinda moot, as that was just how it was organized, we can organize it differently quite easily. What we are doing here with foreman is wayyyy more than just organizing it differently, its a fairly completely different way of orchestrating things, bypassing our lazy_accessor magic. For example, lets say we do the same with environment, where there is a katello environment and a foreman environment. And lets say there is some special piece of information only stored in foreman (this is not a far-fetched scenario). With our current orchestration you would do something like: a = KTEnvironment.find(3) print a.remote_attribute a.remote_attribute = "foo" a.save! whereas the way i see it now, we'd have to do: a = KTEnvironment.find(3) a.foreman_user.remote_attribute = "foo" a.save! I don't really like this better as you'd have to remember which backend engine a particular attribute is. Today you don't. I don't really expect any of these arguments to change the way we are doing anything, its just annoying to change our entire way of working with a backend engine without any discussion :) We need to be aware that doing it this way is creating a 2nd way with working with fully (or partially) remote objects and that needs to be clear and apparent. It also needs to be justified :) -Justin > > Petr > > On 22.08.12 10:19, Lukas Zapletal wrote: >> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: >>> Taking user for example we would have: >>> >>> user.rb >>> glue/pulp/user.rb >> >> But you are missing one piece of the puzzle: >> >> lib/resources/pulp.rb (class User) >> >> And that is the piece which you can find in foreman/user.rb. >> >>> What I see with foreman is: >>> >>> user.rb >>> glue/foreman/user.rb >>> foreman/user.rb >> >> So instead having all the resources in a single class >> (lib/resources/foreman.rb), we are going to have (or better - generate) >> all resource (read also as "dumb") classes. Each in separate file. >> >>> Where foreman/user is a second class that can be instantiated and >>> used on its own, while glue/foreman/user.rb is simply the >>> orchestration to create that object. I see the use of >>> Resources::ForemanModel, but in this user instance the foreman user >>> could be manipulated completely apart from the katello user (which >>> is bad IMHO). This also is completely different from our existing >>> orchestration methods. >> >> Yes, it is different. I like this approach more. Creating a one instance >> per request is nothing, while the code is definitely better than eight >> hundred lines long pulp.rb with all the resources there as "class" >> methods. >> >> I think this is the correct approach and we may discuss splitting those >> big resource files in future into smaller pieces for other backend >> engines too. If we write a similar generator, we wont longer need to >> write them manually (and we will be able to track API changes too). >> >> I was not writing the code, but I believe those instances are treated >> like singletons, so you do not need to create instances by yourself: >> >> https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb >> >> >> Guys please elaborate what the intentions are. >> > > _______________________________________________ > 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 esammons at redhat.com Wed Aug 22 19:33:32 2012 From: esammons at redhat.com (Eric Sammons) Date: Wed, 22 Aug 2012 15:33:32 -0400 (EDT) Subject: [katello-devel] Installing katello-headpin-all fails with /etc/katello/client.conf conflicts In-Reply-To: <1411362689.18206403.1345663795138.JavaMail.root@redhat.com> Message-ID: <595847294.18257798.1345664012722.JavaMail.root@redhat.com> Heads up, it seems as though three packages are providing the same file when in fact only the common package should. Trying to do a yum install katello-headpin-all results in the following error: ''' Transaction Check Error: file /etc/katello/client.conf conflicts between attempted installs of katello-cli-headpin-1.1.0-1.git.14.d10e8a3.fc16.noarch and katello-cli-common-1.1.2-1.git.162.09c0162.fc16.noarch ''' Further investigation using yum whatprovides reveals the following: ''' katello-cli-1.1.2-1.git.162.09c0162.fc16.noarch : Client package for managing ...: application life-cycle for Linux systems Repo : katello Matched from: Filename : /etc/katello/client.conf katello-cli-common-1.1.2-1.git.162.09c0162.fc16.noarch : Common Katello client : bits Repo : katello Matched from: Filename : /etc/katello/client.conf katello-cli-headpin-1.1.0-1.git.14.d10e8a3.fc16.noarch : Client package for ...: managing a katello-headpin installation Repo : katello Matched from: Filename : /etc/katello/client.conf ''' Because katello-cli-common is required by both katello-cli-headpin and katello-cli it seems that client.conf should only be provided by katello-cli-common. I have opened https://bugzilla.redhat.com/show_bug.cgi?id=850935 for this. -- +--------------------------------------------------------+ | Eric L. Sammons esammons at redhat.com | | Senior Quality Assurance Engineer irc: eanxgeek | | Red Hat Quality Engineering 919.754.4963 (w) | | rhce # 805007668329332 919.889.3279 (c) | | rhcva # 805007668329332 | +--------------------------------------------------------+ From jomara at redhat.com Wed Aug 22 19:45:42 2012 From: jomara at redhat.com (Jordan OMara) Date: Wed, 22 Aug 2012 15:45:42 -0400 Subject: [katello-devel] Installing katello-headpin-all fails with /etc/katello/client.conf conflicts In-Reply-To: <595847294.18257798.1345664012722.JavaMail.root@redhat.com> References: <1411362689.18206403.1345663795138.JavaMail.root@redhat.com> <595847294.18257798.1345664012722.JavaMail.root@redhat.com> Message-ID: <20120822194541.GA49540@redhat.com> On 22/08/12 15:33 -0400, Eric Sammons wrote: >Heads up, it seems as though three packages are providing the same file when in fact only the common package should. Trying to do a yum install katello-headpin-all results in the following error: > >''' >Transaction Check Error: > file /etc/katello/client.conf conflicts between attempted installs of katello-cli-headpin-1.1.0-1.git.14.d10e8a3.fc16.noarch and katello-cli-common-1.1.2-1.git.162.09c0162.fc16.noarch >''' > Looks like a regression of: https://bugzilla.redhat.com/show_bug.cgi?id=832462 I'll take a look right now -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From msuchy at redhat.com Wed Aug 22 20:27:31 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Wed, 22 Aug 2012 22:27:31 +0200 Subject: [katello-devel] Installing katello-headpin-all fails with /etc/katello/client.conf conflicts In-Reply-To: <595847294.18257798.1345664012722.JavaMail.root@redhat.com> References: <595847294.18257798.1345664012722.JavaMail.root@redhat.com> Message-ID: <503540B3.9010500@redhat.com> On 22.8.2012 21:33, Eric Sammons wrote: > I have openedhttps://bugzilla.redhat.com/show_bug.cgi?id=850935 for this. Fixed. Mirek From msuchy at redhat.com Wed Aug 22 20:29:08 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Wed, 22 Aug 2012 22:29:08 +0200 Subject: [katello-devel] Installing katello-headpin-all fails with /etc/katello/client.conf conflicts In-Reply-To: <20120822194541.GA49540@redhat.com> References: <1411362689.18206403.1345663795138.JavaMail.root@redhat.com> <595847294.18257798.1345664012722.JavaMail.root@redhat.com> <20120822194541.GA49540@redhat.com> Message-ID: <50354114.3060401@redhat.com> On 22.8.2012 21:45, Jordan OMara wrote: > Looks like a regression of: > https://bugzilla.redhat.com/show_bug.cgi?id=832462 No, it was caused by: https://bugzilla.redhat.com/show_bug.cgi?id=822926 Mirek From jomara at redhat.com Wed Aug 22 20:37:45 2012 From: jomara at redhat.com (Jordan OMara) Date: Wed, 22 Aug 2012 16:37:45 -0400 Subject: [katello-devel] Installing katello-headpin-all fails with /etc/katello/client.conf conflicts In-Reply-To: <50354114.3060401@redhat.com> References: <1411362689.18206403.1345663795138.JavaMail.root@redhat.com> <595847294.18257798.1345664012722.JavaMail.root@redhat.com> <20120822194541.GA49540@redhat.com> <50354114.3060401@redhat.com> Message-ID: <20120822203745.GB49540@redhat.com> On 22/08/12 22:29 +0200, Miroslav Suchy wrote: >On 22.8.2012 21:45, Jordan OMara wrote: >>Looks like a regression of: >>https://bugzilla.redhat.com/show_bug.cgi?id=832462 > >No, it was caused by: >https://bugzilla.redhat.com/show_bug.cgi?id=822926 > +1 good call -- 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 mmccune at redhat.com Wed Aug 22 23:50:17 2012 From: mmccune at redhat.com (Mike McCune) Date: Wed, 22 Aug 2012 16:50:17 -0700 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5034DA2E.9080604@redhat.com> References: <50349AB6.8060505@redhat.com> <20120822130314.GG3044@lzapx.brq.redhat.com> <5034DA2E.9080604@redhat.com> Message-ID: <50357039.9050809@redhat.com> On 08/22/2012 06:10 AM, Dmitri Dolguikh wrote: > On 22/08/12 02:03 PM, Lukas Zapletal wrote: >> On Wed, Aug 22, 2012 at 10:39:18AM +0200, Petr Chalupa wrote: >>> == Requirements >>> >>> When installing on fedora/rhel in production. Do not mess with the >>> production setup, rpm gems are used, 'bundle install' wont install >>> anything else. >>> >>> When installing on fedora/rhel in development. 'bundle install' >>> prefers rpm-gems even if there is a newer gem in our gem-repo [2]. >>> Additional development dependencies are installed. >>> >>> When installing on any other system (Debian, Ubuntu, Mac, ...) in >>> development. 'bundle install' installs the same versions of gems as >>> would be installed on fedora. Optionally (at least made it possible >>> in the future) 'bundle install' installs not only the same versions >>> but also gems including security fixes included in rpm-gems. >>> >> Question - the very same version from which fedora version? >> >> I would like to see four gem repos instead of one. Fedora 16/17 (two >> last stable versions) and RHEL6. Plus one repo with development gems >> (versions does not matter here - we do not deploy them to the users). >> Then we would have something like: >> >> source 'http://fedorapeople.org/groups/katello/gems/f16' >> #source 'http://fedorapeople.org/groups/katello/gems/f17' >> #source 'http://fedorapeople.org/groups/katello/gems/el6' >> source 'http://fedorapeople.org/groups/katello/gems/dev' > are we developing on all of those???? or simply deploying on those? > -d absolutely, I dev on RHEL6, others dev on F16 and and soon others will on F17 as well. Mike From dmitri at redhat.com Thu Aug 23 06:37:13 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 23 Aug 2012 07:37:13 +0100 Subject: [katello-devel] developing & deploying on multiple platforms Message-ID: <5035CF99.9010905@redhat.com> Hey all, We currently have two, soon to be three platforms that we support: RHEL 6.3+ (client and server), F16, and F17. I'll talk about support (AKA production deployment) and development separately. Support. Each of the platforms has its own set of ruby-gems that it ships with, and we use in our deployment on said platform. I propose that for each of deployment platforms we create a branch, and *bundle* and potentially freeze (in bundler sense of the word) all of that platform dependencies, including development ones. We tag it, just like we usually do, when we generate an rpm for that platform. The benefits of this approach are: - no need for multiple gem repositories (this stuff is slowly changing on support-platforms) - deployment setup is easily and consistently replicated on any platform (and saves us from situations when newer development dependency relies on a production dependency that is not available on a given platform) - packaging-specific information is kept away from the main development branch Development. We use the same set of newer version of dependencies on any platform (including those above). We develop using gems, changing Gemfile as often as required. We convert gems to rpms as we go - this is similar to Conductor development model. The benefits of this approach are: - very easy to update/modify dependencies - no need to maintain custom gem repository, we can rely on rubygems.com - development setup is easily and consistently replicated on any platform Thoughts/opinions? -d From msuchy at redhat.com Thu Aug 23 10:21:00 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Thu, 23 Aug 2012 12:21:00 +0200 Subject: [katello-devel] developing & deploying on multiple platforms In-Reply-To: <5035CF99.9010905@redhat.com> References: <5035CF99.9010905@redhat.com> Message-ID: <5036040C.1090605@redhat.com> On 08/23/2012 08:37 AM, Dmitri Dolguikh wrote: > I propose that for each of deployment platforms we create a branch, and > *bundle* and potentially freeze (in bundler sense of the word) all of > that platform dependencies, including development ones. We tag it, just > like we usually do, when we generate an rpm for that platform. You mean branching katello.git? And have branch el6, F16, ...? Who will maintain it? -9999999999 -- Miroslav Suchy Red Hat Systems Management Engineering From dmitri at redhat.com Thu Aug 23 10:28:49 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 23 Aug 2012 11:28:49 +0100 Subject: [katello-devel] developing & deploying on multiple platforms In-Reply-To: <5036040C.1090605@redhat.com> References: <5035CF99.9010905@redhat.com> <5036040C.1090605@redhat.com> Message-ID: <503605E1.409@redhat.com> On 23/08/12 11:21 AM, Miroslav Such? wrote: > On 08/23/2012 08:37 AM, Dmitri Dolguikh wrote: >> I propose that for each of deployment platforms we create a branch, and >> *bundle* and potentially freeze (in bundler sense of the word) all of >> that platform dependencies, including development ones. We tag it, just >> like we usually do, when we generate an rpm for that platform. > > You mean branching katello.git? And have branch el6, F16, ...? > > Who will maintain it? > -9999999999 > This is not meant for development, only to generate rpms and help with troubleshooting, so that an environment can be easily created. The desire to be able to easily re-create production environment, but with development libraries was expressed by a few people. What would you suggest? -d From pchalupa at redhat.com Thu Aug 23 11:56:38 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Thu, 23 Aug 2012 13:56:38 +0200 Subject: [katello-devel] Bundler vs rpm-gems - in more detail Message-ID: <50361A76.2070003@redhat.com> My original email raised a lot of questions, I should wrote it with more details. I apology for that. I'll try again and elaborate. = Goals 1) To be able to implement the solution in a week or so. 2) Not to affect deployment, keep it same way as now. 3) When you are installing development environment on any rpm-based system rpm-gems are used even if they are older then gems in our gem-repo. (this is borken right now) 4) When you are installing development environment in any non-rpm-base system you get installed gems as close as possible to what would you get on fedora 16. (you cannot install with bundle install only right now) * (optionally including the security patches, lets discuss this later) = What was discussed, why I think it wont work == Branch for each platform * There would be little difference between the branches (only Gemfile or Gemfile.lock). Rest of the code will be same. * It would be too much work to maintain it. == Gemfile.lock per platform and environment * We would have to have 8 Gemfile.locks and maintain them all (4 platforms multiplied by two environments) * Too much work unless its automated. * Automation would take time to setup. == Aeolus solution, bundler_ext [2] * Dependencies resolution is unaffected so 'bundle install' cannot be used to install development dependencies, it would ignore rpm-gems and install gems from gem-repo. * If bundler_ext is used for setup development environment, control over which versions are required is lost (requiring is not done by bundler) * It affects only how requirements are loaded [1], it's useful only for deployment. * (We could use it in deployment to get rid of bundler, but that is out of this discussion's scope see Goal.2) == bundle install --without default This installs only development gems, but: * If some of the development gems has a production gem as dependency (eg. ActiveSupport), the gem is reinstalled by bundler from a gem-repo over the older rpm-gem. * If only development gems are installed, bundler cannot be used to require gems. It will raise LoadError because from bundler's point of view production gems are not installed. * It would have to be combined with bundler_ext to find production rpm-gems, so you would loose control over which version are loaded again * If you forget to add '--without default' when you run 'bundle install' unwanted versions are installed. == vendor/cache Move all gems to src/vendor/cache (directly into katello/master or as a git sub-module) and remove sources form Gemfile completely. 'bundle install' installs gems form vendor/cache automatically if there are no sources in Gemfile. * to have .gem files directly in katello/master is ugly * submodules are real pain * git is not that good with binary data = My proposal == Bundler patch * it would be loaded in Gemfile, so every tool using bundler will get it * it would ensure that if rpm-gem is present it's used even if there is newer version available in gem-repo * ensure that locally installed gems are not confused with rpm-gems * patch is optional, can be turned on/off by ENV variable or by options * (I am also considering to add optional check that all production gems are installed as rpms) Deployment is unaffected, all dependencies are satisfied by rpm-gems. When you run bundle install to get development environment on any rpm-based machine, all your rpms have priority and they are used. All missing development gems are installed from our gem-repo. On non-rpm-based machine, 'bundle install' installs all gems production and development from our gem-repo. == Gem Repository Bundler patch will work only if all development and production gems are in the gem-repo. To get it fixed quickly 'bundle package' can be used to get all the gems. Missing gems can be then uploaded to katello-thirdparty (source for our gem-repo) = Summary I think that Bundler patch and updating gem-repo to contain all gems is the only one which can be done fast and will work on any machine in deployment and development. I tried to be thorough but if I missed something or if you have better ideas please let me know. Petr [1] https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 [2] https://github.com/aeolus-incubator/bundler_ext From lzap at redhat.com Thu Aug 23 12:05:37 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 23 Aug 2012 14:05:37 +0200 Subject: [katello-devel] Consumer and goferd In-Reply-To: <20120822124255.GD3044@lzapx.brq.redhat.com> References: <20120822124255.GD3044@lzapx.brq.redhat.com> Message-ID: <20120823120537.GC3116@lzapx.brq.redhat.com> Ok, here is the example bootstrap session: https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient#Examplebootstrapsession This is how users should bootstrap their machines NOW with Katello. LZ On Wed, Aug 22, 2012 at 02:42:55PM +0200, Lukas Zapletal wrote: > Hello, > > I noticed when we install katello-cert-consumer bootstrap RPM which > deploys Katello server certificate (also used for Katello Agent), it > does not restart goferd when it is not running. It only restarts it when > it is running. > > Now, I wonder if we want to keep this. Because then the client bootstrap > process is missing one step - by default goferd is turned off and not > started (after provisioning). > > Currently, to write correct bootstrap script that can be used to > provision systems, you need several actions: > > * Make sure a time synchronizer is installed and enabled on a provisioned > system > * Install all Katello client components (*) > * Configure the client (using RPM bootstrap package preferably) > * Register the client (with activation keys preferably) > * Optionally subscribe to repositories (when immediate content consumption > is necessary) > > (*) - these steps are not necessary for RHEL systems, albeit this does > not apply to RHEL clones. > > I found we are missing one another step: > > * Make sure goferd daemon is started to use Katello Agent > > It looks like a decent amount of work to bootstrap a system now. Isn't > a time to start a bootstrap script that would be distributed in the > /pub/html directory (maybe as an example too)? > > -- > 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 Thu Aug 23 12:10:48 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 23 Aug 2012 14:10:48 +0200 Subject: [katello-devel] Foreman integration model question In-Reply-To: <503511EC.1060701@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> <503511EC.1060701@redhat.com> Message-ID: <20120823121048.GD3116@lzapx.brq.redhat.com> On Wed, Aug 22, 2012 at 01:07:56PM -0400, Justin Sherrill wrote: > With our current orchestration you would do something like: > > a = KTEnvironment.find(3) > print a.remote_attribute > a.remote_attribute = "foo" > a.save! > > whereas the way i see it now, we'd have to do: > > a = KTEnvironment.find(3) > a.foreman_user.remote_attribute = "foo" > a.save! > > I don't really like this better as you'd have to remember which +1 We should stay consistent in this case. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Thu Aug 23 12:13:14 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 23 Aug 2012 08:13:14 -0400 Subject: [katello-devel] Consumer and goferd In-Reply-To: <20120823120537.GC3116@lzapx.brq.redhat.com> References: <20120822124255.GD3044@lzapx.brq.redhat.com> <20120823120537.GC3116@lzapx.brq.redhat.com> Message-ID: <50361E5A.5070805@redhat.com> On 08/23/2012 08:05 AM, Lukas Zapletal wrote: > Ok, here is the example bootstrap session: > > https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient#Examplebootstrapsession > > This is how users should bootstrap their machines NOW with Katello. > > LZ If the agent fails nicely when the machine is not registered, why not just chkconfig it on by default? seems wierd to have to deal with it out of band. -- bk From jlabocki at redhat.com Thu Aug 23 12:25:26 2012 From: jlabocki at redhat.com (James Labocki) Date: Thu, 23 Aug 2012 08:25:26 -0400 (EDT) Subject: [katello-devel] Deployable and System Template Portability In-Reply-To: Message-ID: <826803306.12948243.1345724726580.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Justin Clift" > To: "Hugh O. Brock" > Cc: aeolus-devel at lists.fedorahosted.org, "James Labocki" , katello-devel at redhat.com, "Bryan > Kearney" > Sent: Thursday, August 23, 2012 6:40:43 AM > Subject: Re: [katello-devel] Deployable and System Template Portability > > On 22/08/2012, at 11:44 PM, Hugh Brock wrote: > > >> It sounds like a good idea at first glance, but I would be worried > >> that all implementations would differ so widely. Maybe if when an > >> application blueprint is imported in aeolus it could check if all > >> the proper images exist (sort of like a checksum for a system > >> image) and also could provide guidance on what packages are > >> needed in each image? This would require aeolus having a deeper > >> understanding of the katello environment. > > > > The issue here is that we identify images by UUID, so no image is > > ever > > going to match from one Conductor setup to another. IOW there is no > > way > > Conductor *could* check to see "if the proper images exist" on > > importing a blueprint, given the current setup. > > > > We'd need to have two things to fix this: > > > > 1. A way to guarantee image equivalence. Katello will have this > > before > > all that long with content views > > > > 2. Given 1, a way to identify images that actually are equivalent. > > > > These things are doable but not necessarily easy. Doesn't mean we > > shouldn't do them of course... > > As a potentially easy first step, and ignoring the nascent templates > site for now, we can probably ship some default reference deployables > with Aeolus right now. ie.: > > Apache HTTP Server > JBoss Server (of some appropriate sort) > MySQL Server > Nginx Server > PostgreSQL Server > > We could "reserve" some of the UUID address range for these > kind of templates. ie: > > 00000000-0000-0000-0000-xxxxxxxxxxxx > > And then have the reference ones use known UUIDS: > > Apache HTTP Server == 00000000-0000-0000-0000-000000000001 > JBoss Server == 00000000-0000-0000-0000-000000000002 > MySQL Server == 00000000-0000-0000-0000-000000000003 > Nginx Server == 00000000-0000-0000-0000-000000000004 > PostgreSQL Server == 00000000-0000-0000-0000-000000000005 > > We'd probably add an aeolus-configure option for adding them. > > i.e.: > > $ sudo aeolus-configure -p rhevm,vsphere,ec2,templates > > If someone doesn't want to use those templates they don't > have to. However, most places will probably keep around > the ones they have use for. > > The above probably wouldn't be too hard to implement either, > and gives people a kick start in getting running. Would the templates already be binary images or component outlines pointing to a repo to build? If templates, would it be difficult to ship large binary images around as part of Aeolus? If component outlines, where would the point for packages? It would be nice if the `aeolus-configure -p templates` option were coordinated with `katello-configure -p templates`. This would mean that all a user would need to do is: 1. `yum install aeolus-all` 2. `yum install katello-all` 3. `katello-configure -p templates` 4. import Red Hat Manifest and sync appropriate repos in katello (which might be highlighted by the "templates" configure option in katello) 5. `aeolus-configure -p templates` 6. build images (or maybe the "templates" option can kick builds off on behalf of the user?) Having a way to share images between clouds in aeolus would also be nice in this scenario because it would be possible to move images between a "stage" could and "my" cloud if the images were built in a staging area. Let me know if this sounds way off. > > + Justin > > -- > Aeolus Community Manager > http://www.aeolusproject.org > > From msuchy at redhat.com Thu Aug 23 12:28:59 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Thu, 23 Aug 2012 14:28:59 +0200 Subject: [katello-devel] Consumer and goferd In-Reply-To: <20120823120537.GC3116@lzapx.brq.redhat.com> References: <20120822124255.GD3044@lzapx.brq.redhat.com> <20120823120537.GC3116@lzapx.brq.redhat.com> Message-ID: <5036220B.2050004@redhat.com> On 08/23/2012 02:05 PM, Lukas Zapletal wrote: > Ok, here is the example bootstrap session: > > https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient#Examplebootstrapsession > > This is how users should bootstrap their machines NOW with Katello. > > chkconfig ntpd on What about service start? >#cat > /etc/yum.repos.d/katello-client.repo <<'EOF' We should remove this ASAP. Because it will not work on i386. But it means to resolve this one first: https://bugzilla.redhat.com/show_bug.cgi?id=845643 Somebody who is fedora packager, please pick this up. -- Miroslav Suchy Red Hat Systems Management Engineering From lzap at redhat.com Thu Aug 23 12:34:50 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 23 Aug 2012 14:34:50 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120822152625.GN15992@redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> <20120822141416.GN3044@lzapx.brq.redhat.com> <5034EC7D.1030000@redhat.com> <5034EE8C.5080306@redhat.com> <20120822144657.GM15992@redhat.com> <5034F47A.8010508@redhat.com> <20120822152625.GN15992@redhat.com> Message-ID: <20120823123450.GF3116@lzapx.brq.redhat.com> What's DSC? LZ On Wed, Aug 22, 2012 at 11:26:26AM -0400, Hugh Brock wrote: > On Wed, Aug 22, 2012 at 05:02:18PM +0200, Petr Chalupa wrote: > > For RHEL deployment we move away Gemfile.lock altogether, this will > > work. But you do not have a way how to install rest of the > > development dependencies on RHEL, keep the older rpm-gems and > > install corecct versions of development gems. > > Hmm... well, OK, I think we need to get precise about exactly what the > goal is here. > > Should you want to develop on RHEL -- fix bugs, do new work, whatever -- > I believe the best way to do that going forward is going to be via a > DSC. In other words, forget the native RHEL stack altogether since it > will be of no help. We don't currently have a blessed DSC for Cloudforms > on RHEL but I believe we need to get there ASAP. Given a suitable RHEL > production DSC and a parallel development DSC, you can develop nicely on > an RPM-based system without having to worry so much about getting > packages into RHEL proper. > > Should you want to develop on Fedora or another non-production platform, > use gems, and ideally the packaged versions of your dependencies for > that platform. I would like to have a DSC that would work on fedora as > well, since I don't believe the native Fedora ruby platform offers much > more value than the antiquated one in RHEL. > > Happy to hear what's wrong with this, but just keep in mind that we want > to keep packaging overhead to an absolute minimum. > > --Hugh > > > > > On 22.08.12 16:46, Hugh Brock wrote: > > >On Wed, Aug 22, 2012 at 03:37:00PM +0100, Dmitri Dolguikh wrote: > > >>On 22/08/12 03:28 PM, Petr Chalupa wrote: > > >>>We already discussed solution with Gemfile.lock. There are issues. > > >>> > > >>>- You would have to have Gemfile.lock for f16, f17, el62, el63 > > >>>- You would habe to have Gemfile.lock for production and development > > >>>- You will have update it every time when some version of gem or > > >>>rpm change in some of f16, f17, el62, el63 > > >> > > >>Hmmm. What if we bundled dependencies when we are tagging for a > > >>specific platform (and stripped them when packaging into rpm)? > > >>Troubleshooting would be quite simple then - we could even look at > > >>rhel issues on fedora... > > >> > > >>-d > > > > > >Could work, definitely worth looking into. > > > > > >Our solution thus far has been: Upstream deployment with gem-only uses > > >Gemfile.lock and user-space gems. We control Gemfile.lock pretty tightly > > >and we really only need one version across platforms given a standard > > >.rvmrc that also specifies the Ruby version we use. > > > > > >For RHEL deployment we move away Gemfile.lock altogether and bundler > > >uses system-installed RPM-based gems. I would contend that system > > >packaging details like this -- i.e. what RPMs are required on a > > >particular platform, the associated spec files, etc. -- are packaging > > >details that do *not* belong in the upstream project tree. This is the > > >standard for most upstream projects in the C world -- libvirt, for > > >example, does not maintain RPM specfiles for Fedora or RHEL in its > > >upstream tree and the standard upstream install is via ./configure; > > >make; make install. The RPM specs and build dependencies are tracked > > >separately, as are .deb packaging scripts, etc. > > > > > >I'm not saying this is the only way to handle this situation but it is > > >the standard for many upstream projects. > > > > > >Take care, > > >--Hugh > > > > > >>> > > >>>It seems to me quite clumsy. > > >>> > > >>>Petr > > >>> > > >>>On 22.08.12 16:14, Lukas Zapletal wrote: > > >>>>On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote: > > >>>>>FWIW, our Gemfile.lock is in git. We don't accept changes to it without > > >>>>>patch review, etc. etc. Seems to work reasonably well. > > >>>> > > >>>>Our first experience was not that good, but truth is, now we do use > > >>>>github.com and pull requests. On the other hand, the lock file looks > > >>>>very messy. You guys are able to track it all? > > >>>> > > >>>>The general rule could be - no changes at all except adding new > > >>>>dependencies (after discussion on the list of course :-) > > >>>> > > >>> > > >>>_______________________________________________ > > >>>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 > > -- > == 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 -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Thu Aug 23 12:38:29 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 23 Aug 2012 14:38:29 +0200 Subject: [katello-devel] developing & deploying on multiple platforms In-Reply-To: <5035CF99.9010905@redhat.com> References: <5035CF99.9010905@redhat.com> Message-ID: <20120823123829.GG3116@lzapx.brq.redhat.com> On Thu, Aug 23, 2012 at 07:37:13AM +0100, Dmitri Dolguikh wrote: > with, and we use in our deployment on said platform. I propose that > for each of deployment platforms we create a branch, and *bundle* > and potentially freeze (in bundler sense of the word) all of that > What you mean by "branch", "bundle" and "freeze". Can you elaborate? I am not following. -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Thu Aug 23 12:42:02 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 23 Aug 2012 13:42:02 +0100 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <50361A76.2070003@redhat.com> References: <50361A76.2070003@redhat.com> Message-ID: <5036251A.3050401@redhat.com> On 23/08/12 12:56 PM, Petr Chalupa wrote: > My original email raised a lot of questions, I should wrote it with > more details. I apology for that. I'll try again and elaborate. > > = Goals > > 1) To be able to implement the solution in a week or so. > 2) Not to affect deployment, keep it same way as now. > 3) When you are installing development environment on any rpm-based > system rpm-gems are used even if they are older then gems in our > gem-repo. (this is borken right now) > 4) When you are installing development environment in any non-rpm-base > system you get installed gems as close as possible to what would you > get on fedora 16. (you cannot install with bundle install only right now) > * (optionally including the security patches, lets discuss this later) > > = What was discussed, why I think it wont work > > == Branch for each platform > > * There would be little difference between the branches (only Gemfile > or Gemfile.lock). Rest of the code will be same. > * It would be too much work to maintain it. > > == Gemfile.lock per platform and environment > > * We would have to have 8 Gemfile.locks and maintain them all (4 > platforms multiplied by two environments) > * Too much work unless its automated. > * Automation would take time to setup. > > == Aeolus solution, bundler_ext [2] > > * Dependencies resolution is unaffected so 'bundle install' cannot be > used to install development dependencies, it would ignore rpm-gems and > install gems from gem-repo. > * If bundler_ext is used for setup development environment, control > over which versions are required is lost (requiring is not done by > bundler) > * It affects only how requirements are loaded [1], it's useful only > for deployment. > * (We could use it in deployment to get rid of bundler, but that is > out of this discussion's scope see Goal.2) > > == bundle install --without default > > This installs only development gems, but: > > * If some of the development gems has a production gem as dependency > (eg. ActiveSupport), the gem is reinstalled by bundler from a gem-repo > over the older rpm-gem. > * If only development gems are installed, bundler cannot be used to > require gems. It will raise LoadError because from bundler's point of > view production gems are not installed. > * It would have to be combined with bundler_ext to find production > rpm-gems, so you would loose control over which version are loaded again > * If you forget to add '--without default' when you run 'bundle > install' unwanted versions are installed. > > == vendor/cache > > Move all gems to src/vendor/cache (directly into katello/master or as > a git sub-module) and remove sources form Gemfile completely. 'bundle > install' installs gems form vendor/cache automatically if there are no > sources in Gemfile. > > * to have .gem files directly in katello/master is ugly > * submodules are real pain no need to use sub-modules > * git is not that good with binary data > gems are mostly ruby, very not a lot of binary data. > = My proposal > > == Bundler patch > > * it would be loaded in Gemfile, so every tool using bundler will get it I don't think a single Gemfile is going to solve the issue: we'll need to relax version constraints in Gemfile, and add a bunch of ruby-version specific gems... > > * it would ensure that if rpm-gem is present it's used even if there > is newer version available in gem-repo > * ensure that locally installed gems are not confused with rpm-gems You didn't explain how you are planning to differentiate between the two - system-wide bundler-/ruby-gem-installed gems and rpm-installed gems... > > * patch is optional, can be turned on/off by ENV variable or by options > * (I am also considering to add optional check that all production > gems are installed as rpms) > > Deployment is unaffected, all dependencies are satisfied by rpm-gems. > > When you run bundle install to get development environment on any > rpm-based machine, all your rpms have priority and they are used. All > missing development gems are installed from our gem-repo. I think this is the crux of the issue. Once we have a custom gem repository, the above step has very little practical value. A ruby gem is a ruby gem no matter what place in the system it's installed in. > > On non-rpm-based machine, 'bundle install' installs all gems > production and development from our gem-repo. > > == Gem Repository > > Bundler patch will work only if all development and production gems > are in the gem-repo. To get it fixed quickly 'bundle package' can be > used to get all the gems. Missing gems can be then uploaded to > katello-thirdparty (source for our gem-repo) > > = Summary > > I think that Bundler patch and updating gem-repo to contain all gems > is the only one which can be done fast and will work on any machine in > deployment and development. I tried to be thorough but if I missed > something or if you have better ideas please let me know. The issue with dependency version variability needs solving. The patch itself has little practical value, bundle install from custom repository is sufficient. The irony is that you are trying to solve the problem Bundler has successfully solved awhile ago. I'm baffled as to why we continue to insist on solving the problems the "katello" way. -d > > Petr > > [1] > https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 > > [2] https://github.com/aeolus-incubator/bundler_ext > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From dmitri at redhat.com Thu Aug 23 12:43:36 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 23 Aug 2012 13:43:36 +0100 Subject: [katello-devel] developing & deploying on multiple platforms In-Reply-To: <20120823123829.GG3116@lzapx.brq.redhat.com> References: <5035CF99.9010905@redhat.com> <20120823123829.GG3116@lzapx.brq.redhat.com> Message-ID: <50362578.7010704@redhat.com> On 23/08/12 01:38 PM, Lukas Zapletal wrote: > On Thu, Aug 23, 2012 at 07:37:13AM +0100, Dmitri Dolguikh wrote: >> with, and we use in our deployment on said platform. I propose that >> for each of deployment platforms we create a branch, and *bundle* >> and potentially freeze (in bundler sense of the word) all of that >> > What you mean by "branch", "bundle" and "freeze". Can you elaborate? I > am not following. "branch" in git meaning of the word (probably just a tag). "bundle" and "freeze" - bundler terminology. -d > From vondruch at redhat.com Thu Aug 23 12:59:06 2012 From: vondruch at redhat.com (=?UTF-8?B?VsOtdCBPbmRydWNo?=) Date: Thu, 23 Aug 2012 14:59:06 +0200 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120823123450.GF3116@lzapx.brq.redhat.com> References: <50349AB6.8060505@redhat.com> <50349E2E.8070101@redhat.com> <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> <20120822141416.GN3044@lzapx.brq.redhat.com> <5034EC7D.1030000@redhat.com> <5034EE8C.5080306@redhat.com> <20120822144657.GM15992@redhat.com> <5034F47A.8010508@redhat.com> <20120822152625.GN15992@redhat.com> <20120823123450.GF3116@lzapx.brq.redhat.com> Message-ID: <5036291A.90909@redhat.com> https://fedorahosted.org/SoftwareCollections/ Dne 23.8.2012 14:34, Lukas Zapletal napsal(a): > What's DSC? > > LZ > > On Wed, Aug 22, 2012 at 11:26:26AM -0400, Hugh Brock wrote: >> On Wed, Aug 22, 2012 at 05:02:18PM +0200, Petr Chalupa wrote: >>> For RHEL deployment we move away Gemfile.lock altogether, this will >>> work. But you do not have a way how to install rest of the >>> development dependencies on RHEL, keep the older rpm-gems and >>> install corecct versions of development gems. >> Hmm... well, OK, I think we need to get precise about exactly what the >> goal is here. >> >> Should you want to develop on RHEL -- fix bugs, do new work, whatever -- >> I believe the best way to do that going forward is going to be via a >> DSC. In other words, forget the native RHEL stack altogether since it >> will be of no help. We don't currently have a blessed DSC for Cloudforms >> on RHEL but I believe we need to get there ASAP. Given a suitable RHEL >> production DSC and a parallel development DSC, you can develop nicely on >> an RPM-based system without having to worry so much about getting >> packages into RHEL proper. >> >> Should you want to develop on Fedora or another non-production platform, >> use gems, and ideally the packaged versions of your dependencies for >> that platform. I would like to have a DSC that would work on fedora as >> well, since I don't believe the native Fedora ruby platform offers much >> more value than the antiquated one in RHEL. >> >> Happy to hear what's wrong with this, but just keep in mind that we want >> to keep packaging overhead to an absolute minimum. >> >> --Hugh >> >>> On 22.08.12 16:46, Hugh Brock wrote: >>>> On Wed, Aug 22, 2012 at 03:37:00PM +0100, Dmitri Dolguikh wrote: >>>>> On 22/08/12 03:28 PM, Petr Chalupa wrote: >>>>>> We already discussed solution with Gemfile.lock. There are issues. >>>>>> >>>>>> - You would have to have Gemfile.lock for f16, f17, el62, el63 >>>>>> - You would habe to have Gemfile.lock for production and development >>>>>> - You will have update it every time when some version of gem or >>>>>> rpm change in some of f16, f17, el62, el63 >>>>> Hmmm. What if we bundled dependencies when we are tagging for a >>>>> specific platform (and stripped them when packaging into rpm)? >>>>> Troubleshooting would be quite simple then - we could even look at >>>>> rhel issues on fedora... >>>>> >>>>> -d >>>> Could work, definitely worth looking into. >>>> >>>> Our solution thus far has been: Upstream deployment with gem-only uses >>>> Gemfile.lock and user-space gems. We control Gemfile.lock pretty tightly >>>> and we really only need one version across platforms given a standard >>>> .rvmrc that also specifies the Ruby version we use. >>>> >>>> For RHEL deployment we move away Gemfile.lock altogether and bundler >>>> uses system-installed RPM-based gems. I would contend that system >>>> packaging details like this -- i.e. what RPMs are required on a >>>> particular platform, the associated spec files, etc. -- are packaging >>>> details that do *not* belong in the upstream project tree. This is the >>>> standard for most upstream projects in the C world -- libvirt, for >>>> example, does not maintain RPM specfiles for Fedora or RHEL in its >>>> upstream tree and the standard upstream install is via ./configure; >>>> make; make install. The RPM specs and build dependencies are tracked >>>> separately, as are .deb packaging scripts, etc. >>>> >>>> I'm not saying this is the only way to handle this situation but it is >>>> the standard for many upstream projects. >>>> >>>> Take care, >>>> --Hugh >>>> >>>>>> It seems to me quite clumsy. >>>>>> >>>>>> Petr >>>>>> >>>>>> On 22.08.12 16:14, Lukas Zapletal wrote: >>>>>>> On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote: >>>>>>>> FWIW, our Gemfile.lock is in git. We don't accept changes to it without >>>>>>>> patch review, etc. etc. Seems to work reasonably well. >>>>>>> Our first experience was not that good, but truth is, now we do use >>>>>>> github.com and pull requests. On the other hand, the lock file looks >>>>>>> very messy. You guys are able to track it all? >>>>>>> >>>>>>> The general rule could be - no changes at all except adding new >>>>>>> dependencies (after discussion on the list of course :-) >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> -- >> == 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 hbrock at redhat.com Thu Aug 23 13:07:00 2012 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 23 Aug 2012 09:07:00 -0400 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <5036291A.90909@redhat.com> References: <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> <20120822141416.GN3044@lzapx.brq.redhat.com> <5034EC7D.1030000@redhat.com> <5034EE8C.5080306@redhat.com> <20120822144657.GM15992@redhat.com> <5034F47A.8010508@redhat.com> <20120822152625.GN15992@redhat.com> <20120823123450.GF3116@lzapx.brq.redhat.com> <5036291A.90909@redhat.com> Message-ID: <20120823130700.GT15992@redhat.com> On Thu, Aug 23, 2012 at 02:59:06PM +0200, V?t Ondruch wrote: > https://fedorahosted.org/SoftwareCollections/ > > > > Dne 23.8.2012 14:34, Lukas Zapletal napsal(a): > >What's DSC? > > Yes. And I've just realized that Openshift have an up-to-date DSC that includes Rails 3.2, Passenger (I think), Ruby 1.9.3, etc. I'd like to see Aeolus and Katello move to that as soon as possible after 1.1 goes out. --H > > > >On Wed, Aug 22, 2012 at 11:26:26AM -0400, Hugh Brock wrote: > >>On Wed, Aug 22, 2012 at 05:02:18PM +0200, Petr Chalupa wrote: > >>>For RHEL deployment we move away Gemfile.lock altogether, this will > >>>work. But you do not have a way how to install rest of the > >>>development dependencies on RHEL, keep the older rpm-gems and > >>>install corecct versions of development gems. > >>Hmm... well, OK, I think we need to get precise about exactly what the > >>goal is here. > >> > >>Should you want to develop on RHEL -- fix bugs, do new work, whatever -- > >>I believe the best way to do that going forward is going to be via a > >>DSC. In other words, forget the native RHEL stack altogether since it > >>will be of no help. We don't currently have a blessed DSC for Cloudforms > >>on RHEL but I believe we need to get there ASAP. Given a suitable RHEL > >>production DSC and a parallel development DSC, you can develop nicely on > >>an RPM-based system without having to worry so much about getting > >>packages into RHEL proper. > >> > >>Should you want to develop on Fedora or another non-production platform, > >>use gems, and ideally the packaged versions of your dependencies for > >>that platform. I would like to have a DSC that would work on fedora as > >>well, since I don't believe the native Fedora ruby platform offers much > >>more value than the antiquated one in RHEL. > >> > >>Happy to hear what's wrong with this, but just keep in mind that we want > >>to keep packaging overhead to an absolute minimum. > >> > >>--Hugh > >> > >>>On 22.08.12 16:46, Hugh Brock wrote: > >>>>On Wed, Aug 22, 2012 at 03:37:00PM +0100, Dmitri Dolguikh wrote: > >>>>>On 22/08/12 03:28 PM, Petr Chalupa wrote: > >>>>>>We already discussed solution with Gemfile.lock. There are issues. > >>>>>> > >>>>>>- You would have to have Gemfile.lock for f16, f17, el62, el63 > >>>>>>- You would habe to have Gemfile.lock for production and development > >>>>>>- You will have update it every time when some version of gem or > >>>>>>rpm change in some of f16, f17, el62, el63 > >>>>>Hmmm. What if we bundled dependencies when we are tagging for a > >>>>>specific platform (and stripped them when packaging into rpm)? > >>>>>Troubleshooting would be quite simple then - we could even look at > >>>>>rhel issues on fedora... > >>>>> > >>>>>-d > >>>>Could work, definitely worth looking into. > >>>> > >>>>Our solution thus far has been: Upstream deployment with gem-only uses > >>>>Gemfile.lock and user-space gems. We control Gemfile.lock pretty tightly > >>>>and we really only need one version across platforms given a standard > >>>>.rvmrc that also specifies the Ruby version we use. > >>>> > >>>>For RHEL deployment we move away Gemfile.lock altogether and bundler > >>>>uses system-installed RPM-based gems. I would contend that system > >>>>packaging details like this -- i.e. what RPMs are required on a > >>>>particular platform, the associated spec files, etc. -- are packaging > >>>>details that do *not* belong in the upstream project tree. This is the > >>>>standard for most upstream projects in the C world -- libvirt, for > >>>>example, does not maintain RPM specfiles for Fedora or RHEL in its > >>>>upstream tree and the standard upstream install is via ./configure; > >>>>make; make install. The RPM specs and build dependencies are tracked > >>>>separately, as are .deb packaging scripts, etc. > >>>> > >>>>I'm not saying this is the only way to handle this situation but it is > >>>>the standard for many upstream projects. > >>>> > >>>>Take care, > >>>>--Hugh > >>>> > >>>>>>It seems to me quite clumsy. > >>>>>> > >>>>>>Petr > >>>>>> > >>>>>>On 22.08.12 16:14, Lukas Zapletal wrote: > >>>>>>>On Wed, Aug 22, 2012 at 09:49:06AM -0400, Hugh Brock wrote: > >>>>>>>>FWIW, our Gemfile.lock is in git. We don't accept changes to it without > >>>>>>>>patch review, etc. etc. Seems to work reasonably well. > >>>>>>>Our first experience was not that good, but truth is, now we do use > >>>>>>>github.com and pull requests. On the other hand, the lock file looks > >>>>>>>very messy. You guys are able to track it all? > >>>>>>> > >>>>>>>The general rule could be - no changes at all except adding new > >>>>>>>dependencies (after discussion on the list of course :-) > >>>>>>> > >>>>>>_______________________________________________ > >>>>>>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 > >>-- > >>== 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 -- == 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 Aug 23 13:14:31 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 23 Aug 2012 09:14:31 -0400 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <20120823130700.GT15992@redhat.com> References: <20120822125533.GF3044@lzapx.brq.redhat.com> <20120822134905.GJ15992@redhat.com> <20120822141416.GN3044@lzapx.brq.redhat.com> <5034EC7D.1030000@redhat.com> <5034EE8C.5080306@redhat.com> <20120822144657.GM15992@redhat.com> <5034F47A.8010508@redhat.com> <20120822152625.GN15992@redhat.com> <20120823123450.GF3116@lzapx.brq.redhat.com> <5036291A.90909@redhat.com> <20120823130700.GT15992@redhat.com> Message-ID: <50362CB7.8030908@redhat.com> On 08/23/2012 09:07 AM, Hugh Brock wrote: > On Thu, Aug 23, 2012 at 02:59:06PM +0200, V?t Ondruch wrote: >> https://fedorahosted.org/SoftwareCollections/ >> >> >> >> Dne 23.8.2012 14:34, Lukas Zapletal napsal(a): >>> What's DSC? >>> > > Yes. And I've just realized that Openshift have an up-to-date DSC that > includes Rails 3.2, Passenger (I think), Ruby 1.9.3, etc. I'd like to see Aeolus and > Katello move to that as soon as possible after 1.1 goes out. Is it a real DSC? I thought our use of DSC's would not work with passenger? -- bk From hbrock at redhat.com Thu Aug 23 13:25:57 2012 From: hbrock at redhat.com (Hugh Brock) Date: Thu, 23 Aug 2012 09:25:57 -0400 Subject: [katello-devel] Bundler vs rpm-gems In-Reply-To: <50362CB7.8030908@redhat.com> References: <20120822141416.GN3044@lzapx.brq.redhat.com> <5034EC7D.1030000@redhat.com> <5034EE8C.5080306@redhat.com> <20120822144657.GM15992@redhat.com> <5034F47A.8010508@redhat.com> <20120822152625.GN15992@redhat.com> <20120823123450.GF3116@lzapx.brq.redhat.com> <5036291A.90909@redhat.com> <20120823130700.GT15992@redhat.com> <50362CB7.8030908@redhat.com> Message-ID: <20120823132557.GV15992@redhat.com> On Thu, Aug 23, 2012 at 09:14:31AM -0400, Bryan Kearney wrote: > On 08/23/2012 09:07 AM, Hugh Brock wrote: > >On Thu, Aug 23, 2012 at 02:59:06PM +0200, V?t Ondruch wrote: > >>https://fedorahosted.org/SoftwareCollections/ > >> > >> > >> > >>Dne 23.8.2012 14:34, Lukas Zapletal napsal(a): > >>>What's DSC? > >>> > > > >Yes. And I've just realized that Openshift have an up-to-date DSC that > >includes Rails 3.2, Passenger (I think), Ruby 1.9.3, etc. I'd like to see Aeolus and > >Katello move to that as soon as possible after 1.1 goes out. > > > Is it a real DSC? I thought our use of DSC's would not work with passenger? > -- bk cc-ing Mr. Hicks to see... Mr. Hicks, your Openshift stack, is it real? Does it include/work with passenger? --H -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From bkearney at redhat.com Thu Aug 23 13:51:07 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 23 Aug 2012 09:51:07 -0400 Subject: [katello-devel] developing & deploying on multiple platforms In-Reply-To: <50362578.7010704@redhat.com> References: <5035CF99.9010905@redhat.com> <20120823123829.GG3116@lzapx.brq.redhat.com> <50362578.7010704@redhat.com> Message-ID: <5036354B.9040503@redhat.com> On 08/23/2012 08:43 AM, Dmitri Dolguikh wrote: > On 23/08/12 01:38 PM, Lukas Zapletal wrote: >> On Thu, Aug 23, 2012 at 07:37:13AM +0100, Dmitri Dolguikh wrote: >>> with, and we use in our deployment on said platform. I propose that >>> for each of deployment platforms we create a branch, and *bundle* >>> and potentially freeze (in bundler sense of the word) all of that >>> >> What you mean by "branch", "bundle" and "freeze". Can you elaborate? I >> am not following. > "branch" in git meaning of the word (probably just a tag). "bundle" and > "freeze" - bundler terminology. Is the only difference really the Gemfile.lock? If so, then can we carry several of these files and then have setup/spec file put the correct one in place? -- bk From dmitri at redhat.com Thu Aug 23 13:58:38 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 23 Aug 2012 14:58:38 +0100 Subject: [katello-devel] developing & deploying on multiple platforms In-Reply-To: <5036354B.9040503@redhat.com> References: <5035CF99.9010905@redhat.com> <20120823123829.GG3116@lzapx.brq.redhat.com> <50362578.7010704@redhat.com> <5036354B.9040503@redhat.com> Message-ID: <5036370E.70108@redhat.com> On 23/08/12 02:51 PM, Bryan Kearney wrote: > On 08/23/2012 08:43 AM, Dmitri Dolguikh wrote: >> On 23/08/12 01:38 PM, Lukas Zapletal wrote: >>> On Thu, Aug 23, 2012 at 07:37:13AM +0100, Dmitri Dolguikh wrote: >>>> with, and we use in our deployment on said platform. I propose that >>>> for each of deployment platforms we create a branch, and *bundle* >>>> and potentially freeze (in bundler sense of the word) all of that >>>> >>> What you mean by "branch", "bundle" and "freeze". Can you elaborate? I >>> am not following. >> "branch" in git meaning of the word (probably just a tag). "bundle" and >> "freeze" - bundler terminology. > > Is the only difference really the Gemfile.lock? If so, then can we > carry several of these files and then have setup/spec file put the > correct one in place? That, and actual gem files. There's a good chance that gem files of the same version will be different between rubygems.com and rpm-sourced ones (bug- and security-fixes get back-ported). We do need to somehow a) associate a particular gem version and b) have actual gem in order to replicate a given release version of Katello. -d > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Thu Aug 23 14:02:30 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 23 Aug 2012 10:02:30 -0400 Subject: [katello-devel] developing & deploying on multiple platforms In-Reply-To: <5036370E.70108@redhat.com> References: <5035CF99.9010905@redhat.com> <20120823123829.GG3116@lzapx.brq.redhat.com> <50362578.7010704@redhat.com> <5036354B.9040503@redhat.com> <5036370E.70108@redhat.com> Message-ID: <503637F6.4050805@redhat.com> On 08/23/2012 09:58 AM, Dmitri Dolguikh wrote: > On 23/08/12 02:51 PM, Bryan Kearney wrote: >> On 08/23/2012 08:43 AM, Dmitri Dolguikh wrote: >>> On 23/08/12 01:38 PM, Lukas Zapletal wrote: >>>> On Thu, Aug 23, 2012 at 07:37:13AM +0100, Dmitri Dolguikh wrote: >>>>> with, and we use in our deployment on said platform. I propose that >>>>> for each of deployment platforms we create a branch, and *bundle* >>>>> and potentially freeze (in bundler sense of the word) all of that >>>>> >>>> What you mean by "branch", "bundle" and "freeze". Can you elaborate? I >>>> am not following. >>> "branch" in git meaning of the word (probably just a tag). "bundle" and >>> "freeze" - bundler terminology. >> >> Is the only difference really the Gemfile.lock? If so, then can we >> carry several of these files and then have setup/spec file put the >> correct one in place? > That, and actual gem files. There's a good chance that gem files of the > same version will be different between rubygems.com and rpm-sourced ones > (bug- and security-fixes get back-ported). We do need to somehow a) > associate a particular gem version and b) have actual gem in order to > replicate a given release version of Katello. > But the gem files are not checked into our repos? Or, are you suggesting we still carry our own gen repos? -- bk From mbacovsk at redhat.com Thu Aug 23 14:01:38 2012 From: mbacovsk at redhat.com (Martin Bacovsky) Date: Thu, 23 Aug 2012 16:01:38 +0200 Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <1109139362.12559597.1345644633125.JavaMail.root@redhat.com> References: <1109139362.12559597.1345644633125.JavaMail.root@redhat.com> Message-ID: <503637C2.9030304@redhat.com> On 08/22/2012 04:10 PM, Eric Helms wrote: > Excellent - this is exactly what I was looking for and missed that there was a separate set of API bindings in a gem due to no requires at the top of the file in lib/resources. > > Looking closer at the lib/resources/foreman_model.rb this mostly seems like a generic layer for interacting with a set of Ruby API bindings and could be re-purposed to used by any of the glue layers. Keeping in mind I am pondering this with regards to our migration to Pulp V2 and the re-factoring and work that will be associated with it. How much in this file is Foreman specific? > > -Eric You are right, the ForemanModel is pretty generic and could be used for any other resources with API bindings. Only the resource method is Foreman specific and that would be easy to fix. Im not sure however if it is applicable for Candlepin and Pulp as they don't use API bindings but just are proxying the requests (someone correct me if I'm wrong). -Martin > > ----- Original Message ----- > From: "Martin Bacovsky" > To: katello-devel at redhat.com > Sent: Wednesday, August 22, 2012 4:23:10 AM > Subject: Re: [katello-devel] Katello-Foreman Integration API Layer Question > > On 08/22/2012 09:12 AM, Ivan Ne?as wrote: >> On Tue 21 Aug 2012 05:31:43 PM CEST, Eric Helms wrote: >>> A question after seeing the current progress of the Foreman >>> integration work around the API layer. This is inspired by some >>> thoughts we've had around the Pulp v2 migrations. >>> >>> Has any thought been given to generating a separate >>> library/gem/project for the API part? Since this would be a re-usable >>> component by potentially other communities and present a nice, clean >>> set of ruby bindings for the Foreman APIs that we could consume (as >>> well as others). >> Is this the answer? >> >> https://github.com/mbacovsky/foreman_api >> >> -- Ivan > The foreman_api is generated from API documentation using the Apipie > tool [1]. The tool's other nice feature is that you can generate simple > CLI client, but as the new API is still far from complete neither we nor > the foreman community provide one. > > The foreman_api is available in git repo [3] (most fresh version is > usually on the link Ivan provided), as a gem on rubygems.org and also in > our katello-thirdparty repo as a rpm. It should be available soon as a > rpm and deb for the Foreman community by their own means. > > Here is short wiki [2] on how we use the bindings in katello. If you > find anything you need to add there, let me know. > > Martin > > [1] https://github.com/Pajk/apipie-rails > [2] https://fedorahosted.org/katello/wiki/ForemanIntegrationAPI > [3] https://github.com/theforeman/foreman_api > > >>> - Eric >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mbacovsk at redhat.com Thu Aug 23 14:50:18 2012 From: mbacovsk at redhat.com (Martin Bacovsky) Date: Thu, 23 Aug 2012 16:50:18 +0200 Subject: [katello-devel] Foreman integration model question In-Reply-To: <503511EC.1060701@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> <503511EC.1060701@redhat.com> Message-ID: <5036432A.7060701@redhat.com> On 08/22/2012 07:07 PM, Justin Sherrill wrote: > On 08/22/2012 08:26 AM, Petr Chalupa wrote: >> Lukas is right, our motivation was to break the code into smaller >> pieces (I am big fan of SOLID and 'single responsibility principle' >> in particular). If you write code this way, you can then move things >> around very quickly so you can develop features and fix bugs faster. >> No to mention it can be testes more easily. >> >> app/models/user.rb (User) is representation of katello user which >> mixes (if foreman is installed) foreman orchestration >> app/models/glue/forema/user.rb. Orchestration is working with foreman >> through children of ForemanModel which are representation of remote >> resources app/models/foreman/user.rb (Foreman::User). Foreman::User >> is using foreman-api bindings which are defined as singletons in >> lib/resources/foreman.rb. >> >> So there are 4 layers: >> - katello model >> - foreman-katello orchestration >> - foreman model (remote resource) >> - foreman bindings (gem foreman-api) >> >> I also for splitting up big parts. > I do like this auto generated api method better (aside from there > being two distinct User models). To say a downside of the current > model is a giant single file pulp.rb is kinda moot, as that was just > how it was organized, we can organize it differently quite easily. > What we are doing here with foreman is wayyyy more than just > organizing it differently, its a fairly completely different way of > orchestrating things, bypassing our lazy_accessor magic. > > For example, lets say we do the same with environment, where there is > a katello environment and a foreman environment. And lets say there > is some special piece of information only stored in foreman (this is > not a far-fetched scenario). > > With our current orchestration you would do something like: > > a = KTEnvironment.find(3) > print a.remote_attribute > a.remote_attribute = "foo" > a.save! > > whereas the way i see it now, we'd have to do: > > a = KTEnvironment.find(3) > a.foreman_user.remote_attribute = "foo" > a.save! > > I don't really like this better as you'd have to remember which > backend engine a particular attribute is. Today you don't. I don't > really expect any of these arguments to change the way we are doing > anything, its just annoying to change our entire way of working with a > backend engine without any discussion :) > > We need to be aware that doing it this way is creating a 2nd way with > working with fully (or partially) remote objects and that needs to be > clear and apparent. It also needs to be justified :) > > -Justin > Good point with the attributes. On the other hand the approach Peter used for Foreman model feels to me a way better. From my experience the lazy-stuff usually translates as "easy at writing busy at maintaining" ;). Would it be solution to keep the current implementation and add a way to access the foreman specific attributes form the katello model? Perhaps by explicitly including the attributes handling to katello model from the glue layer? Martin >> >> Petr >> >> On 22.08.12 10:19, Lukas Zapletal wrote: >>> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: >>>> Taking user for example we would have: >>>> >>>> user.rb >>>> glue/pulp/user.rb >>> >>> But you are missing one piece of the puzzle: >>> >>> lib/resources/pulp.rb (class User) >>> >>> And that is the piece which you can find in foreman/user.rb. >>> >>>> What I see with foreman is: >>>> >>>> user.rb >>>> glue/foreman/user.rb >>>> foreman/user.rb >>> >>> So instead having all the resources in a single class >>> (lib/resources/foreman.rb), we are going to have (or better - generate) >>> all resource (read also as "dumb") classes. Each in separate file. >>> >>>> Where foreman/user is a second class that can be instantiated and >>>> used on its own, while glue/foreman/user.rb is simply the >>>> orchestration to create that object. I see the use of >>>> Resources::ForemanModel, but in this user instance the foreman user >>>> could be manipulated completely apart from the katello user (which >>>> is bad IMHO). This also is completely different from our existing >>>> orchestration methods. >>> >>> Yes, it is different. I like this approach more. Creating a one >>> instance >>> per request is nothing, while the code is definitely better than eight >>> hundred lines long pulp.rb with all the resources there as "class" >>> methods. >>> >>> I think this is the correct approach and we may discuss splitting those >>> big resource files in future into smaller pieces for other backend >>> engines too. If we write a similar generator, we wont longer need to >>> write them manually (and we will be able to track API changes too). >>> >>> I was not writing the code, but I believe those instances are treated >>> like singletons, so you do not need to create instances by yourself: >>> >>> https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb >>> >>> >>> Guys please elaborate what the intentions are. >>> >> >> _______________________________________________ >> 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 Thu Aug 23 15:27:35 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 23 Aug 2012 16:27:35 +0100 Subject: [katello-devel] Foreman integration model question In-Reply-To: <503511EC.1060701@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> <503511EC.1060701@redhat.com> Message-ID: <50364BE7.90504@redhat.com> On 22/08/12 06:07 PM, Justin Sherrill wrote: > On 08/22/2012 08:26 AM, Petr Chalupa wrote: >> Lukas is right, our motivation was to break the code into smaller >> pieces (I am big fan of SOLID and 'single responsibility principle' >> in particular). If you write code this way, you can then move things >> around very quickly so you can develop features and fix bugs faster. >> No to mention it can be testes more easily. >> >> app/models/user.rb (User) is representation of katello user which >> mixes (if foreman is installed) foreman orchestration >> app/models/glue/forema/user.rb. Orchestration is working with foreman >> through children of ForemanModel which are representation of remote >> resources app/models/foreman/user.rb (Foreman::User). Foreman::User >> is using foreman-api bindings which are defined as singletons in >> lib/resources/foreman.rb. >> >> So there are 4 layers: >> - katello model >> - foreman-katello orchestration >> - foreman model (remote resource) >> - foreman bindings (gem foreman-api) >> >> I also for splitting up big parts. > I do like this auto generated api method better (aside from there > being two distinct User models). To say a downside of the current > model is a giant single file pulp.rb is kinda moot, as that was just > how it was organized, we can organize it differently quite easily. > What we are doing here with foreman is wayyyy more than just > organizing it differently, its a fairly completely different way of > orchestrating things, bypassing our lazy_accessor magic. I will insist on using the orchestration layer for all access outside of local model. Controller code shouldn't be aware of where a given model attribute is, otherwise you are leaking orchestration outside of model. That aside, but why do we need to *generate* code in *ruby*? Does that mean we have a lot of dumb code with very little logic in it? We can and should do better. -d > > For example, lets say we do the same with environment, where there is > a katello environment and a foreman environment. And lets say there > is some special piece of information only stored in foreman (this is > not a far-fetched scenario). > > With our current orchestration you would do something like: > > a = KTEnvironment.find(3) > print a.remote_attribute > a.remote_attribute = "foo" > a.save! > > whereas the way i see it now, we'd have to do: > > a = KTEnvironment.find(3) > a.foreman_user.remote_attribute = "foo" > a.save! > > I don't really like this better as you'd have to remember which > backend engine a particular attribute is. Today you don't. I don't > really expect any of these arguments to change the way we are doing > anything, its just annoying to change our entire way of working with a > backend engine without any discussion :) > > We need to be aware that doing it this way is creating a 2nd way with > working with fully (or partially) remote objects and that needs to be > clear and apparent. It also needs to be justified :) > > -Justin > >> >> Petr >> >> On 22.08.12 10:19, Lukas Zapletal wrote: >>> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: >>>> Taking user for example we would have: >>>> >>>> user.rb >>>> glue/pulp/user.rb >>> >>> But you are missing one piece of the puzzle: >>> >>> lib/resources/pulp.rb (class User) >>> >>> And that is the piece which you can find in foreman/user.rb. >>> >>>> What I see with foreman is: >>>> >>>> user.rb >>>> glue/foreman/user.rb >>>> foreman/user.rb >>> >>> So instead having all the resources in a single class >>> (lib/resources/foreman.rb), we are going to have (or better - generate) >>> all resource (read also as "dumb") classes. Each in separate file. >>> >>>> Where foreman/user is a second class that can be instantiated and >>>> used on its own, while glue/foreman/user.rb is simply the >>>> orchestration to create that object. I see the use of >>>> Resources::ForemanModel, but in this user instance the foreman user >>>> could be manipulated completely apart from the katello user (which >>>> is bad IMHO). This also is completely different from our existing >>>> orchestration methods. >>> >>> Yes, it is different. I like this approach more. Creating a one >>> instance >>> per request is nothing, while the code is definitely better than eight >>> hundred lines long pulp.rb with all the resources there as "class" >>> methods. >>> >>> I think this is the correct approach and we may discuss splitting those >>> big resource files in future into smaller pieces for other backend >>> engines too. If we write a similar generator, we wont longer need to >>> write them manually (and we will be able to track API changes too). >>> >>> I was not writing the code, but I believe those instances are treated >>> like singletons, so you do not need to create instances by yourself: >>> >>> https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb >>> >>> >>> Guys please elaborate what the intentions are. >>> >> >> _______________________________________________ >> 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 Thu Aug 23 16:38:04 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 23 Aug 2012 12:38:04 -0400 Subject: [katello-devel] Foreman integration model question In-Reply-To: <5034CFE5.1080702@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> Message-ID: <50365C6C.7030204@redhat.com> On 08/22/2012 08:26 AM, Petr Chalupa wrote: > Lukas is right, our motivation was to break the code into smaller pieces > (I am big fan of SOLID and 'single responsibility principle' in > particular). If you write code this way, you can then move things around > very quickly so you can develop features and fix bugs faster. No to > mention it can be testes more easily. > > app/models/user.rb (User) is representation of katello user which mixes > (if foreman is installed) foreman orchestration > app/models/glue/forema/user.rb. Orchestration is working with foreman > through children of ForemanModel which are representation of remote > resources app/models/foreman/user.rb (Foreman::User). Foreman::User is > using foreman-api bindings which are defined as singletons in > lib/resources/foreman.rb. > > So there are 4 layers: > - katello model > - foreman-katello orchestration > - foreman model (remote resource) > - foreman bindings (gem foreman-api) > > I also for splitting up big parts. > So, you put code in models/foreman because there is no data in katello? This is similar ot candlepin/pools. I tend to agree with justin in that it would be nice to have symmitry in whre the code is placed across all the backend engines. -- kb From jomara at redhat.com Thu Aug 23 21:33:07 2012 From: jomara at redhat.com (Jordan OMara) Date: Thu, 23 Aug 2012 17:33:07 -0400 Subject: [katello-devel] pulp upgrade scripts for headpin mode Message-ID: <20120823213307.GG49540@redhat.com> If you run katello-upgrade with a headpin install, it still processes the pulp upgrade script. It looks like it has to have an apply: katello line in it to get filtered out appropriately. However, the pulp upgrade script is basically empty: # # TODO # # exit 0 Does it somehow do anything automatically or is it really just a no-op? Is this script basically a placeholder for upgrading pulp in the future? Should I add apply: katello to the placeholder? Thanks! -- 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 dmitri at redhat.com Fri Aug 24 10:01:16 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 24 Aug 2012 11:01:16 +0100 Subject: [katello-devel] Foreman-api Message-ID: <503750EC.7020605@redhat.com> Hey guys, I'm about to add api bindings for environments to Foreman API, but was wondering about the goals of that [sub]-project. In particular, why did we choose to create our own code instead of using Rails ActiveResource (did anyone looked if there are still issues with Oauth when using ActiveResource)? Another one is why do we perform client side validation of parameters? -d From dmitri at redhat.com Fri Aug 24 10:56:26 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 24 Aug 2012 11:56:26 +0100 Subject: [katello-devel] Foreman-api In-Reply-To: <503750EC.7020605@redhat.com> References: <503750EC.7020605@redhat.com> Message-ID: <50375DDA.7040403@redhat.com> On 24/08/12 11:01 AM, Dmitri Dolguikh wrote: > Hey guys, > > I'm about to add api bindings for environments to Foreman API, but was > wondering about the goals of that [sub]-project. In particular, why > did we choose to create our own code instead of using Rails > ActiveResource (did anyone looked if there are still issues with Oauth > when using ActiveResource)? Another one is why do we perform client > side validation of parameters? > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel nm, the discussion is going to be moved to foreman-related mailing list. -d From lzap at redhat.com Fri Aug 24 12:56:48 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 24 Aug 2012 14:56:48 +0200 Subject: [katello-devel] Consumer and goferd In-Reply-To: <5036220B.2050004@redhat.com> References: <20120822124255.GD3044@lzapx.brq.redhat.com> <20120823120537.GC3116@lzapx.brq.redhat.com> <5036220B.2050004@redhat.com> Message-ID: <20120824125648.GH3980@lzapx.brq.redhat.com> On Thu, Aug 23, 2012 at 02:28:59PM +0200, Miroslav Suchy wrote: > On 08/23/2012 02:05 PM, Lukas Zapletal wrote: > >Ok, here is the example bootstrap session: > > > >https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient#Examplebootstrapsession > > > >This is how users should bootstrap their machines NOW with Katello. > > > > > chkconfig ntpd on > What about service start? Will add, thanks. > >#cat > /etc/yum.repos.d/katello-client.repo <<'EOF' > We should remove this ASAP. Because it will not work on i386. But it > Well there is already a note: "We currently do not build client tools for non-x86-64 systems, but feel free to replace $basearch with 'x86_64' string, because all packages there are currently platform indepentent." And it will not break i386 machines. Its a noarch package there. > means to resolve this one first: > https://bugzilla.redhat.com/show_bug.cgi?id=845643 > Somebody who is fedora packager, please pick this up. > Still on my TODO stack :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Aug 24 13:03:23 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 24 Aug 2012 15:03:23 +0200 Subject: [katello-devel] Consumer and goferd In-Reply-To: <50361E5A.5070805@redhat.com> References: <20120822124255.GD3044@lzapx.brq.redhat.com> <20120823120537.GC3116@lzapx.brq.redhat.com> <50361E5A.5070805@redhat.com> Message-ID: <20120824130323.GI3980@lzapx.brq.redhat.com> On Thu, Aug 23, 2012 at 08:13:14AM -0400, Bryan Kearney wrote: > On 08/23/2012 08:05 AM, Lukas Zapletal wrote: > >Ok, here is the example bootstrap session: > > > >https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient#Examplebootstrapsession > > > >This is how users should bootstrap their machines NOW with Katello. > > > >LZ > > If the agent fails nicely when the machine is not registered, why > not just chkconfig it on by default? seems wierd to have to deal > with it out of band. > It's not a good practice to do that. And what we get by removing two lines from the bootstrap script putting them to the RPM when the script is (as you see) quite big. I see no added value. On top of that, we do restart goferd, but it must be running. It is not by default (for the same reasons). I would recommend to leave the decision on the administrator. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Aug 24 13:04:17 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 24 Aug 2012 15:04:17 +0200 Subject: [katello-devel] Consumer and goferd In-Reply-To: <20120824125648.GH3980@lzapx.brq.redhat.com> References: <20120822124255.GD3044@lzapx.brq.redhat.com> <20120823120537.GC3116@lzapx.brq.redhat.com> <5036220B.2050004@redhat.com> <20120824125648.GH3980@lzapx.brq.redhat.com> Message-ID: <20120824130416.GJ3980@lzapx.brq.redhat.com> On Fri, Aug 24, 2012 at 02:56:48PM +0200, Lukas Zapletal wrote: > On Thu, Aug 23, 2012 at 02:28:59PM +0200, Miroslav Suchy wrote: > > On 08/23/2012 02:05 PM, Lukas Zapletal wrote: > > >Ok, here is the example bootstrap session: > > > > > >https://fedorahosted.org/katello/wiki/GuideSystemRegistrationClient#Examplebootstrapsession > > > > > >This is how users should bootstrap their machines NOW with Katello. > > > > > > > > chkconfig ntpd on > > What about service start? > > Will add, thanks. > > > >#cat > /etc/yum.repos.d/katello-client.repo <<'EOF' > > We should remove this ASAP. Because it will not work on i386. But it > > > > Well there is already a note: > > "We currently do not build client tools for non-x86-64 systems, but feel > free to replace $basearch with 'x86_64' string, because all packages > there are currently platform indepentent." > > And it will not break i386 machines. Its a noarch package there. Ah there is $basearch I see. Well, it should definitely be in the "noarch" on the server. I will expedite the review :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Aug 24 14:11:32 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 24 Aug 2012 16:11:32 +0200 Subject: [katello-devel] Foreman integration model question In-Reply-To: <5036432A.7060701@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> <503511EC.1060701@redhat.com> <5036432A.7060701@redhat.com> Message-ID: <20120824141132.GK3980@lzapx.brq.redhat.com> On Thu, Aug 23, 2012 at 04:50:18PM +0200, Martin Bacovsky wrote: > Would it be solution to keep the current implementation and add a > way to access the foreman specific attributes form the katello > model? Perhaps by explicitly including the attributes handling to > katello model from the glue layer? Whatever the solution is, please plan some design wiki and schedule a meeting so we can all discuss it. I don't like having architectural changes merged in master without proper discussion. This really looks like different approach. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Aug 24 14:26:50 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 24 Aug 2012 16:26:50 +0200 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <50361A76.2070003@redhat.com> References: <50361A76.2070003@redhat.com> Message-ID: <20120824142649.GL3980@lzapx.brq.redhat.com> > == Aeolus solution, bundler_ext [2] > > * Dependencies resolution is unaffected so 'bundle install' cannot > be used to install development dependencies, it would ignore > rpm-gems and install gems from gem-repo. > * If bundler_ext is used for setup development environment, control > over which versions are required is lost (requiring is not done by > bundler) > * It affects only how requirements are loaded [1], it's useful only > for deployment. > * (We could use it in deployment to get rid of bundler, but that is > out of this discussion's scope see Goal.2) I wonder if there is another solution: == Get rid of the bundler Make a patch to our application adding all required "require" statements so we can safely delete Gemfile and Gemfile.lock, start up Rails and it will work. Only for production of course. During our discussion with Bundler author, he said this is the preferred solution. I wonder if we need to use Bundler in production at all. Currently the only issue is we load all the gemfiles with Bundler and we do not put require statements in the individual source files. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Aug 24 14:30:44 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 24 Aug 2012 16:30:44 +0200 Subject: [katello-devel] pulp upgrade scripts for headpin mode In-Reply-To: <20120823213307.GG49540@redhat.com> References: <20120823213307.GG49540@redhat.com> Message-ID: <20120824143044.GM3980@lzapx.brq.redhat.com> On Thu, Aug 23, 2012 at 05:33:07PM -0400, Jordan O'Mara wrote: > Does it somehow do anything automatically or is it really just a > no-op? Is this script basically a placeholder for upgrading pulp in > the future? Should I add apply: katello to the placeholder? > Katello-upgrade script is meant to run manually. It will likely be interactive. Currently its a placeholder. But it is a good time to start testing it. QA question: Do you have plans for Katello upgrades (CFSE upgrades I mean) set? -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Fri Aug 24 14:32:36 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 24 Aug 2012 10:32:36 -0400 Subject: [katello-devel] pulp upgrade scripts for headpin mode In-Reply-To: <20120824143044.GM3980@lzapx.brq.redhat.com> References: <20120823213307.GG49540@redhat.com> <20120824143044.GM3980@lzapx.brq.redhat.com> Message-ID: <50379084.5070402@redhat.com> On 08/24/2012 10:30 AM, Lukas Zapletal wrote: > On Thu, Aug 23, 2012 at 05:33:07PM -0400, Jordan O'Mara wrote: >> Does it somehow do anything automatically or is it really just a >> no-op? Is this script basically a placeholder for upgrading pulp in >> the future? Should I add apply: katello to the placeholder? >> > > Katello-upgrade script is meant to run manually. It will likely be > interactive. Currently its a placeholder. But it is a good time to start > testing it. > > QA question: Do you have plans for Katello upgrades (CFSE upgrades I > mean) set? > It is a requirement for cFSE 1.1 and SAM 1.2 :) -- bk From lzap at redhat.com Fri Aug 24 14:38:15 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 24 Aug 2012 16:38:15 +0200 Subject: [katello-devel] Foreman-api In-Reply-To: <503750EC.7020605@redhat.com> References: <503750EC.7020605@redhat.com> Message-ID: <20120824143815.GN3980@lzapx.brq.redhat.com> On Fri, Aug 24, 2012 at 11:01:16AM +0100, Dmitri Dolguikh wrote: > Hey guys, > > I'm about to add api bindings for environments to Foreman API, but > was wondering about the goals of that [sub]-project. In particular, > why did we choose to create our own code instead of using Rails > ActiveResource (did anyone looked if there are still issues with > Oauth when using ActiveResource)? Another one is why do we perform > client side validation of parameters? The right question is maybe - why we started coding resource/pulp.rb and resource/candlepin.rb huge files with all the methods there? ;-) Any outcomes so far? LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From gkhachik at redhat.com Fri Aug 24 14:38:47 2012 From: gkhachik at redhat.com (Garik Khachikyan) Date: Fri, 24 Aug 2012 16:38:47 +0200 Subject: [katello-devel] pulp upgrade scripts for headpin mode In-Reply-To: <20120824143044.GM3980@lzapx.brq.redhat.com> References: <20120823213307.GG49540@redhat.com> <20120824143044.GM3980@lzapx.brq.redhat.com> Message-ID: <503791F7.3050406@redhat.com> On 24/08/12 16:30, Lukas Zapletal wrote: > On Thu, Aug 23, 2012 at 05:33:07PM -0400, Jordan O'Mara wrote: >> Does it somehow do anything automatically or is it really just a >> no-op? Is this script basically a placeholder for upgrading pulp in >> the future? Should I add apply: katello to the placeholder? >> > Katello-upgrade script is meant to run manually. It will likely be > interactive. Currently its a placeholder. But it is a good time to start > testing it. > > QA question: Do you have plans for Katello upgrades (CFSE upgrades I > mean) set? > yes- we have scenarios + automation is in progress for CFSE 1.0.x -> 1.1 upgrade. Garik From dmitri at redhat.com Fri Aug 24 14:46:51 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 24 Aug 2012 15:46:51 +0100 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <20120824142649.GL3980@lzapx.brq.redhat.com> References: <50361A76.2070003@redhat.com> <20120824142649.GL3980@lzapx.brq.redhat.com> Message-ID: <503793DB.6070108@redhat.com> On 24/08/12 03:26 PM, Lukas Zapletal wrote: >> == Aeolus solution, bundler_ext [2] >> >> * Dependencies resolution is unaffected so 'bundle install' cannot >> be used to install development dependencies, it would ignore >> rpm-gems and install gems from gem-repo. >> * If bundler_ext is used for setup development environment, control >> over which versions are required is lost (requiring is not done by >> bundler) >> * It affects only how requirements are loaded [1], it's useful only >> for deployment. >> * (We could use it in deployment to get rid of bundler, but that is >> out of this discussion's scope see Goal.2) > I wonder if there is another solution: > > == Get rid of the bundler > > Make a patch to our application adding all required "require" statements > so we can safely delete Gemfile and Gemfile.lock, start up Rails and it > will work. Only for production of course. That is exactly what bundler_ext gem does. > During our discussion with Bundler author, he said this is the preferred > solution. I wonder if we need to use Bundler in production at all. > > Currently the only issue is we load all the gemfiles with Bundler and we > do not put require statements in the individual source files. > I'm a little lost at what *exactly* we are trying to solve. I think we are talking about several problems simultaneously. To make the conversation clear[er], here is the problems that need solving: - Ability to run Katello from both bundler and rpm installs. As I mentioned before, bundler_ext does exactly that. - A way to easily reproduce production setup + development dependencies (Lukas, I think it was you who mentioned this one. Please chime in if so.). There's a couple of ways to do that using Bundler, and there's Petr's approach - the hybrid. - A related to the previous one, but somewhat separate conversation is how we are going to keep platform-specific changes/meta-data/dependencies required for builds. -d From dmitri at redhat.com Fri Aug 24 14:50:23 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 24 Aug 2012 15:50:23 +0100 Subject: [katello-devel] Foreman-api In-Reply-To: <20120824143815.GN3980@lzapx.brq.redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> Message-ID: <503794AF.6030609@redhat.com> On 24/08/12 03:38 PM, Lukas Zapletal wrote: > On Fri, Aug 24, 2012 at 11:01:16AM +0100, Dmitri Dolguikh wrote: >> Hey guys, >> >> I'm about to add api bindings for environments to Foreman API, but >> was wondering about the goals of that [sub]-project. In particular, >> why did we choose to create our own code instead of using Rails >> ActiveResource (did anyone looked if there are still issues with >> Oauth when using ActiveResource)? Another one is why do we perform >> client side validation of parameters? > The right question is maybe - why we started coding resource/pulp.rb and > resource/candlepin.rb huge files with all the methods there? ;-) They started small. It's pretty easy to break them up (we should) - each file is a collection of classes corresponding to resources on pulp/candlepin server. I'd like to see if we can switch to ActiveResource though - perhaps it's viable now. Ohad - have you looked at this lately? -d > > Any outcomes so far? > > LZ > From jrist at redhat.com Fri Aug 24 14:52:53 2012 From: jrist at redhat.com (Jason Rist) Date: Fri, 24 Aug 2012 10:52:53 -0400 Subject: [katello-devel] Foreman-api In-Reply-To: <503794AF.6030609@redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> Message-ID: <50379545.40901@redhat.com> On 08/24/2012 10:50 AM, Dmitri Dolguikh wrote: > On 24/08/12 03:38 PM, Lukas Zapletal wrote: >> On Fri, Aug 24, 2012 at 11:01:16AM +0100, Dmitri Dolguikh wrote: >>> Hey guys, >>> >>> I'm about to add api bindings for environments to Foreman API, but >>> was wondering about the goals of that [sub]-project. In particular, >>> why did we choose to create our own code instead of using Rails >>> ActiveResource (did anyone looked if there are still issues with >>> Oauth when using ActiveResource)? Another one is why do we perform >>> client side validation of parameters? >> The right question is maybe - why we started coding resource/pulp.rb and >> resource/candlepin.rb huge files with all the methods there? ;-) > They started small. It's pretty easy to break them up (we should) - each > file is a collection of classes corresponding to resources on > pulp/candlepin server. I'd like to see if we can switch to > ActiveResource though - perhaps it's viable now. Ohad - have you looked > at this lately? > > -d >> >> Any outcomes so far? >> >> LZ >> > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel OpenShift is primarily using ActiveResource. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bkearney at redhat.com Fri Aug 24 14:57:23 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 24 Aug 2012 10:57:23 -0400 Subject: [katello-devel] Foreman-api In-Reply-To: <50379545.40901@redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> Message-ID: <50379653.9090507@redhat.com> On 08/24/2012 10:52 AM, Jason Rist wrote: > On 08/24/2012 10:50 AM, Dmitri Dolguikh wrote: >> On 24/08/12 03:38 PM, Lukas Zapletal wrote: >>> On Fri, Aug 24, 2012 at 11:01:16AM +0100, Dmitri Dolguikh wrote: >>>> Hey guys, >>>> >>>> I'm about to add api bindings for environments to Foreman API, but >>>> was wondering about the goals of that [sub]-project. In particular, >>>> why did we choose to create our own code instead of using Rails >>>> ActiveResource (did anyone looked if there are still issues with >>>> Oauth when using ActiveResource)? Another one is why do we perform >>>> client side validation of parameters? >>> The right question is maybe - why we started coding resource/pulp.rb and >>> resource/candlepin.rb huge files with all the methods there? ;-) >> They started small. It's pretty easy to break them up (we should) - each >> file is a collection of classes corresponding to resources on >> pulp/candlepin server. I'd like to see if we can switch to >> ActiveResource though - perhaps it's viable now. Ohad - have you looked >> at this lately? >> >> -d >>> >>> Any outcomes so far? >>> >>> LZ >>> >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > > OpenShift is primarily using ActiveResource. If I recall, ActiveResource assumes a rather rails centric json view. It it works, rgeat. If not, you end up monkey patching alot. -- bk From dmitri at redhat.com Fri Aug 24 14:58:38 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 24 Aug 2012 15:58:38 +0100 Subject: [katello-devel] Foreman-api In-Reply-To: <50379653.9090507@redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> Message-ID: <5037969E.7010403@redhat.com> On 24/08/12 03:57 PM, Bryan Kearney wrote: > On 08/24/2012 10:52 AM, Jason Rist wrote: >> On 08/24/2012 10:50 AM, Dmitri Dolguikh wrote: >>> On 24/08/12 03:38 PM, Lukas Zapletal wrote: >>>> On Fri, Aug 24, 2012 at 11:01:16AM +0100, Dmitri Dolguikh wrote: >>>>> Hey guys, >>>>> >>>>> I'm about to add api bindings for environments to Foreman API, but >>>>> was wondering about the goals of that [sub]-project. In particular, >>>>> why did we choose to create our own code instead of using Rails >>>>> ActiveResource (did anyone looked if there are still issues with >>>>> Oauth when using ActiveResource)? Another one is why do we perform >>>>> client side validation of parameters? >>>> The right question is maybe - why we started coding >>>> resource/pulp.rb and >>>> resource/candlepin.rb huge files with all the methods there? ;-) >>> They started small. It's pretty easy to break them up (we should) - >>> each >>> file is a collection of classes corresponding to resources on >>> pulp/candlepin server. I'd like to see if we can switch to >>> ActiveResource though - perhaps it's viable now. Ohad - have you looked >>> at this lately? >>> >>> -d >>>> >>>> Any outcomes so far? >>>> >>>> LZ >>>> >>> >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> >> >> OpenShift is primarily using ActiveResource. > > If I recall, ActiveResource assumes a rather rails centric json view. > It it works, rgeat. If not, you end up monkey patching alot. Hmm. I remember issues with OAuth and not-very-restful urls (I don't remember any json issues though). Perhaps those have been solved/made manageable? -d > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From msuchy at redhat.com Fri Aug 24 20:04:17 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Fri, 24 Aug 2012 22:04:17 +0200 Subject: [katello-devel] When working on bugs... Message-ID: <5037DE41.4010703@redhat.com> * When you start working on bug, please assign it to yourself and move it to ASSIGNED. * You can steal bug only if is NEW. If bug is ASSIGNED, contact owner of that bug ("Assigned To") first. And if he is on PTO, at least check Pull Request queue first - it is quite long recently. This may sound trivial, but I've seen recently several issues with this. Mirek From inecas at redhat.com Mon Aug 27 09:27:27 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 27 Aug 2012 11:27:27 +0200 Subject: [katello-devel] Foreman-api In-Reply-To: <5037969E.7010403@redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> Message-ID: <503B3D7F.6020102@redhat.com> On 08/24/2012 04:58 PM, Dmitri Dolguikh wrote: > On 24/08/12 03:57 PM, Bryan Kearney wrote: >> On 08/24/2012 10:52 AM, Jason Rist wrote: >>> On 08/24/2012 10:50 AM, Dmitri Dolguikh wrote: >>>> On 24/08/12 03:38 PM, Lukas Zapletal wrote: >>>>> On Fri, Aug 24, 2012 at 11:01:16AM +0100, Dmitri Dolguikh wrote: >>>>>> Hey guys, >>>>>> >>>>>> I'm about to add api bindings for environments to Foreman API, but >>>>>> was wondering about the goals of that [sub]-project. In particular, >>>>>> why did we choose to create our own code instead of using Rails >>>>>> ActiveResource (did anyone looked if there are still issues with >>>>>> Oauth when using ActiveResource)? Another one is why do we perform >>>>>> client side validation of parameters? >>>>> The right question is maybe - why we started coding >>>>> resource/pulp.rb and >>>>> resource/candlepin.rb huge files with all the methods there? ;-) >>>> They started small. It's pretty easy to break them up (we should) - >>>> each >>>> file is a collection of classes corresponding to resources on >>>> pulp/candlepin server. I'd like to see if we can switch to >>>> ActiveResource though - perhaps it's viable now. Ohad - have you >>>> looked >>>> at this lately? >>>> >>>> -d >>>>> >>>>> Any outcomes so far? >>>>> >>>>> LZ >>>>> >>>> >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >>> >>> OpenShift is primarily using ActiveResource. >> >> If I recall, ActiveResource assumes a rather rails centric json view. >> It it works, rgeat. If not, you end up monkey patching alot. > Hmm. I remember issues with OAuth and not-very-restful urls (I don't > remember any json issues though). Perhaps those have been solved/made > manageable? What advantage does it bring us? ActiveResource works well only if you strictly follow the Rails conventions. Take an example from the client library for Katello based on ActiveResources [1]. It doesn't work well (forcing you to do hacks), because for security reasons, Katello does allow you only subset of attributes. So from this code, I know nothing about what arguments I can pass in (I see only arguments I can't update, which is quite useless). If you take a look at the generated code [2] for Foreman, you immediately see, how you can use that. No hacks needed. Another fact is that this approach forces you to document you API. ActiveResource without sufficient documentation of your API is unusable. Me as a developer, I find it much easier to use the code that I immediately see what it expects from me. [1] - https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb [2] - https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb > > -d >> >> -- 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 pchalupa at redhat.com Mon Aug 27 10:46:23 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Mon, 27 Aug 2012 12:46:23 +0200 Subject: [katello-devel] 'rescue Exception => e' removed Message-ID: <503B4FFF.8050706@redhat.com> Hi, I've just merged pull-request [1] removing "rescue Exception => e" from katello source code. Please do not use "rescue Exception => e" any more, use standard "rescue => e" (which is equivalent with "rescue StandardError => e") or better specify the exception class "rescue ActiveRecord::RecordNotSaved => e". See the pull request for why. Thanks, Petr [1] https://github.com/Katello/katello/pull/176 From msuchy at redhat.com Mon Aug 27 11:07:14 2012 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Mon, 27 Aug 2012 13:07:14 +0200 Subject: [katello-devel] Foreman-api In-Reply-To: <503B3D7F.6020102@redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> <503B3D7F.6020102@redhat.com> Message-ID: <503B54E2.4090801@redhat.com> On 08/27/2012 11:27 AM, Ivan Ne?as wrote: > Me as a developer, I find it much easier to use the code that I > immediately see what it expects from me. > > [1] - > https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb > > [2] - > https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb > +1 [2] is much more readable to me. -- Miroslav Suchy Red Hat Systems Management Engineering From lzap at redhat.com Mon Aug 27 12:15:26 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 27 Aug 2012 14:15:26 +0200 Subject: [katello-devel] Foreman-api In-Reply-To: <503B54E2.4090801@redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> <503B3D7F.6020102@redhat.com> <503B54E2.4090801@redhat.com> Message-ID: <20120827121526.GD6031@lzapx.brq.redhat.com> On Mon, Aug 27, 2012 at 01:07:14PM +0200, Miroslav Suchy wrote: > On 08/27/2012 11:27 AM, Ivan Ne?as wrote: > >Me as a developer, I find it much easier to use the code that I > >immediately see what it expects from me. > > > >[1] - > >https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb > > > >[2] - > >https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb > > > > +1 > [2] is much more readable to me. +1 No more "dynamic" stuff please. Plus your favourite IDE can OmniComplete :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From calfonso at redhat.com Mon Aug 27 13:54:25 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Mon, 27 Aug 2012 09:54:25 -0400 Subject: [katello-devel] Foreman-api In-Reply-To: <20120827121526.GD6031@lzapx.brq.redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> <503B3D7F.6020102@redhat.com> <503B54E2.4090801@redhat.com> <20120827121526.GD6031@lzapx.brq.redhat.com> Message-ID: <20120827135425.GA4524@dhcp-230-220.rdu.redhat.com> On 27/08/12 14:15 +0200, Lukas Zapletal wrote: >On Mon, Aug 27, 2012 at 01:07:14PM +0200, Miroslav Suchy wrote: >> On 08/27/2012 11:27 AM, Ivan Ne?as wrote: >> >Me as a developer, I find it much easier to use the code that I >> >immediately see what it expects from me. >> > >> >[1] - >> >https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb >> > >> >[2] - >> >https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb >> > >> >> +1 >> [2] is much more readable to me. > >+1 No more "dynamic" stuff please. > >Plus your favourite IDE can OmniComplete :-) > >-- >Later, > Would you guys be interested in auto generating a katello api client gem? It would be really nice to be able to keep the client in sync with the server api without having to really study the api changes. Also, it would be really nice to generate tests to go along with the rest client classes. Regarding the deadwood attribute removal ambiguity comments, I think you guys are comparing apples to oranges. The consuming application that uses a client will either want to interact with model objects and pass them around in a client api, or they will be happy with passing around descriptive hashes. In the case of the model object pattern, the developer should never have to see the client api implementation, I just remove the attributeds that aren't allowed to be updated[1]. If I pass a hash representation of a domain [3], I can see by looking at the forman api code implementation which attributes will be sent to foreman, but I still have to look at the forman api documentation to understand what all attributes are avaialable on a domain model and what values are acceptable and why I wasn't able to send every domain attribute in an update api call (why is it a subset?). Don't get me wrong here, anytime you have server side attribute validation the client will want to know what attributes are being validated and why. Right now the only way to find out what model attributes in Katello that are not allowed in an update is by submiting a request and watching a traceback appear in the server logs. Personally, I think this is a documentaiton task TODO. I don't expect developers to go read the Katello controller implementation to discover what type of validation has to happen, just as I don't expect api gem consumers to have to read the api gem implemenation to read what attributes are not allowed. As a TODO for me, I'll add the documentation to the deadwood api for now to describe the model attributes (allowed, not allowed, values, etc). -- Chris > Lukas "lzap" Zapletal > #katello #systemengine > >_______________________________________________ >katello-devel mailing list >katello-devel at redhat.com >https://www.redhat.com/mailman/listinfo/katello-devel [3]https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/domain.rb -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From mmccune at redhat.com Mon Aug 27 15:15:48 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 27 Aug 2012 08:15:48 -0700 Subject: [katello-devel] 'rescue Exception => e' removed In-Reply-To: <503B4FFF.8050706@redhat.com> References: <503B4FFF.8050706@redhat.com> Message-ID: <503B8F24.900@redhat.com> On 08/27/2012 03:46 AM, Petr Chalupa wrote: > Hi, > > I've just merged pull-request [1] removing "rescue Exception => e" from > katello source code. > > Please do not use "rescue Exception => e" any more, use standard "rescue > => e" (which is equivalent with "rescue StandardError => e") or better > specify the exception class "rescue ActiveRecord::RecordNotSaved => e". > > See the pull request for why. > > Thanks, Petr > > [1] https://github.com/Katello/katello/pull/176 > excellent work From inecas at redhat.com Mon Aug 27 16:33:40 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 27 Aug 2012 18:33:40 +0200 Subject: [katello-devel] 'rescue Exception => e' removed In-Reply-To: <503B8F24.900@redhat.com> References: <503B4FFF.8050706@redhat.com> <503B8F24.900@redhat.com> Message-ID: <503BA164.6030201@redhat.com> On 08/27/2012 05:15 PM, Mike McCune wrote: > On 08/27/2012 03:46 AM, Petr Chalupa wrote: >> Hi, >> >> I've just merged pull-request [1] removing "rescue Exception => e" from >> katello source code. >> >> Please do not use "rescue Exception => e" any more, use standard >> "rescue >> => e" (which is equivalent with "rescue StandardError => e") or better >> specify the exception class "rescue ActiveRecord::RecordNotSaved => e". >> >> See the pull request for why. >> >> Thanks, Petr >> >> [1] https://github.com/Katello/katello/pull/176 >> > > excellent work +1 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Ivan From pchalupa at redhat.com Tue Aug 28 07:11:06 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 28 Aug 2012 09:11:06 +0200 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <20120824142649.GL3980@lzapx.brq.redhat.com> References: <50361A76.2070003@redhat.com> <20120824142649.GL3980@lzapx.brq.redhat.com> Message-ID: <503C6F0A.4080402@redhat.com> We could get rid of the bundler, but we have to consider that we loose control over what katello is requiring. If somebody installs newer gem with 'sudo gem install rails' without using yum, katello will require this newer version and will be broken. Actually (I did not consider this before) this will be prevented by the path [1] because the older version installed with yum is picked and required. Petr [1] https://github.com/Katello/katello/pull/526 On 24.08.12 16:26, Lukas Zapletal wrote: >> == Aeolus solution, bundler_ext [2] >> >> * Dependencies resolution is unaffected so 'bundle install' cannot >> be used to install development dependencies, it would ignore >> rpm-gems and install gems from gem-repo. >> * If bundler_ext is used for setup development environment, control >> over which versions are required is lost (requiring is not done by >> bundler) >> * It affects only how requirements are loaded [1], it's useful only >> for deployment. >> * (We could use it in deployment to get rid of bundler, but that is >> out of this discussion's scope see Goal.2) > > I wonder if there is another solution: > > == Get rid of the bundler > > Make a patch to our application adding all required "require" statements > so we can safely delete Gemfile and Gemfile.lock, start up Rails and it > will work. Only for production of course. > > During our discussion with Bundler author, he said this is the preferred > solution. I wonder if we need to use Bundler in production at all. > > Currently the only issue is we load all the gemfiles with Bundler and we > do not put require statements in the individual source files. > From pchalupa at redhat.com Tue Aug 28 07:21:02 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 28 Aug 2012 09:21:02 +0200 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <5036251A.3050401@redhat.com> References: <50361A76.2070003@redhat.com> <5036251A.3050401@redhat.com> Message-ID: <503C715E.3060207@redhat.com> On 23.08.12 14:42, Dmitri Dolguikh wrote: > On 23/08/12 12:56 PM, Petr Chalupa wrote: >> My original email raised a lot of questions, I should wrote it with >> more details. I apology for that. I'll try again and elaborate. >> >> = Goals >> >> 1) To be able to implement the solution in a week or so. >> 2) Not to affect deployment, keep it same way as now. >> 3) When you are installing development environment on any rpm-based >> system rpm-gems are used even if they are older then gems in our >> gem-repo. (this is borken right now) >> 4) When you are installing development environment in any non-rpm-base >> system you get installed gems as close as possible to what would you >> get on fedora 16. (you cannot install with bundle install only right now) >> * (optionally including the security patches, lets discuss this later) >> >> = What was discussed, why I think it wont work >> >> == Branch for each platform >> >> * There would be little difference between the branches (only Gemfile >> or Gemfile.lock). Rest of the code will be same. >> * It would be too much work to maintain it. >> >> == Gemfile.lock per platform and environment >> >> * We would have to have 8 Gemfile.locks and maintain them all (4 >> platforms multiplied by two environments) >> * Too much work unless its automated. >> * Automation would take time to setup. >> >> == Aeolus solution, bundler_ext [2] >> >> * Dependencies resolution is unaffected so 'bundle install' cannot be >> used to install development dependencies, it would ignore rpm-gems and >> install gems from gem-repo. >> * If bundler_ext is used for setup development environment, control >> over which versions are required is lost (requiring is not done by >> bundler) >> * It affects only how requirements are loaded [1], it's useful only >> for deployment. >> * (We could use it in deployment to get rid of bundler, but that is >> out of this discussion's scope see Goal.2) >> >> == bundle install --without default >> >> This installs only development gems, but: >> >> * If some of the development gems has a production gem as dependency >> (eg. ActiveSupport), the gem is reinstalled by bundler from a gem-repo >> over the older rpm-gem. >> * If only development gems are installed, bundler cannot be used to >> require gems. It will raise LoadError because from bundler's point of >> view production gems are not installed. >> * It would have to be combined with bundler_ext to find production >> rpm-gems, so you would loose control over which version are loaded again >> * If you forget to add '--without default' when you run 'bundle >> install' unwanted versions are installed. >> >> == vendor/cache >> >> Move all gems to src/vendor/cache (directly into katello/master or as >> a git sub-module) and remove sources form Gemfile completely. 'bundle >> install' installs gems form vendor/cache automatically if there are no >> sources in Gemfile. >> >> * to have .gem files directly in katello/master is ugly >> * submodules are real pain > no need to use sub-modules >> * git is not that good with binary data >> > gems are mostly ruby, very not a lot of binary data. gems would be stored in vendor/cache as .gem files, one file per gem which are actually tar.gz (binary). That is what I meant sorry about the confusion. >> = My proposal >> >> == Bundler patch >> >> * it would be loaded in Gemfile, so every tool using bundler will get it > I don't think a single Gemfile is going to solve the issue: we'll need > to relax version constraints in Gemfile, and add a bunch of ruby-version > specific gems... >> >> * it would ensure that if rpm-gem is present it's used even if there >> is newer version available in gem-repo >> * ensure that locally installed gems are not confused with rpm-gems > You didn't explain how you are planning to differentiate between the two > - system-wide bundler-/ruby-gem-installed gems and rpm-installed gems... I don't think this is a problem, see [1] how I did it. >> >> * patch is optional, can be turned on/off by ENV variable or by options >> * (I am also considering to add optional check that all production >> gems are installed as rpms) >> >> Deployment is unaffected, all dependencies are satisfied by rpm-gems. >> >> When you run bundle install to get development environment on any >> rpm-based machine, all your rpms have priority and they are used. All >> missing development gems are installed from our gem-repo. > I think this is the crux of the issue. Once we have a custom gem > repository, the above step has very little practical value. A ruby gem > is a ruby gem no matter what place in the system it's installed in. IMO This has a big practical value. When you are fixing a bug you want to be sure that you have same rpm-gems installed and required as in production where the bug was discovered. >> >> On non-rpm-based machine, 'bundle install' installs all gems >> production and development from our gem-repo. >> >> == Gem Repository >> >> Bundler patch will work only if all development and production gems >> are in the gem-repo. To get it fixed quickly 'bundle package' can be >> used to get all the gems. Missing gems can be then uploaded to >> katello-thirdparty (source for our gem-repo) >> >> = Summary >> >> I think that Bundler patch and updating gem-repo to contain all gems >> is the only one which can be done fast and will work on any machine in >> deployment and development. I tried to be thorough but if I missed >> something or if you have better ideas please let me know. > The issue with dependency version variability needs solving. The patch > itself has little practical value, bundle install from custom repository > is sufficient. The irony is that you are trying to solve the problem > Bundler has successfully solved awhile ago. I'm baffled as to why we > continue to insist on solving the problems the "katello" way. > > -d > >> >> Petr >> >> [1] >> https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 >> >> [2] https://github.com/aeolus-incubator/bundler_ext >> >> _______________________________________________ >> 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 [1] https://github.com/Katello/katello/pull/526 From pchalupa at redhat.com Tue Aug 28 08:53:42 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 28 Aug 2012 10:53:42 +0200 Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <503637C2.9030304@redhat.com> References: <1109139362.12559597.1345644633125.JavaMail.root@redhat.com> <503637C2.9030304@redhat.com> Message-ID: <503C8716.4050907@redhat.com> Martin is right. Its generic only .resource method has to be fixed and it is also dependent on api of foreman_bindings see [1], the methods would have to have same signitures. +1 for using this for pulp v2 Petr [1] https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/config_template.rb On 23.08.12 16:01, Martin Bacovsky wrote: > On 08/22/2012 04:10 PM, Eric Helms wrote: >> Excellent - this is exactly what I was looking for and missed that >> there was a separate set of API bindings in a gem due to no requires >> at the top of the file in lib/resources. >> >> Looking closer at the lib/resources/foreman_model.rb this mostly seems >> like a generic layer for interacting with a set of Ruby API bindings >> and could be re-purposed to used by any of the glue layers. Keeping >> in mind I am pondering this with regards to our migration to Pulp V2 >> and the re-factoring and work that will be associated with it. How >> much in this file is Foreman specific? >> >> -Eric > You are right, the ForemanModel is pretty generic and could be used for > any other resources with API bindings. Only the resource method is > Foreman specific and that would be easy to fix. Im not sure however if > it is applicable for Candlepin and Pulp as they don't use API bindings > but just are proxying the requests (someone correct me if I'm wrong). > > -Martin > > >> >> ----- Original Message ----- >> From: "Martin Bacovsky" >> To: katello-devel at redhat.com >> Sent: Wednesday, August 22, 2012 4:23:10 AM >> Subject: Re: [katello-devel] Katello-Foreman Integration API Layer >> Question >> >> On 08/22/2012 09:12 AM, Ivan Ne?as wrote: >>> On Tue 21 Aug 2012 05:31:43 PM CEST, Eric Helms wrote: >>>> A question after seeing the current progress of the Foreman >>>> integration work around the API layer. This is inspired by some >>>> thoughts we've had around the Pulp v2 migrations. >>>> >>>> Has any thought been given to generating a separate >>>> library/gem/project for the API part? Since this would be a re-usable >>>> component by potentially other communities and present a nice, clean >>>> set of ruby bindings for the Foreman APIs that we could consume (as >>>> well as others). >>> Is this the answer? >>> >>> https://github.com/mbacovsky/foreman_api >>> >>> -- Ivan >> The foreman_api is generated from API documentation using the Apipie >> tool [1]. The tool's other nice feature is that you can generate simple >> CLI client, but as the new API is still far from complete neither we nor >> the foreman community provide one. >> >> The foreman_api is available in git repo [3] (most fresh version is >> usually on the link Ivan provided), as a gem on rubygems.org and also in >> our katello-thirdparty repo as a rpm. It should be available soon as a >> rpm and deb for the Foreman community by their own means. >> >> Here is short wiki [2] on how we use the bindings in katello. If you >> find anything you need to add there, let me know. >> >> Martin >> >> [1] https://github.com/Pajk/apipie-rails >> [2] https://fedorahosted.org/katello/wiki/ForemanIntegrationAPI >> [3] https://github.com/theforeman/foreman_api >> >> >>>> - Eric >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 Tue Aug 28 09:08:57 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 28 Aug 2012 10:08:57 +0100 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <503C715E.3060207@redhat.com> References: <50361A76.2070003@redhat.com> <5036251A.3050401@redhat.com> <503C715E.3060207@redhat.com> Message-ID: <503C8AA9.5050108@redhat.com> On 28/08/12 08:21 AM, Petr Chalupa wrote: > > > On 23.08.12 14:42, Dmitri Dolguikh wrote: >> On 23/08/12 12:56 PM, Petr Chalupa wrote: >>> My original email raised a lot of questions, I should wrote it with >>> more details. I apology for that. I'll try again and elaborate. >>> >>> = Goals >>> >>> 1) To be able to implement the solution in a week or so. >>> 2) Not to affect deployment, keep it same way as now. >>> 3) When you are installing development environment on any rpm-based >>> system rpm-gems are used even if they are older then gems in our >>> gem-repo. (this is borken right now) >>> 4) When you are installing development environment in any non-rpm-base >>> system you get installed gems as close as possible to what would you >>> get on fedora 16. (you cannot install with bundle install only right >>> now) >>> * (optionally including the security patches, lets discuss this >>> later) >>> >>> = What was discussed, why I think it wont work >>> >>> == Branch for each platform >>> >>> * There would be little difference between the branches (only Gemfile >>> or Gemfile.lock). Rest of the code will be same. >>> * It would be too much work to maintain it. >>> >>> == Gemfile.lock per platform and environment >>> >>> * We would have to have 8 Gemfile.locks and maintain them all (4 >>> platforms multiplied by two environments) >>> * Too much work unless its automated. >>> * Automation would take time to setup. >>> >>> == Aeolus solution, bundler_ext [2] >>> >>> * Dependencies resolution is unaffected so 'bundle install' cannot be >>> used to install development dependencies, it would ignore rpm-gems and >>> install gems from gem-repo. >>> * If bundler_ext is used for setup development environment, control >>> over which versions are required is lost (requiring is not done by >>> bundler) >>> * It affects only how requirements are loaded [1], it's useful only >>> for deployment. >>> * (We could use it in deployment to get rid of bundler, but that is >>> out of this discussion's scope see Goal.2) >>> >>> == bundle install --without default >>> >>> This installs only development gems, but: >>> >>> * If some of the development gems has a production gem as dependency >>> (eg. ActiveSupport), the gem is reinstalled by bundler from a gem-repo >>> over the older rpm-gem. >>> * If only development gems are installed, bundler cannot be used to >>> require gems. It will raise LoadError because from bundler's point of >>> view production gems are not installed. >>> * It would have to be combined with bundler_ext to find production >>> rpm-gems, so you would loose control over which version are loaded >>> again >>> * If you forget to add '--without default' when you run 'bundle >>> install' unwanted versions are installed. >>> >>> == vendor/cache >>> >>> Move all gems to src/vendor/cache (directly into katello/master or as >>> a git sub-module) and remove sources form Gemfile completely. 'bundle >>> install' installs gems form vendor/cache automatically if there are no >>> sources in Gemfile. >>> >>> * to have .gem files directly in katello/master is ugly >>> * submodules are real pain >> no need to use sub-modules >>> * git is not that good with binary data >>> >> gems are mostly ruby, very not a lot of binary data. > > gems would be stored in vendor/cache as .gem files, one file per gem > which are actually tar.gz (binary). That is what I meant sorry about > the confusion. > >>> = My proposal >>> >>> == Bundler patch >>> >>> * it would be loaded in Gemfile, so every tool using bundler will >>> get it >> I don't think a single Gemfile is going to solve the issue: we'll need >> to relax version constraints in Gemfile, and add a bunch of ruby-version >> specific gems... >>> >>> * it would ensure that if rpm-gem is present it's used even if there >>> is newer version available in gem-repo >>> * ensure that locally installed gems are not confused with rpm-gems >> You didn't explain how you are planning to differentiate between the two >> - system-wide bundler-/ruby-gem-installed gems and rpm-installed gems... > > I don't think this is a problem, see [1] how I did it. This is not a good approach - you introduced platform-specific code into main Katello code base. >>> * patch is optional, can be turned on/off by ENV variable or by options >>> * (I am also considering to add optional check that all production >>> gems are installed as rpms) >>> >>> Deployment is unaffected, all dependencies are satisfied by rpm-gems. >>> >>> When you run bundle install to get development environment on any >>> rpm-based machine, all your rpms have priority and they are used. All >>> missing development gems are installed from our gem-repo. >> I think this is the crux of the issue. Once we have a custom gem >> repository, the above step has very little practical value. A ruby gem >> is a ruby gem no matter what place in the system it's installed in. > > IMO This has a big practical value. When you are fixing a bug you want > to be sure that you have same rpm-gems installed and required as in > production where the bug was discovered. Do you understand how ruby loads gem dependencies? Can you explain the difference between rpm-installed gem, and bundler-installed gem (for system-wide installs)? -d > > >>> >>> On non-rpm-based machine, 'bundle install' installs all gems >>> production and development from our gem-repo. >>> >>> == Gem Repository >>> >>> Bundler patch will work only if all development and production gems >>> are in the gem-repo. To get it fixed quickly 'bundle package' can be >>> used to get all the gems. Missing gems can be then uploaded to >>> katello-thirdparty (source for our gem-repo) >>> >>> = Summary >>> >>> I think that Bundler patch and updating gem-repo to contain all gems >>> is the only one which can be done fast and will work on any machine in >>> deployment and development. I tried to be thorough but if I missed >>> something or if you have better ideas please let me know. >> The issue with dependency version variability needs solving. The patch >> itself has little practical value, bundle install from custom repository >> is sufficient. The irony is that you are trying to solve the problem >> Bundler has successfully solved awhile ago. I'm baffled as to why we >> continue to insist on solving the problems the "katello" way. >> >> -d >> >>> >>> Petr >>> >>> [1] >>> https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 >>> >>> >>> [2] https://github.com/aeolus-incubator/bundler_ext >>> >>> _______________________________________________ >>> 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 > > [1] https://github.com/Katello/katello/pull/526 From dmitri at redhat.com Tue Aug 28 09:22:46 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 28 Aug 2012 10:22:46 +0100 Subject: [katello-devel] Foreman-api In-Reply-To: <503B3D7F.6020102@redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> <503B3D7F.6020102@redhat.com> Message-ID: <503C8DE6.7050905@redhat.com> On 27/08/12 10:27 AM, Ivan Ne?as wrote: > On 08/24/2012 04:58 PM, Dmitri Dolguikh wrote: >> On 24/08/12 03:57 PM, Bryan Kearney wrote: >>> On 08/24/2012 10:52 AM, Jason Rist wrote: >>>> On 08/24/2012 10:50 AM, Dmitri Dolguikh wrote: >>>>> On 24/08/12 03:38 PM, Lukas Zapletal wrote: >>>>>> On Fri, Aug 24, 2012 at 11:01:16AM +0100, Dmitri Dolguikh wrote: >>>>>>> Hey guys, >>>>>>> >>>>>>> I'm about to add api bindings for environments to Foreman API, but >>>>>>> was wondering about the goals of that [sub]-project. In particular, >>>>>>> why did we choose to create our own code instead of using Rails >>>>>>> ActiveResource (did anyone looked if there are still issues with >>>>>>> Oauth when using ActiveResource)? Another one is why do we perform >>>>>>> client side validation of parameters? >>>>>> The right question is maybe - why we started coding >>>>>> resource/pulp.rb and >>>>>> resource/candlepin.rb huge files with all the methods there? ;-) >>>>> They started small. It's pretty easy to break them up (we should) >>>>> - each >>>>> file is a collection of classes corresponding to resources on >>>>> pulp/candlepin server. I'd like to see if we can switch to >>>>> ActiveResource though - perhaps it's viable now. Ohad - have you >>>>> looked >>>>> at this lately? >>>>> >>>>> -d >>>>>> >>>>>> Any outcomes so far? >>>>>> >>>>>> LZ >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> katello-devel mailing list >>>>> katello-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> >>>> >>>> OpenShift is primarily using ActiveResource. >>> >>> If I recall, ActiveResource assumes a rather rails centric json >>> view. It it works, rgeat. If not, you end up monkey patching alot. >> Hmm. I remember issues with OAuth and not-very-restful urls (I don't >> remember any json issues though). Perhaps those have been solved/made >> manageable? > What advantage does it bring us? > > ActiveResource works well only if you strictly follow the Rails > conventions. We are using rails, and are following Rest conventions most of the time (the rest of the cases should be fixed). > Take an example from the client library for Katello based on > ActiveResources [1]. It doesn't work well (forcing you to do hacks), > because for security reasons, Katello does allow you only subset of > attributes. So from this code, I know nothing about what arguments I > can pass in (I see only arguments I can't update, which is quite > useless). > > If you take a look at the generated code [2] for Foreman, you > immediately see, how you can use that. No hacks needed. Another fact > is that this approach forces you to document you API. ActiveResource > without sufficient documentation of your API is unusable. I'm not arguing about documentation. > > Me as a developer, I find it much easier to use the code that I > immediately see what it expects from me. > > [1] - > https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb > [2] - > https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb I'd argue that the attribute filtration doesn't belong in [1]. [2] has a lot of repetitive code, indeed that's the reason why you generate it, and why I don't like it. It makes more sense for non-standard methods, but index, show, update, create can either be moved into some common mixin, or be generated similarly to accessor generators. -d >> >> -d >>> >>> -- 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 dmitri at redhat.com Tue Aug 28 09:29:13 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 28 Aug 2012 10:29:13 +0100 Subject: [katello-devel] Foreman-api In-Reply-To: <20120827121526.GD6031@lzapx.brq.redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> <503B3D7F.6020102@redhat.com> <503B54E2.4090801@redhat.com> <20120827121526.GD6031@lzapx.brq.redhat.com> Message-ID: <503C8F69.9030707@redhat.com> On 27/08/12 01:15 PM, Lukas Zapletal wrote: > On Mon, Aug 27, 2012 at 01:07:14PM +0200, Miroslav Suchy wrote: >> On 08/27/2012 11:27 AM, Ivan Ne?as wrote: >>> Me as a developer, I find it much easier to use the code that I >>> immediately see what it expects from me. >>> >>> [1] - >>> https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb >>> >>> [2] - >>> https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb >>> >> +1 >> [2] is much more readable to me. > +1 No more "dynamic" stuff please. I don't want to get into discussion about code generation. We are developing within constraints and using conventions of REST and Rails. We should only write code when we are dealing with something that doesn't follow conventions, or extends them, instead of repeating the obvious. -d > > Plus your favourite IDE can OmniComplete :-) > From dmitri at redhat.com Tue Aug 28 09:37:12 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 28 Aug 2012 10:37:12 +0100 Subject: [katello-devel] Katello-Foreman Integration API Layer Question In-Reply-To: <20120822082246.GB3044@lzapx.brq.redhat.com> References: <5033B135.2050403@redhat.com> <1858040011.12284235.1345574654206.JavaMail.root@redhat.com> <20120822082246.GB3044@lzapx.brq.redhat.com> Message-ID: <503C9148.9030701@redhat.com> On 22/08/12 09:22 AM, Lukas Zapletal wrote: > On Tue, Aug 21, 2012 at 02:44:14PM -0400, Eric Helms wrote: >> To clarify a bit, in Katello today, the ruby bindings (for both Pulp and Candlepin) are tied to Katello code and we are working to change that as we do our Pulp V2 migration work. I.E. create a stand-alone set of ruby-bindings to Pulp that Katello can consume. But are we doing the same with Foreman? >> >> A good example of what I mean is Funzo's project deadwood for Katello - https://github.com/calfonso/deadwood > Well, the best approach would be to generate those automatically. That > makes big difference. > I think that the only problem that static code generation solves is that of typing. I said this in the other thread, and I'll repeat this here. We are operating within constraints and use conventions of Rails and REST. Our code should not repeatedly state the obvious, but rather show where and how we deviate from those constraints and conventions. Ruby in general, and Rails in particular are very good at following this approach, which we should follow as well. -d From lzap at redhat.com Tue Aug 28 10:29:47 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 28 Aug 2012 12:29:47 +0200 Subject: [katello-devel] Demotions and deletions Message-ID: <20120828102947.GB1383@lzapx.brq.redhat.com> Hey, stumbled upon a bug (https://bugzilla.redhat.com/show_bug.cgi?id=835875) that prevents you from creating a repository with a same name that has been deleted (but promoted). Now the question - we now do support demotions (those promotions opposite - not sure about wording). Therefore I guess the proper solution would be to check if the repository (*) was already promoted. If so, Katello will refuse to delete the object asking user to do the demotion. Opinions? (*) this should apply to anything that is promotable: - product - repo - template - package - erratum - distribution -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Tue Aug 28 10:47:07 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 28 Aug 2012 11:47:07 +0100 Subject: [katello-devel] Demotions and deletions In-Reply-To: <20120828102947.GB1383@lzapx.brq.redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> Message-ID: <503CA1AB.8000503@redhat.com> On 28/08/12 11:29 AM, Lukas Zapletal wrote: > Hey, > > stumbled upon a bug (https://bugzilla.redhat.com/show_bug.cgi?id=835875) > that prevents you from creating a repository with a same name that has > been deleted (but promoted). > > Now the question - we now do support demotions (those promotions > opposite - not sure about wording). Therefore I guess the proper > solution would be to check if the repository (*) was already promoted. > If so, Katello will refuse to delete the object asking user to do the > demotion. Not sure I understand the issue correctly - are you concerned that a user can mixup deletion with demotion? Shouldn't they be semantically the same? -d > > Opinions? > > (*) this should apply to anything that is promotable: > > - product > - repo > - template > - package > - erratum > - distribution > From pchalupa at redhat.com Tue Aug 28 11:13:48 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 28 Aug 2012 13:13:48 +0200 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <503C8AA9.5050108@redhat.com> References: <50361A76.2070003@redhat.com> <5036251A.3050401@redhat.com> <503C715E.3060207@redhat.com> <503C8AA9.5050108@redhat.com> Message-ID: <503CA7EC.6060209@redhat.com> On 28.08.12 11:08, Dmitri Dolguikh wrote: > On 28/08/12 08:21 AM, Petr Chalupa wrote: >> >> >> On 23.08.12 14:42, Dmitri Dolguikh wrote: >>> On 23/08/12 12:56 PM, Petr Chalupa wrote: >>>> My original email raised a lot of questions, I should wrote it with >>>> more details. I apology for that. I'll try again and elaborate. >>>> >>>> = Goals >>>> >>>> 1) To be able to implement the solution in a week or so. >>>> 2) Not to affect deployment, keep it same way as now. >>>> 3) When you are installing development environment on any rpm-based >>>> system rpm-gems are used even if they are older then gems in our >>>> gem-repo. (this is borken right now) >>>> 4) When you are installing development environment in any non-rpm-base >>>> system you get installed gems as close as possible to what would you >>>> get on fedora 16. (you cannot install with bundle install only right >>>> now) >>>> * (optionally including the security patches, lets discuss this >>>> later) >>>> >>>> = What was discussed, why I think it wont work >>>> >>>> == Branch for each platform >>>> >>>> * There would be little difference between the branches (only Gemfile >>>> or Gemfile.lock). Rest of the code will be same. >>>> * It would be too much work to maintain it. >>>> >>>> == Gemfile.lock per platform and environment >>>> >>>> * We would have to have 8 Gemfile.locks and maintain them all (4 >>>> platforms multiplied by two environments) >>>> * Too much work unless its automated. >>>> * Automation would take time to setup. >>>> >>>> == Aeolus solution, bundler_ext [2] >>>> >>>> * Dependencies resolution is unaffected so 'bundle install' cannot be >>>> used to install development dependencies, it would ignore rpm-gems and >>>> install gems from gem-repo. >>>> * If bundler_ext is used for setup development environment, control >>>> over which versions are required is lost (requiring is not done by >>>> bundler) >>>> * It affects only how requirements are loaded [1], it's useful only >>>> for deployment. >>>> * (We could use it in deployment to get rid of bundler, but that is >>>> out of this discussion's scope see Goal.2) >>>> >>>> == bundle install --without default >>>> >>>> This installs only development gems, but: >>>> >>>> * If some of the development gems has a production gem as dependency >>>> (eg. ActiveSupport), the gem is reinstalled by bundler from a gem-repo >>>> over the older rpm-gem. >>>> * If only development gems are installed, bundler cannot be used to >>>> require gems. It will raise LoadError because from bundler's point of >>>> view production gems are not installed. >>>> * It would have to be combined with bundler_ext to find production >>>> rpm-gems, so you would loose control over which version are loaded >>>> again >>>> * If you forget to add '--without default' when you run 'bundle >>>> install' unwanted versions are installed. >>>> >>>> == vendor/cache >>>> >>>> Move all gems to src/vendor/cache (directly into katello/master or as >>>> a git sub-module) and remove sources form Gemfile completely. 'bundle >>>> install' installs gems form vendor/cache automatically if there are no >>>> sources in Gemfile. >>>> >>>> * to have .gem files directly in katello/master is ugly >>>> * submodules are real pain >>> no need to use sub-modules >>>> * git is not that good with binary data >>>> >>> gems are mostly ruby, very not a lot of binary data. >> >> gems would be stored in vendor/cache as .gem files, one file per gem >> which are actually tar.gz (binary). That is what I meant sorry about >> the confusion. >> >>>> = My proposal >>>> >>>> == Bundler patch >>>> >>>> * it would be loaded in Gemfile, so every tool using bundler will >>>> get it >>> I don't think a single Gemfile is going to solve the issue: we'll need >>> to relax version constraints in Gemfile, and add a bunch of ruby-version >>> specific gems... >>>> >>>> * it would ensure that if rpm-gem is present it's used even if there >>>> is newer version available in gem-repo >>>> * ensure that locally installed gems are not confused with rpm-gems >>> You didn't explain how you are planning to differentiate between the two >>> - system-wide bundler-/ruby-gem-installed gems and rpm-installed gems... >> >> I don't think this is a problem, see [1] how I did it. > > This is not a good approach - you introduced platform-specific code into > main Katello code base. > >>>> * patch is optional, can be turned on/off by ENV variable or by options >>>> * (I am also considering to add optional check that all production >>>> gems are installed as rpms) >>>> >>>> Deployment is unaffected, all dependencies are satisfied by rpm-gems. >>>> >>>> When you run bundle install to get development environment on any >>>> rpm-based machine, all your rpms have priority and they are used. All >>>> missing development gems are installed from our gem-repo. >>> I think this is the crux of the issue. Once we have a custom gem >>> repository, the above step has very little practical value. A ruby gem >>> is a ruby gem no matter what place in the system it's installed in. >> >> IMO This has a big practical value. When you are fixing a bug you want >> to be sure that you have same rpm-gems installed and required as in >> production where the bug was discovered. > > Do you understand how ruby loads gem dependencies? Can you explain the > difference between rpm-installed gem, and bundler-installed gem (for > system-wide installs)? > Yeah, I understand, We just don't understand each other :) How is this relevant to what I said before? I would like to give you an answer but I don't see the connection, please explain where are you heading with this. > -d > >> >> >>>> >>>> On non-rpm-based machine, 'bundle install' installs all gems >>>> production and development from our gem-repo. >>>> >>>> == Gem Repository >>>> >>>> Bundler patch will work only if all development and production gems >>>> are in the gem-repo. To get it fixed quickly 'bundle package' can be >>>> used to get all the gems. Missing gems can be then uploaded to >>>> katello-thirdparty (source for our gem-repo) >>>> >>>> = Summary >>>> >>>> I think that Bundler patch and updating gem-repo to contain all gems >>>> is the only one which can be done fast and will work on any machine in >>>> deployment and development. I tried to be thorough but if I missed >>>> something or if you have better ideas please let me know. >>> The issue with dependency version variability needs solving. The patch >>> itself has little practical value, bundle install from custom repository >>> is sufficient. The irony is that you are trying to solve the problem >>> Bundler has successfully solved awhile ago. I'm baffled as to why we >>> continue to insist on solving the problems the "katello" way. >>> >>> -d >>> >>>> >>>> Petr >>>> >>>> [1] >>>> https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 >>>> >>>> >>>> [2] https://github.com/aeolus-incubator/bundler_ext >>>> >>>> _______________________________________________ >>>> 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 >> >> [1] https://github.com/Katello/katello/pull/526 > > From dmitri at redhat.com Tue Aug 28 11:24:55 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 28 Aug 2012 12:24:55 +0100 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <503CA7EC.6060209@redhat.com> References: <50361A76.2070003@redhat.com> <5036251A.3050401@redhat.com> <503C715E.3060207@redhat.com> <503C8AA9.5050108@redhat.com> <503CA7EC.6060209@redhat.com> Message-ID: <503CAA87.8040708@redhat.com> On 28/08/12 12:13 PM, Petr Chalupa wrote: > > > On 28.08.12 11:08, Dmitri Dolguikh wrote: >> On 28/08/12 08:21 AM, Petr Chalupa wrote: >>> >>> >>> On 23.08.12 14:42, Dmitri Dolguikh wrote: >>>> On 23/08/12 12:56 PM, Petr Chalupa wrote: >>>>> My original email raised a lot of questions, I should wrote it with >>>>> more details. I apology for that. I'll try again and elaborate. >>>>> >>>>> = Goals >>>>> >>>>> 1) To be able to implement the solution in a week or so. >>>>> 2) Not to affect deployment, keep it same way as now. >>>>> 3) When you are installing development environment on any rpm-based >>>>> system rpm-gems are used even if they are older then gems in our >>>>> gem-repo. (this is borken right now) >>>>> 4) When you are installing development environment in any >>>>> non-rpm-base >>>>> system you get installed gems as close as possible to what would you >>>>> get on fedora 16. (you cannot install with bundle install only right >>>>> now) >>>>> * (optionally including the security patches, lets discuss this >>>>> later) >>>>> >>>>> = What was discussed, why I think it wont work >>>>> >>>>> == Branch for each platform >>>>> >>>>> * There would be little difference between the branches (only Gemfile >>>>> or Gemfile.lock). Rest of the code will be same. >>>>> * It would be too much work to maintain it. >>>>> >>>>> == Gemfile.lock per platform and environment >>>>> >>>>> * We would have to have 8 Gemfile.locks and maintain them all (4 >>>>> platforms multiplied by two environments) >>>>> * Too much work unless its automated. >>>>> * Automation would take time to setup. >>>>> >>>>> == Aeolus solution, bundler_ext [2] >>>>> >>>>> * Dependencies resolution is unaffected so 'bundle install' cannot be >>>>> used to install development dependencies, it would ignore rpm-gems >>>>> and >>>>> install gems from gem-repo. >>>>> * If bundler_ext is used for setup development environment, control >>>>> over which versions are required is lost (requiring is not done by >>>>> bundler) >>>>> * It affects only how requirements are loaded [1], it's useful only >>>>> for deployment. >>>>> * (We could use it in deployment to get rid of bundler, but that is >>>>> out of this discussion's scope see Goal.2) >>>>> >>>>> == bundle install --without default >>>>> >>>>> This installs only development gems, but: >>>>> >>>>> * If some of the development gems has a production gem as dependency >>>>> (eg. ActiveSupport), the gem is reinstalled by bundler from a >>>>> gem-repo >>>>> over the older rpm-gem. >>>>> * If only development gems are installed, bundler cannot be used to >>>>> require gems. It will raise LoadError because from bundler's point of >>>>> view production gems are not installed. >>>>> * It would have to be combined with bundler_ext to find production >>>>> rpm-gems, so you would loose control over which version are loaded >>>>> again >>>>> * If you forget to add '--without default' when you run 'bundle >>>>> install' unwanted versions are installed. >>>>> >>>>> == vendor/cache >>>>> >>>>> Move all gems to src/vendor/cache (directly into katello/master or as >>>>> a git sub-module) and remove sources form Gemfile completely. 'bundle >>>>> install' installs gems form vendor/cache automatically if there >>>>> are no >>>>> sources in Gemfile. >>>>> >>>>> * to have .gem files directly in katello/master is ugly >>>>> * submodules are real pain >>>> no need to use sub-modules >>>>> * git is not that good with binary data >>>>> >>>> gems are mostly ruby, very not a lot of binary data. >>> >>> gems would be stored in vendor/cache as .gem files, one file per gem >>> which are actually tar.gz (binary). That is what I meant sorry about >>> the confusion. >>> >>>>> = My proposal >>>>> >>>>> == Bundler patch >>>>> >>>>> * it would be loaded in Gemfile, so every tool using bundler will >>>>> get it >>>> I don't think a single Gemfile is going to solve the issue: we'll need >>>> to relax version constraints in Gemfile, and add a bunch of >>>> ruby-version >>>> specific gems... >>>>> >>>>> * it would ensure that if rpm-gem is present it's used even if there >>>>> is newer version available in gem-repo >>>>> * ensure that locally installed gems are not confused with rpm-gems >>>> You didn't explain how you are planning to differentiate between >>>> the two >>>> - system-wide bundler-/ruby-gem-installed gems and rpm-installed >>>> gems... >>> >>> I don't think this is a problem, see [1] how I did it. >> >> This is not a good approach - you introduced platform-specific code into >> main Katello code base. >> >>>>> * patch is optional, can be turned on/off by ENV variable or by >>>>> options >>>>> * (I am also considering to add optional check that all production >>>>> gems are installed as rpms) >>>>> >>>>> Deployment is unaffected, all dependencies are satisfied by rpm-gems. >>>>> >>>>> When you run bundle install to get development environment on any >>>>> rpm-based machine, all your rpms have priority and they are used. All >>>>> missing development gems are installed from our gem-repo. >>>> I think this is the crux of the issue. Once we have a custom gem >>>> repository, the above step has very little practical value. A ruby gem >>>> is a ruby gem no matter what place in the system it's installed in. >>> >>> IMO This has a big practical value. When you are fixing a bug you want >>> to be sure that you have same rpm-gems installed and required as in >>> production where the bug was discovered. >> >> Do you understand how ruby loads gem dependencies? Can you explain the >> difference between rpm-installed gem, and bundler-installed gem (for >> system-wide installs)? >> > > Yeah, I understand, We just don't understand each other :) How is this > relevant to what I said before? I would like to give you an answer but > I don't see the connection, please explain where are you heading with > this. Ultimately, one way, or another, we are solving the problem of loading gem dependencies. I'd like you to demonstrate the difference between loading of a regular ruby gem and rpm-installed ruby gem by ruby interpreter. > >> -d >> >>> >>> >>>>> >>>>> On non-rpm-based machine, 'bundle install' installs all gems >>>>> production and development from our gem-repo. >>>>> >>>>> == Gem Repository >>>>> >>>>> Bundler patch will work only if all development and production gems >>>>> are in the gem-repo. To get it fixed quickly 'bundle package' can be >>>>> used to get all the gems. Missing gems can be then uploaded to >>>>> katello-thirdparty (source for our gem-repo) >>>>> >>>>> = Summary >>>>> >>>>> I think that Bundler patch and updating gem-repo to contain all gems >>>>> is the only one which can be done fast and will work on any >>>>> machine in >>>>> deployment and development. I tried to be thorough but if I missed >>>>> something or if you have better ideas please let me know. >>>> The issue with dependency version variability needs solving. The patch >>>> itself has little practical value, bundle install from custom >>>> repository >>>> is sufficient. The irony is that you are trying to solve the problem >>>> Bundler has successfully solved awhile ago. I'm baffled as to why we >>>> continue to insist on solving the problems the "katello" way. >>>> >>>> -d >>>> >>>>> >>>>> Petr >>>>> >>>>> [1] >>>>> https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 >>>>> >>>>> >>>>> >>>>> [2] https://github.com/aeolus-incubator/bundler_ext >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> [1] https://github.com/Katello/katello/pull/526 >> >> From pchalupa at redhat.com Tue Aug 28 11:47:46 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 28 Aug 2012 13:47:46 +0200 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <503CAA87.8040708@redhat.com> References: <50361A76.2070003@redhat.com> <5036251A.3050401@redhat.com> <503C715E.3060207@redhat.com> <503C8AA9.5050108@redhat.com> <503CA7EC.6060209@redhat.com> <503CAA87.8040708@redhat.com> Message-ID: <503CAFE2.6080209@redhat.com> On Tue Aug 28 13:24:55 2012, Dmitri Dolguikh wrote: > On 28/08/12 12:13 PM, Petr Chalupa wrote: >> >> >> On 28.08.12 11:08, Dmitri Dolguikh wrote: >>> On 28/08/12 08:21 AM, Petr Chalupa wrote: >>>> >>>> >>>> On 23.08.12 14:42, Dmitri Dolguikh wrote: >>>>> On 23/08/12 12:56 PM, Petr Chalupa wrote: >>>>>> My original email raised a lot of questions, I should wrote it with >>>>>> more details. I apology for that. I'll try again and elaborate. >>>>>> >>>>>> = Goals >>>>>> >>>>>> 1) To be able to implement the solution in a week or so. >>>>>> 2) Not to affect deployment, keep it same way as now. >>>>>> 3) When you are installing development environment on any rpm-based >>>>>> system rpm-gems are used even if they are older then gems in our >>>>>> gem-repo. (this is borken right now) >>>>>> 4) When you are installing development environment in any >>>>>> non-rpm-base >>>>>> system you get installed gems as close as possible to what would you >>>>>> get on fedora 16. (you cannot install with bundle install only right >>>>>> now) >>>>>> * (optionally including the security patches, lets discuss this >>>>>> later) >>>>>> >>>>>> = What was discussed, why I think it wont work >>>>>> >>>>>> == Branch for each platform >>>>>> >>>>>> * There would be little difference between the branches (only >>>>>> Gemfile >>>>>> or Gemfile.lock). Rest of the code will be same. >>>>>> * It would be too much work to maintain it. >>>>>> >>>>>> == Gemfile.lock per platform and environment >>>>>> >>>>>> * We would have to have 8 Gemfile.locks and maintain them all (4 >>>>>> platforms multiplied by two environments) >>>>>> * Too much work unless its automated. >>>>>> * Automation would take time to setup. >>>>>> >>>>>> == Aeolus solution, bundler_ext [2] >>>>>> >>>>>> * Dependencies resolution is unaffected so 'bundle install' >>>>>> cannot be >>>>>> used to install development dependencies, it would ignore >>>>>> rpm-gems and >>>>>> install gems from gem-repo. >>>>>> * If bundler_ext is used for setup development environment, control >>>>>> over which versions are required is lost (requiring is not done by >>>>>> bundler) >>>>>> * It affects only how requirements are loaded [1], it's useful only >>>>>> for deployment. >>>>>> * (We could use it in deployment to get rid of bundler, but that is >>>>>> out of this discussion's scope see Goal.2) >>>>>> >>>>>> == bundle install --without default >>>>>> >>>>>> This installs only development gems, but: >>>>>> >>>>>> * If some of the development gems has a production gem as dependency >>>>>> (eg. ActiveSupport), the gem is reinstalled by bundler from a >>>>>> gem-repo >>>>>> over the older rpm-gem. >>>>>> * If only development gems are installed, bundler cannot be used to >>>>>> require gems. It will raise LoadError because from bundler's >>>>>> point of >>>>>> view production gems are not installed. >>>>>> * It would have to be combined with bundler_ext to find production >>>>>> rpm-gems, so you would loose control over which version are loaded >>>>>> again >>>>>> * If you forget to add '--without default' when you run 'bundle >>>>>> install' unwanted versions are installed. >>>>>> >>>>>> == vendor/cache >>>>>> >>>>>> Move all gems to src/vendor/cache (directly into katello/master >>>>>> or as >>>>>> a git sub-module) and remove sources form Gemfile completely. >>>>>> 'bundle >>>>>> install' installs gems form vendor/cache automatically if there >>>>>> are no >>>>>> sources in Gemfile. >>>>>> >>>>>> * to have .gem files directly in katello/master is ugly >>>>>> * submodules are real pain >>>>> no need to use sub-modules >>>>>> * git is not that good with binary data >>>>>> >>>>> gems are mostly ruby, very not a lot of binary data. >>>> >>>> gems would be stored in vendor/cache as .gem files, one file per gem >>>> which are actually tar.gz (binary). That is what I meant sorry about >>>> the confusion. >>>> >>>>>> = My proposal >>>>>> >>>>>> == Bundler patch >>>>>> >>>>>> * it would be loaded in Gemfile, so every tool using bundler will >>>>>> get it >>>>> I don't think a single Gemfile is going to solve the issue: we'll >>>>> need >>>>> to relax version constraints in Gemfile, and add a bunch of >>>>> ruby-version >>>>> specific gems... >>>>>> >>>>>> * it would ensure that if rpm-gem is present it's used even if there >>>>>> is newer version available in gem-repo >>>>>> * ensure that locally installed gems are not confused with rpm-gems >>>>> You didn't explain how you are planning to differentiate between >>>>> the two >>>>> - system-wide bundler-/ruby-gem-installed gems and rpm-installed >>>>> gems... >>>> >>>> I don't think this is a problem, see [1] how I did it. >>> >>> This is not a good approach - you introduced platform-specific code >>> into >>> main Katello code base. >>> >>>>>> * patch is optional, can be turned on/off by ENV variable or by >>>>>> options >>>>>> * (I am also considering to add optional check that all production >>>>>> gems are installed as rpms) >>>>>> >>>>>> Deployment is unaffected, all dependencies are satisfied by >>>>>> rpm-gems. >>>>>> >>>>>> When you run bundle install to get development environment on any >>>>>> rpm-based machine, all your rpms have priority and they are used. >>>>>> All >>>>>> missing development gems are installed from our gem-repo. >>>>> I think this is the crux of the issue. Once we have a custom gem >>>>> repository, the above step has very little practical value. A ruby >>>>> gem >>>>> is a ruby gem no matter what place in the system it's installed in. >>>> >>>> IMO This has a big practical value. When you are fixing a bug you want >>>> to be sure that you have same rpm-gems installed and required as in >>>> production where the bug was discovered. >>> >>> Do you understand how ruby loads gem dependencies? Can you explain the >>> difference between rpm-installed gem, and bundler-installed gem (for >>> system-wide installs)? >>> >> >> Yeah, I understand, We just don't understand each other :) How is >> this relevant to what I said before? I would like to give you an >> answer but I don't see the connection, please explain where are you >> heading with this. > > Ultimately, one way, or another, we are solving the problem of loading > gem dependencies. I'd like you to demonstrate the difference between > loading of a regular ruby gem and rpm-installed ruby gem by ruby > interpreter. > The patch I introduced does not affect how gems are required. It changes how bundler prioritizes gem matching against dependencies. Rpm-gems are moved to the top in the queue of gem candidates for the dependency matching. So rpm-gems are matched/picked before other gems. Rpm-gems are matched/picked even if there is newer version in gem-repo. To answer you question, plain ruby process requires newest available version of a given gem, regular or rpm-installed. There is no difference for Ruby. This is unchanged by the patch. Ruby process using Bundler (with or without the patch) to require gems will require gems in versions as they are specified in Gemfile.lock, regular or rpm-installed. This is also unchanged by the patch. The ruby requiring algorithm with or without bundler is unchanged by the patch. What gems are in Gemfile.lock is resolved when `bundle install` is run. What gems are resolved and picked to Gemfile.lock is altered by the patch. Does this help to answer your question? Petr > >> >>> -d >>> >>>> >>>> >>>>>> >>>>>> On non-rpm-based machine, 'bundle install' installs all gems >>>>>> production and development from our gem-repo. >>>>>> >>>>>> == Gem Repository >>>>>> >>>>>> Bundler patch will work only if all development and production gems >>>>>> are in the gem-repo. To get it fixed quickly 'bundle package' can be >>>>>> used to get all the gems. Missing gems can be then uploaded to >>>>>> katello-thirdparty (source for our gem-repo) >>>>>> >>>>>> = Summary >>>>>> >>>>>> I think that Bundler patch and updating gem-repo to contain all gems >>>>>> is the only one which can be done fast and will work on any >>>>>> machine in >>>>>> deployment and development. I tried to be thorough but if I missed >>>>>> something or if you have better ideas please let me know. >>>>> The issue with dependency version variability needs solving. The >>>>> patch >>>>> itself has little practical value, bundle install from custom >>>>> repository >>>>> is sufficient. The irony is that you are trying to solve the problem >>>>> Bundler has successfully solved awhile ago. I'm baffled as to why we >>>>> continue to insist on solving the problems the "katello" way. >>>>> >>>>> -d >>>>> >>>>>> >>>>>> Petr >>>>>> >>>>>> [1] >>>>>> https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 >>>>>> >>>>>> >>>>>> >>>>>> [2] https://github.com/aeolus-incubator/bundler_ext >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> [1] https://github.com/Katello/katello/pull/526 >>> >>> > > From dmitri at redhat.com Tue Aug 28 11:53:16 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 28 Aug 2012 12:53:16 +0100 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <503CAFE2.6080209@redhat.com> References: <50361A76.2070003@redhat.com> <5036251A.3050401@redhat.com> <503C715E.3060207@redhat.com> <503C8AA9.5050108@redhat.com> <503CA7EC.6060209@redhat.com> <503CAA87.8040708@redhat.com> <503CAFE2.6080209@redhat.com> Message-ID: <503CB12C.1070207@redhat.com> On 28/08/12 12:47 PM, Petr Chalupa wrote: > > > On Tue Aug 28 13:24:55 2012, Dmitri Dolguikh wrote: >> On 28/08/12 12:13 PM, Petr Chalupa wrote: >>> >>> >>> On 28.08.12 11:08, Dmitri Dolguikh wrote: >>>> On 28/08/12 08:21 AM, Petr Chalupa wrote: >>>>> >>>>> >>>>> On 23.08.12 14:42, Dmitri Dolguikh wrote: >>>>>> On 23/08/12 12:56 PM, Petr Chalupa wrote: >>>>>>> My original email raised a lot of questions, I should wrote it with >>>>>>> more details. I apology for that. I'll try again and elaborate. >>>>>>> >>>>>>> = Goals >>>>>>> >>>>>>> 1) To be able to implement the solution in a week or so. >>>>>>> 2) Not to affect deployment, keep it same way as now. >>>>>>> 3) When you are installing development environment on any rpm-based >>>>>>> system rpm-gems are used even if they are older then gems in our >>>>>>> gem-repo. (this is borken right now) >>>>>>> 4) When you are installing development environment in any >>>>>>> non-rpm-base >>>>>>> system you get installed gems as close as possible to what would >>>>>>> you >>>>>>> get on fedora 16. (you cannot install with bundle install only >>>>>>> right >>>>>>> now) >>>>>>> * (optionally including the security patches, lets discuss this >>>>>>> later) >>>>>>> >>>>>>> = What was discussed, why I think it wont work >>>>>>> >>>>>>> == Branch for each platform >>>>>>> >>>>>>> * There would be little difference between the branches (only >>>>>>> Gemfile >>>>>>> or Gemfile.lock). Rest of the code will be same. >>>>>>> * It would be too much work to maintain it. >>>>>>> >>>>>>> == Gemfile.lock per platform and environment >>>>>>> >>>>>>> * We would have to have 8 Gemfile.locks and maintain them all (4 >>>>>>> platforms multiplied by two environments) >>>>>>> * Too much work unless its automated. >>>>>>> * Automation would take time to setup. >>>>>>> >>>>>>> == Aeolus solution, bundler_ext [2] >>>>>>> >>>>>>> * Dependencies resolution is unaffected so 'bundle install' >>>>>>> cannot be >>>>>>> used to install development dependencies, it would ignore >>>>>>> rpm-gems and >>>>>>> install gems from gem-repo. >>>>>>> * If bundler_ext is used for setup development environment, control >>>>>>> over which versions are required is lost (requiring is not done by >>>>>>> bundler) >>>>>>> * It affects only how requirements are loaded [1], it's useful only >>>>>>> for deployment. >>>>>>> * (We could use it in deployment to get rid of bundler, but that is >>>>>>> out of this discussion's scope see Goal.2) >>>>>>> >>>>>>> == bundle install --without default >>>>>>> >>>>>>> This installs only development gems, but: >>>>>>> >>>>>>> * If some of the development gems has a production gem as >>>>>>> dependency >>>>>>> (eg. ActiveSupport), the gem is reinstalled by bundler from a >>>>>>> gem-repo >>>>>>> over the older rpm-gem. >>>>>>> * If only development gems are installed, bundler cannot be used to >>>>>>> require gems. It will raise LoadError because from bundler's >>>>>>> point of >>>>>>> view production gems are not installed. >>>>>>> * It would have to be combined with bundler_ext to find production >>>>>>> rpm-gems, so you would loose control over which version are loaded >>>>>>> again >>>>>>> * If you forget to add '--without default' when you run 'bundle >>>>>>> install' unwanted versions are installed. >>>>>>> >>>>>>> == vendor/cache >>>>>>> >>>>>>> Move all gems to src/vendor/cache (directly into katello/master >>>>>>> or as >>>>>>> a git sub-module) and remove sources form Gemfile completely. >>>>>>> 'bundle >>>>>>> install' installs gems form vendor/cache automatically if there >>>>>>> are no >>>>>>> sources in Gemfile. >>>>>>> >>>>>>> * to have .gem files directly in katello/master is ugly >>>>>>> * submodules are real pain >>>>>> no need to use sub-modules >>>>>>> * git is not that good with binary data >>>>>>> >>>>>> gems are mostly ruby, very not a lot of binary data. >>>>> >>>>> gems would be stored in vendor/cache as .gem files, one file per gem >>>>> which are actually tar.gz (binary). That is what I meant sorry about >>>>> the confusion. >>>>> >>>>>>> = My proposal >>>>>>> >>>>>>> == Bundler patch >>>>>>> >>>>>>> * it would be loaded in Gemfile, so every tool using bundler will >>>>>>> get it >>>>>> I don't think a single Gemfile is going to solve the issue: we'll >>>>>> need >>>>>> to relax version constraints in Gemfile, and add a bunch of >>>>>> ruby-version >>>>>> specific gems... >>>>>>> >>>>>>> * it would ensure that if rpm-gem is present it's used even if >>>>>>> there >>>>>>> is newer version available in gem-repo >>>>>>> * ensure that locally installed gems are not confused with rpm-gems >>>>>> You didn't explain how you are planning to differentiate between >>>>>> the two >>>>>> - system-wide bundler-/ruby-gem-installed gems and rpm-installed >>>>>> gems... >>>>> >>>>> I don't think this is a problem, see [1] how I did it. >>>> >>>> This is not a good approach - you introduced platform-specific code >>>> into >>>> main Katello code base. >>>> >>>>>>> * patch is optional, can be turned on/off by ENV variable or by >>>>>>> options >>>>>>> * (I am also considering to add optional check that all production >>>>>>> gems are installed as rpms) >>>>>>> >>>>>>> Deployment is unaffected, all dependencies are satisfied by >>>>>>> rpm-gems. >>>>>>> >>>>>>> When you run bundle install to get development environment on any >>>>>>> rpm-based machine, all your rpms have priority and they are used. >>>>>>> All >>>>>>> missing development gems are installed from our gem-repo. >>>>>> I think this is the crux of the issue. Once we have a custom gem >>>>>> repository, the above step has very little practical value. A ruby >>>>>> gem >>>>>> is a ruby gem no matter what place in the system it's installed in. >>>>> >>>>> IMO This has a big practical value. When you are fixing a bug you >>>>> want >>>>> to be sure that you have same rpm-gems installed and required as in >>>>> production where the bug was discovered. >>>> >>>> Do you understand how ruby loads gem dependencies? Can you explain the >>>> difference between rpm-installed gem, and bundler-installed gem (for >>>> system-wide installs)? >>>> >>> >>> Yeah, I understand, We just don't understand each other :) How is >>> this relevant to what I said before? I would like to give you an >>> answer but I don't see the connection, please explain where are you >>> heading with this. >> >> Ultimately, one way, or another, we are solving the problem of loading >> gem dependencies. I'd like you to demonstrate the difference between >> loading of a regular ruby gem and rpm-installed ruby gem by ruby >> interpreter. >> > > The patch I introduced does not affect how gems are required. It > changes how bundler prioritizes gem matching against dependencies. > Rpm-gems are moved to the top in the queue of gem candidates for the > dependency matching. So rpm-gems are matched/picked before other gems. > Rpm-gems are matched/picked even if there is newer version in gem-repo. > > To answer you question, plain ruby process requires newest available > version of a given gem, regular or rpm-installed. There is no > difference for Ruby. This is unchanged by the patch. > > Ruby process using Bundler (with or without the patch) to require gems > will require gems in versions as they are specified in Gemfile.lock, > regular or rpm-installed. This is also unchanged by the patch. > > The ruby requiring algorithm with or without bundler is unchanged by > the patch. > > What gems are in Gemfile.lock is resolved when `bundle install` is > run. What gems are resolved and picked to Gemfile.lock is altered by > the patch. > > Does this help to answer your question? It does, thank you. You have shown there's no difference between loading gems from either of the sources. What benefits does your patch provide over bundler using have platform-specific repository[ies]? -d > > Petr > >> >>> >>>> -d >>>> >>>>> >>>>> >>>>>>> >>>>>>> On non-rpm-based machine, 'bundle install' installs all gems >>>>>>> production and development from our gem-repo. >>>>>>> >>>>>>> == Gem Repository >>>>>>> >>>>>>> Bundler patch will work only if all development and production gems >>>>>>> are in the gem-repo. To get it fixed quickly 'bundle package' >>>>>>> can be >>>>>>> used to get all the gems. Missing gems can be then uploaded to >>>>>>> katello-thirdparty (source for our gem-repo) >>>>>>> >>>>>>> = Summary >>>>>>> >>>>>>> I think that Bundler patch and updating gem-repo to contain all >>>>>>> gems >>>>>>> is the only one which can be done fast and will work on any >>>>>>> machine in >>>>>>> deployment and development. I tried to be thorough but if I missed >>>>>>> something or if you have better ideas please let me know. >>>>>> The issue with dependency version variability needs solving. The >>>>>> patch >>>>>> itself has little practical value, bundle install from custom >>>>>> repository >>>>>> is sufficient. The irony is that you are trying to solve the problem >>>>>> Bundler has successfully solved awhile ago. I'm baffled as to why we >>>>>> continue to insist on solving the problems the "katello" way. >>>>>> >>>>>> -d >>>>>> >>>>>>> >>>>>>> Petr >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> [2] https://github.com/aeolus-incubator/bundler_ext >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> [1] https://github.com/Katello/katello/pull/526 >>>> >>>> >> >> From pchalupa at redhat.com Tue Aug 28 12:04:27 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 28 Aug 2012 14:04:27 +0200 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <503CB12C.1070207@redhat.com> References: <50361A76.2070003@redhat.com> <5036251A.3050401@redhat.com> <503C715E.3060207@redhat.com> <503C8AA9.5050108@redhat.com> <503CA7EC.6060209@redhat.com> <503CAA87.8040708@redhat.com> <503CAFE2.6080209@redhat.com> <503CB12C.1070207@redhat.com> Message-ID: <503CB3CB.1060009@redhat.com> On 28.08.12 13:53, Dmitri Dolguikh wrote: > On 28/08/12 12:47 PM, Petr Chalupa wrote: >> >> >> On Tue Aug 28 13:24:55 2012, Dmitri Dolguikh wrote: >>> On 28/08/12 12:13 PM, Petr Chalupa wrote: >>>> >>>> >>>> On 28.08.12 11:08, Dmitri Dolguikh wrote: >>>>> On 28/08/12 08:21 AM, Petr Chalupa wrote: >>>>>> >>>>>> >>>>>> On 23.08.12 14:42, Dmitri Dolguikh wrote: >>>>>>> On 23/08/12 12:56 PM, Petr Chalupa wrote: >>>>>>>> My original email raised a lot of questions, I should wrote it with >>>>>>>> more details. I apology for that. I'll try again and elaborate. >>>>>>>> >>>>>>>> = Goals >>>>>>>> >>>>>>>> 1) To be able to implement the solution in a week or so. >>>>>>>> 2) Not to affect deployment, keep it same way as now. >>>>>>>> 3) When you are installing development environment on any rpm-based >>>>>>>> system rpm-gems are used even if they are older then gems in our >>>>>>>> gem-repo. (this is borken right now) >>>>>>>> 4) When you are installing development environment in any >>>>>>>> non-rpm-base >>>>>>>> system you get installed gems as close as possible to what would >>>>>>>> you >>>>>>>> get on fedora 16. (you cannot install with bundle install only >>>>>>>> right >>>>>>>> now) >>>>>>>> * (optionally including the security patches, lets discuss this >>>>>>>> later) >>>>>>>> >>>>>>>> = What was discussed, why I think it wont work >>>>>>>> >>>>>>>> == Branch for each platform >>>>>>>> >>>>>>>> * There would be little difference between the branches (only >>>>>>>> Gemfile >>>>>>>> or Gemfile.lock). Rest of the code will be same. >>>>>>>> * It would be too much work to maintain it. >>>>>>>> >>>>>>>> == Gemfile.lock per platform and environment >>>>>>>> >>>>>>>> * We would have to have 8 Gemfile.locks and maintain them all (4 >>>>>>>> platforms multiplied by two environments) >>>>>>>> * Too much work unless its automated. >>>>>>>> * Automation would take time to setup. >>>>>>>> >>>>>>>> == Aeolus solution, bundler_ext [2] >>>>>>>> >>>>>>>> * Dependencies resolution is unaffected so 'bundle install' >>>>>>>> cannot be >>>>>>>> used to install development dependencies, it would ignore >>>>>>>> rpm-gems and >>>>>>>> install gems from gem-repo. >>>>>>>> * If bundler_ext is used for setup development environment, control >>>>>>>> over which versions are required is lost (requiring is not done by >>>>>>>> bundler) >>>>>>>> * It affects only how requirements are loaded [1], it's useful only >>>>>>>> for deployment. >>>>>>>> * (We could use it in deployment to get rid of bundler, but that is >>>>>>>> out of this discussion's scope see Goal.2) >>>>>>>> >>>>>>>> == bundle install --without default >>>>>>>> >>>>>>>> This installs only development gems, but: >>>>>>>> >>>>>>>> * If some of the development gems has a production gem as >>>>>>>> dependency >>>>>>>> (eg. ActiveSupport), the gem is reinstalled by bundler from a >>>>>>>> gem-repo >>>>>>>> over the older rpm-gem. >>>>>>>> * If only development gems are installed, bundler cannot be used to >>>>>>>> require gems. It will raise LoadError because from bundler's >>>>>>>> point of >>>>>>>> view production gems are not installed. >>>>>>>> * It would have to be combined with bundler_ext to find production >>>>>>>> rpm-gems, so you would loose control over which version are loaded >>>>>>>> again >>>>>>>> * If you forget to add '--without default' when you run 'bundle >>>>>>>> install' unwanted versions are installed. >>>>>>>> >>>>>>>> == vendor/cache >>>>>>>> >>>>>>>> Move all gems to src/vendor/cache (directly into katello/master >>>>>>>> or as >>>>>>>> a git sub-module) and remove sources form Gemfile completely. >>>>>>>> 'bundle >>>>>>>> install' installs gems form vendor/cache automatically if there >>>>>>>> are no >>>>>>>> sources in Gemfile. >>>>>>>> >>>>>>>> * to have .gem files directly in katello/master is ugly >>>>>>>> * submodules are real pain >>>>>>> no need to use sub-modules >>>>>>>> * git is not that good with binary data >>>>>>>> >>>>>>> gems are mostly ruby, very not a lot of binary data. >>>>>> >>>>>> gems would be stored in vendor/cache as .gem files, one file per gem >>>>>> which are actually tar.gz (binary). That is what I meant sorry about >>>>>> the confusion. >>>>>> >>>>>>>> = My proposal >>>>>>>> >>>>>>>> == Bundler patch >>>>>>>> >>>>>>>> * it would be loaded in Gemfile, so every tool using bundler will >>>>>>>> get it >>>>>>> I don't think a single Gemfile is going to solve the issue: we'll >>>>>>> need >>>>>>> to relax version constraints in Gemfile, and add a bunch of >>>>>>> ruby-version >>>>>>> specific gems... >>>>>>>> >>>>>>>> * it would ensure that if rpm-gem is present it's used even if >>>>>>>> there >>>>>>>> is newer version available in gem-repo >>>>>>>> * ensure that locally installed gems are not confused with rpm-gems >>>>>>> You didn't explain how you are planning to differentiate between >>>>>>> the two >>>>>>> - system-wide bundler-/ruby-gem-installed gems and rpm-installed >>>>>>> gems... >>>>>> >>>>>> I don't think this is a problem, see [1] how I did it. >>>>> >>>>> This is not a good approach - you introduced platform-specific code >>>>> into >>>>> main Katello code base. >>>>> >>>>>>>> * patch is optional, can be turned on/off by ENV variable or by >>>>>>>> options >>>>>>>> * (I am also considering to add optional check that all production >>>>>>>> gems are installed as rpms) >>>>>>>> >>>>>>>> Deployment is unaffected, all dependencies are satisfied by >>>>>>>> rpm-gems. >>>>>>>> >>>>>>>> When you run bundle install to get development environment on any >>>>>>>> rpm-based machine, all your rpms have priority and they are used. >>>>>>>> All >>>>>>>> missing development gems are installed from our gem-repo. >>>>>>> I think this is the crux of the issue. Once we have a custom gem >>>>>>> repository, the above step has very little practical value. A ruby >>>>>>> gem >>>>>>> is a ruby gem no matter what place in the system it's installed in. >>>>>> >>>>>> IMO This has a big practical value. When you are fixing a bug you >>>>>> want >>>>>> to be sure that you have same rpm-gems installed and required as in >>>>>> production where the bug was discovered. >>>>> >>>>> Do you understand how ruby loads gem dependencies? Can you explain the >>>>> difference between rpm-installed gem, and bundler-installed gem (for >>>>> system-wide installs)? >>>>> >>>> >>>> Yeah, I understand, We just don't understand each other :) How is >>>> this relevant to what I said before? I would like to give you an >>>> answer but I don't see the connection, please explain where are you >>>> heading with this. >>> >>> Ultimately, one way, or another, we are solving the problem of loading >>> gem dependencies. I'd like you to demonstrate the difference between >>> loading of a regular ruby gem and rpm-installed ruby gem by ruby >>> interpreter. >>> >> >> The patch I introduced does not affect how gems are required. It >> changes how bundler prioritizes gem matching against dependencies. >> Rpm-gems are moved to the top in the queue of gem candidates for the >> dependency matching. So rpm-gems are matched/picked before other gems. >> Rpm-gems are matched/picked even if there is newer version in gem-repo. >> >> To answer you question, plain ruby process requires newest available >> version of a given gem, regular or rpm-installed. There is no >> difference for Ruby. This is unchanged by the patch. >> >> Ruby process using Bundler (with or without the patch) to require gems >> will require gems in versions as they are specified in Gemfile.lock, >> regular or rpm-installed. This is also unchanged by the patch. >> >> The ruby requiring algorithm with or without bundler is unchanged by >> the patch. >> >> What gems are in Gemfile.lock is resolved when `bundle install` is >> run. What gems are resolved and picked to Gemfile.lock is altered by >> the patch. >> >> Does this help to answer your question? > It does, thank you. You have shown there's no difference between loading > gems from either of the sources. What benefits does your patch provide > over bundler using have platform-specific repository[ies]? > > -d You are able to install development dependencies on top of already installed rpm-gems (production dependencies) without overshadowing them with newer gems from gem-repo. Needed for RHEL and CentOS. On fedora 16 the rpm-gems have same versions as gems in our gem-repo. On non-rpm machine you get same versions as on fedora 16 because I also updated gem-repo with missing gems (this was not possible before). Petr >> >> Petr >> >>> >>>> >>>>> -d >>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>> On non-rpm-based machine, 'bundle install' installs all gems >>>>>>>> production and development from our gem-repo. >>>>>>>> >>>>>>>> == Gem Repository >>>>>>>> >>>>>>>> Bundler patch will work only if all development and production gems >>>>>>>> are in the gem-repo. To get it fixed quickly 'bundle package' >>>>>>>> can be >>>>>>>> used to get all the gems. Missing gems can be then uploaded to >>>>>>>> katello-thirdparty (source for our gem-repo) >>>>>>>> >>>>>>>> = Summary >>>>>>>> >>>>>>>> I think that Bundler patch and updating gem-repo to contain all >>>>>>>> gems >>>>>>>> is the only one which can be done fast and will work on any >>>>>>>> machine in >>>>>>>> deployment and development. I tried to be thorough but if I missed >>>>>>>> something or if you have better ideas please let me know. >>>>>>> The issue with dependency version variability needs solving. The >>>>>>> patch >>>>>>> itself has little practical value, bundle install from custom >>>>>>> repository >>>>>>> is sufficient. The irony is that you are trying to solve the problem >>>>>>> Bundler has successfully solved awhile ago. I'm baffled as to why we >>>>>>> continue to insist on solving the problems the "katello" way. >>>>>>> >>>>>>> -d >>>>>>> >>>>>>>> >>>>>>>> Petr >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [2] https://github.com/aeolus-incubator/bundler_ext >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> [1] https://github.com/Katello/katello/pull/526 >>>>> >>>>> >>> >>> > > From msuchy at redhat.com Tue Aug 28 12:10:03 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Tue, 28 Aug 2012 14:10:03 +0200 Subject: [katello-devel] Demotions and deletions In-Reply-To: <20120828102947.GB1383@lzapx.brq.redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> Message-ID: <503CB51B.9060002@redhat.com> On 08/28/2012 12:29 PM, Lukas Zapletal wrote: > Hey, > > stumbled upon a bug (https://bugzilla.redhat.com/show_bug.cgi?id=835875) > that prevents you from creating a repository with a same name that has > been deleted (but promoted). > > Now the question - we now do support demotions (those promotions > opposite - not sure about wording). Therefore I guess the proper > solution would be to check if the repository (*) was already promoted. > If so, Katello will refuse to delete the object asking user to do the > demotion. > > Opinions? +1 I was thinking for a while about offering to do demotion for them (with big exclamation mark). But if that would be easy, you can easily destroy your set up. So I would leave it to admin to do that by hand. -- Miroslav Suchy Red Hat Systems Management Engineering From calfonso at redhat.com Tue Aug 28 12:27:59 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Tue, 28 Aug 2012 08:27:59 -0400 Subject: [katello-devel] Foreman-api In-Reply-To: <503C8DE6.7050905@redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> <503B3D7F.6020102@redhat.com> <503C8DE6.7050905@redhat.com> Message-ID: <20120828122759.GA5270@dhcp-230-220.rdu.redhat.com> On 28/08/12 10:22 +0100, Dmitri Dolguikh wrote: >On 27/08/12 10:27 AM, Ivan Ne?as wrote: >>On 08/24/2012 04:58 PM, Dmitri Dolguikh wrote: >>>On 24/08/12 03:57 PM, Bryan Kearney wrote: >>>>On 08/24/2012 10:52 AM, Jason Rist wrote: >>>>>On 08/24/2012 10:50 AM, Dmitri Dolguikh wrote: [snip] >>[1] - https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb >>[2] - https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb > >I'd argue that the attribute filtration doesn't belong in [1]. Where does it belong? If the server rejects certain attributes, the client must not allow those attributes to be part of the request. The workflow is as follows..user makes a request to GET an object from the server, the returned object has all the attributes that describe the object. The user then updates one attribute and then saves the object. That save action is going to generate a PUT request, note: the object still has all the attributes that describe the object, but a subset of those attributes are not allowed on PUT requests. I don't think it's reasonable to have the user remove the attributes, so I remove them in the client api gem. The user then never has to worry about what attributes are allowed/disallowed. If the attribute removal doesn't belone in the client api gem, where does it belong? The only other option is to have the server ignore those attributes rather than return an error code. - Chris >[2] >has a lot of repetitive code, indeed that's the reason why you >generate it, and why I don't like it. It makes more sense for >non-standard methods, but index, show, update, create can either be >moved into some common mixin, or be generated similarly to accessor >generators. > >-d > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From dmitri at redhat.com Tue Aug 28 12:43:01 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 28 Aug 2012 13:43:01 +0100 Subject: [katello-devel] Foreman-api In-Reply-To: <20120828122759.GA5270@dhcp-230-220.rdu.redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> <503B3D7F.6020102@redhat.com> <503C8DE6.7050905@redhat.com> <20120828122759.GA5270@dhcp-230-220.rdu.redhat.com> Message-ID: <503CBCD5.4040401@redhat.com> On 28/08/12 01:27 PM, Chris Alfonso wrote: > On 28/08/12 10:22 +0100, Dmitri Dolguikh wrote: >> On 27/08/12 10:27 AM, Ivan Ne?as wrote: >>> On 08/24/2012 04:58 PM, Dmitri Dolguikh wrote: >>>> On 24/08/12 03:57 PM, Bryan Kearney wrote: >>>>> On 08/24/2012 10:52 AM, Jason Rist wrote: >>>>>> On 08/24/2012 10:50 AM, Dmitri Dolguikh wrote: > [snip] >>> [1] - >>> https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb >>> [2] - >>> https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb >> >> I'd argue that the attribute filtration doesn't belong in [1]. > Where does it belong? If the server rejects certain attributes, the > client > must not allow those attributes to be part of the request. The > workflow is > as follows..user makes a request to GET an object from the server, the > returned object has all the attributes that describe the object. The user > then updates one attribute and then saves the object. That save > action is > going to generate a PUT request, note: the object still has all the > attributes that describe the object, but a subset of those attributes > are not > allowed on PUT requests. I don't think it's reasonable to have the user > remove the attributes, so I remove them in the client api gem. The > user then > never has to worry about what attributes are allowed/disallowed. > > If the attribute removal doesn't belone in the client api gem, where > does it > belong? The only other option is to have the server ignore those > attributes > rather than return an error code. It certainly belongs on the client, there is no question about that in my mind. I'm not sure that silently dropping an attribute from the hash is a good approach though, as it may lead to a confusing situation when a developer attempts to update an attribute, sees a success, but the attribute hasn't been actually changed on the server. Haven't looked at how Aeolus/Conductor handles remote models though, perhaps this is appropriate there. Cheers, -d > > - Chris >> [2] has a lot of repetitive code, indeed that's the reason why you >> generate it, and why I don't like it. It makes more sense for >> non-standard methods, but index, show, update, create can either be >> moved into some common mixin, or be generated similarly to accessor >> generators. >> >> -d >> > From calfonso at redhat.com Tue Aug 28 12:54:33 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Tue, 28 Aug 2012 08:54:33 -0400 Subject: [katello-devel] Foreman-api In-Reply-To: <503C8F69.9030707@redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> <503B3D7F.6020102@redhat.com> <503B54E2.4090801@redhat.com> <20120827121526.GD6031@lzapx.brq.redhat.com> <503C8F69.9030707@redhat.com> Message-ID: <20120828125432.GB5270@dhcp-230-220.rdu.redhat.com> On 28/08/12 10:29 +0100, Dmitri Dolguikh wrote: >On 27/08/12 01:15 PM, Lukas Zapletal wrote: >>On Mon, Aug 27, 2012 at 01:07:14PM +0200, Miroslav Suchy wrote: >>>On 08/27/2012 11:27 AM, Ivan Ne?as wrote: >>>>Me as a developer, I find it much easier to use the code that I >>>>immediately see what it expects from me. >>>> >>>>[1] - >>>>https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb >>>> >>>>[2] - >>>>https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb >>>> >>>+1 >>>[2] is much more readable to me. >>+1 No more "dynamic" stuff please. > >I don't want to get into discussion about code generation. We are >developing within constraints and using conventions of REST and >Rails. We should only write code when we are dealing with something >that doesn't follow conventions, or extends them, instead of >repeating the obvious. > >-d It wasn't clear to me that some attributes were not allowed on an update until I read server logs in the traceback either. I'm going to add the disallowed attributes to the documentation for the client gem in this case. Perhaps I should override the update_attributes method to raise an exception if the developer tries to update a certain attribute. That might make more sense. -Chris > >> >>Plus your favourite IDE can OmniComplete :-) >> > > >_______________________________________________ >katello-devel mailing list >katello-devel at redhat.com >https://www.redhat.com/mailman/listinfo/katello-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From bbuckingham at redhat.com Tue Aug 28 12:56:23 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Tue, 28 Aug 2012 08:56:23 -0400 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503CB51B.9060002@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> Message-ID: <503CBFF7.9030500@redhat.com> On 08/28/2012 08:10 AM, Miroslav Such? wrote: > On 08/28/2012 12:29 PM, Lukas Zapletal wrote: >> Hey, >> >> stumbled upon a bug (https://bugzilla.redhat.com/show_bug.cgi?id=835875) >> that prevents you from creating a repository with a same name that has >> been deleted (but promoted). >> >> Now the question - we now do support demotions (those promotions >> opposite - not sure about wording). Therefore I guess the proper >> solution would be to check if the repository (*) was already promoted. >> If so, Katello will refuse to delete the object asking user to do the >> demotion. >> >> Opinions? > > +1 > I was thinking for a while about offering to do demotion for them > (with big exclamation mark). But if that would be easy, you can easily > destroy your set up. So I would leave it to admin to do that by hand. > > -- > Miroslav Suchy > Red Hat Systems Management Engineering > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Hi, The feature that was recently introduced in Katello is content deletion. It allows for deletion of content (which includes things such as products, repos, packages, errata, distributions and system templates) from any environment along the promotion path, except for the Library. It isn't really a demotion of content since it is possible to delete content from the an environment that is in the middle of the path (e.g. assuming Library->Dev->Test, user could delete a package from Dev leaving it in Test). For content deletion, all deletions are done via the Content->Changesets page in the UI. For reference, the following is a brief wiki on the feature: https://fedorahosted.org/katello/wiki/ContentDeletionDesign . In the bug mentioned, the issue is with deleting content via Content -> Repositories -> Custom Content Repositories. This deletes the repository from the Library; however, it appears to be leaving some data in the later environments along the path. For this one, a couple of solutions might be: 1. Do not allow user to delete a repository. (Doesn't sound good). 2. Allow the user to delete a repository, deleting it from the Library and all environments that it has been promoted to. Prior to deletion, in the Deletion Confirmation dialog provide them with additional information detailing all environments that the Repository will be deleted from. For example, Are you sure you want to delete repo ABC? Warning! This repo currently exists in: Library->Dev->Test and Library->Dev2 thanks, Brad From dmitri at redhat.com Tue Aug 28 13:02:02 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 28 Aug 2012 14:02:02 +0100 Subject: [katello-devel] Foreman-api In-Reply-To: <20120828125432.GB5270@dhcp-230-220.rdu.redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> <503B3D7F.6020102@redhat.com> <503B54E2.4090801@redhat.com> <20120827121526.GD6031@lzapx.brq.redhat.com> <503C8F69.9030707@redhat.com> <20120828125432.GB5270@dhcp-230-220.rdu.redhat.com> Message-ID: <503CC14A.4050307@redhat.com> On 28/08/12 01:54 PM, Chris Alfonso wrote: > On 28/08/12 10:29 +0100, Dmitri Dolguikh wrote: >> On 27/08/12 01:15 PM, Lukas Zapletal wrote: >>> On Mon, Aug 27, 2012 at 01:07:14PM +0200, Miroslav Suchy wrote: >>>> On 08/27/2012 11:27 AM, Ivan Ne?as wrote: >>>>> Me as a developer, I find it much easier to use the code that I >>>>> immediately see what it expects from me. >>>>> >>>>> [1] - >>>>> https://github.com/calfonso/deadwood/blob/master/lib/deadwood/model/environment.rb >>>>> >>>>> >>>>> [2] - >>>>> https://github.com/mbacovsky/foreman_api/blob/master/lib/foreman_api/resources/architecture.rb >>>>> >>>>> >>>> +1 >>>> [2] is much more readable to me. >>> +1 No more "dynamic" stuff please. >> >> I don't want to get into discussion about code generation. We are >> developing within constraints and using conventions of REST and >> Rails. We should only write code when we are dealing with something >> that doesn't follow conventions, or extends them, instead of >> repeating the obvious. >> >> -d > It wasn't clear to me that some attributes were not allowed on an update > until I read server logs in the traceback either. I'm going to add the > disallowed attributes to the documentation for the client gem in this > case. > Perhaps I should override the update_attributes method to raise an > exception > if the developer tries to update a certain attribute. This bit is already handled by the server, I don't think you need to add an additional validation. I'd just make the filtering out of attributes somewhere closer to the model (not sure how Conductor keeps track of remotely-stored attributes, but somewhere in that general area of the code-base). -d > That might make more > sense. > -Chris >> >>> >>> Plus your favourite IDE can OmniComplete :-) >>> >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Tue Aug 28 13:06:12 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 28 Aug 2012 09:06:12 -0400 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503CBFF7.9030500@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> Message-ID: <503CC244.7070103@redhat.com> On 08/28/2012 08:56 AM, Brad Buckingham wrote: > On 08/28/2012 08:10 AM, Miroslav Such? wrote: >> On 08/28/2012 12:29 PM, Lukas Zapletal wrote: >>> Hey, >>> >>> stumbled upon a bug (https://bugzilla.redhat.com/show_bug.cgi?id=835875) >>> that prevents you from creating a repository with a same name that has >>> been deleted (but promoted). >>> >>> Now the question - we now do support demotions (those promotions >>> opposite - not sure about wording). Therefore I guess the proper >>> solution would be to check if the repository (*) was already promoted. >>> If so, Katello will refuse to delete the object asking user to do the >>> demotion. >>> >>> Opinions? >> >> +1 >> I was thinking for a while about offering to do demotion for them >> (with big exclamation mark). But if that would be easy, you can easily >> destroy your set up. So I would leave it to admin to do that by hand. >> >> -- >> Miroslav Suchy >> Red Hat Systems Management Engineering >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Hi, > > The feature that was recently introduced in Katello is content > deletion. It allows for deletion of content (which includes things such > as products, repos, packages, errata, distributions and system > templates) from any environment along the promotion path, except for the > Library. It isn't really a demotion of content since it is possible to > delete content from the an environment that is in the middle of the path > (e.g. assuming Library->Dev->Test, user could delete a package from Dev > leaving it in Test). For content deletion, all deletions are done via > the Content->Changesets page in the UI. > > For reference, the following is a brief wiki on the feature: > https://fedorahosted.org/katello/wiki/ContentDeletionDesign . > > In the bug mentioned, the issue is with deleting content via Content -> > Repositories -> Custom Content Repositories. This deletes the > repository from the Library; however, it appears to be leaving some data > in the later environments along the path. > > For this one, a couple of solutions might be: > 1. Do not allow user to delete a repository. (Doesn't sound good). > 2. Allow the user to delete a repository, deleting it from the Library > and all environments that it has been promoted to. Prior to deletion, > in the Deletion Confirmation dialog provide them with additional > information detailing all environments that the Repository will be > deleted from. For example, > Are you sure you want to delete repo ABC? > Warning! This repo currently exists in: Library->Dev->Test and > Library->Dev2 > I like (2). -- bk From pchalupa at redhat.com Tue Aug 28 13:09:16 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 28 Aug 2012 15:09:16 +0200 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <503CB585.1030904@redhat.com> References: <50361A76.2070003@redhat.com> <5036251A.3050401@redhat.com> <503C715E.3060207@redhat.com> <503C8AA9.5050108@redhat.com> <503CA7EC.6060209@redhat.com> <503CAA87.8040708@redhat.com> <503CAFE2.6080209@redhat.com> <503CB12C.1070207@redhat.com> <503CB3CB.1060009@redhat.com> <503CB585.1030904@redhat.com> Message-ID: <503CC2FC.3060203@redhat.com> On 28.08.12 14:11, Dmitri Dolguikh wrote: > On 28/08/12 01:04 PM, Petr Chalupa wrote: >> >> >> On 28.08.12 13:53, Dmitri Dolguikh wrote: >>> On 28/08/12 12:47 PM, Petr Chalupa wrote: >>>> >>>> >>>> On Tue Aug 28 13:24:55 2012, Dmitri Dolguikh wrote: >>>>> On 28/08/12 12:13 PM, Petr Chalupa wrote: >>>>>> >>>>>> >>>>>> On 28.08.12 11:08, Dmitri Dolguikh wrote: >>>>>>> On 28/08/12 08:21 AM, Petr Chalupa wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 23.08.12 14:42, Dmitri Dolguikh wrote: >>>>>>>>> On 23/08/12 12:56 PM, Petr Chalupa wrote: >>>>>>>>>> My original email raised a lot of questions, I should wrote it >>>>>>>>>> with >>>>>>>>>> more details. I apology for that. I'll try again and elaborate. >>>>>>>>>> >>>>>>>>>> = Goals >>>>>>>>>> >>>>>>>>>> 1) To be able to implement the solution in a week or so. >>>>>>>>>> 2) Not to affect deployment, keep it same way as now. >>>>>>>>>> 3) When you are installing development environment on any >>>>>>>>>> rpm-based >>>>>>>>>> system rpm-gems are used even if they are older then gems in our >>>>>>>>>> gem-repo. (this is borken right now) >>>>>>>>>> 4) When you are installing development environment in any >>>>>>>>>> non-rpm-base >>>>>>>>>> system you get installed gems as close as possible to what would >>>>>>>>>> you >>>>>>>>>> get on fedora 16. (you cannot install with bundle install only >>>>>>>>>> right >>>>>>>>>> now) >>>>>>>>>> * (optionally including the security patches, lets discuss this >>>>>>>>>> later) >>>>>>>>>> >>>>>>>>>> = What was discussed, why I think it wont work >>>>>>>>>> >>>>>>>>>> == Branch for each platform >>>>>>>>>> >>>>>>>>>> * There would be little difference between the branches (only >>>>>>>>>> Gemfile >>>>>>>>>> or Gemfile.lock). Rest of the code will be same. >>>>>>>>>> * It would be too much work to maintain it. >>>>>>>>>> >>>>>>>>>> == Gemfile.lock per platform and environment >>>>>>>>>> >>>>>>>>>> * We would have to have 8 Gemfile.locks and maintain them all (4 >>>>>>>>>> platforms multiplied by two environments) >>>>>>>>>> * Too much work unless its automated. >>>>>>>>>> * Automation would take time to setup. >>>>>>>>>> >>>>>>>>>> == Aeolus solution, bundler_ext [2] >>>>>>>>>> >>>>>>>>>> * Dependencies resolution is unaffected so 'bundle install' >>>>>>>>>> cannot be >>>>>>>>>> used to install development dependencies, it would ignore >>>>>>>>>> rpm-gems and >>>>>>>>>> install gems from gem-repo. >>>>>>>>>> * If bundler_ext is used for setup development environment, >>>>>>>>>> control >>>>>>>>>> over which versions are required is lost (requiring is not >>>>>>>>>> done by >>>>>>>>>> bundler) >>>>>>>>>> * It affects only how requirements are loaded [1], it's useful >>>>>>>>>> only >>>>>>>>>> for deployment. >>>>>>>>>> * (We could use it in deployment to get rid of bundler, but >>>>>>>>>> that is >>>>>>>>>> out of this discussion's scope see Goal.2) >>>>>>>>>> >>>>>>>>>> == bundle install --without default >>>>>>>>>> >>>>>>>>>> This installs only development gems, but: >>>>>>>>>> >>>>>>>>>> * If some of the development gems has a production gem as >>>>>>>>>> dependency >>>>>>>>>> (eg. ActiveSupport), the gem is reinstalled by bundler from a >>>>>>>>>> gem-repo >>>>>>>>>> over the older rpm-gem. >>>>>>>>>> * If only development gems are installed, bundler cannot be >>>>>>>>>> used to >>>>>>>>>> require gems. It will raise LoadError because from bundler's >>>>>>>>>> point of >>>>>>>>>> view production gems are not installed. >>>>>>>>>> * It would have to be combined with bundler_ext to find >>>>>>>>>> production >>>>>>>>>> rpm-gems, so you would loose control over which version are >>>>>>>>>> loaded >>>>>>>>>> again >>>>>>>>>> * If you forget to add '--without default' when you run 'bundle >>>>>>>>>> install' unwanted versions are installed. >>>>>>>>>> >>>>>>>>>> == vendor/cache >>>>>>>>>> >>>>>>>>>> Move all gems to src/vendor/cache (directly into katello/master >>>>>>>>>> or as >>>>>>>>>> a git sub-module) and remove sources form Gemfile completely. >>>>>>>>>> 'bundle >>>>>>>>>> install' installs gems form vendor/cache automatically if there >>>>>>>>>> are no >>>>>>>>>> sources in Gemfile. >>>>>>>>>> >>>>>>>>>> * to have .gem files directly in katello/master is ugly >>>>>>>>>> * submodules are real pain >>>>>>>>> no need to use sub-modules >>>>>>>>>> * git is not that good with binary data >>>>>>>>>> >>>>>>>>> gems are mostly ruby, very not a lot of binary data. >>>>>>>> >>>>>>>> gems would be stored in vendor/cache as .gem files, one file per >>>>>>>> gem >>>>>>>> which are actually tar.gz (binary). That is what I meant sorry >>>>>>>> about >>>>>>>> the confusion. >>>>>>>> >>>>>>>>>> = My proposal >>>>>>>>>> >>>>>>>>>> == Bundler patch >>>>>>>>>> >>>>>>>>>> * it would be loaded in Gemfile, so every tool using bundler will >>>>>>>>>> get it >>>>>>>>> I don't think a single Gemfile is going to solve the issue: we'll >>>>>>>>> need >>>>>>>>> to relax version constraints in Gemfile, and add a bunch of >>>>>>>>> ruby-version >>>>>>>>> specific gems... >>>>>>>>>> >>>>>>>>>> * it would ensure that if rpm-gem is present it's used even if >>>>>>>>>> there >>>>>>>>>> is newer version available in gem-repo >>>>>>>>>> * ensure that locally installed gems are not confused with >>>>>>>>>> rpm-gems >>>>>>>>> You didn't explain how you are planning to differentiate between >>>>>>>>> the two >>>>>>>>> - system-wide bundler-/ruby-gem-installed gems and rpm-installed >>>>>>>>> gems... >>>>>>>> >>>>>>>> I don't think this is a problem, see [1] how I did it. >>>>>>> >>>>>>> This is not a good approach - you introduced platform-specific code >>>>>>> into >>>>>>> main Katello code base. >>>>>>> >>>>>>>>>> * patch is optional, can be turned on/off by ENV variable or by >>>>>>>>>> options >>>>>>>>>> * (I am also considering to add optional check that all >>>>>>>>>> production >>>>>>>>>> gems are installed as rpms) >>>>>>>>>> >>>>>>>>>> Deployment is unaffected, all dependencies are satisfied by >>>>>>>>>> rpm-gems. >>>>>>>>>> >>>>>>>>>> When you run bundle install to get development environment on any >>>>>>>>>> rpm-based machine, all your rpms have priority and they are used. >>>>>>>>>> All >>>>>>>>>> missing development gems are installed from our gem-repo. >>>>>>>>> I think this is the crux of the issue. Once we have a custom gem >>>>>>>>> repository, the above step has very little practical value. A ruby >>>>>>>>> gem >>>>>>>>> is a ruby gem no matter what place in the system it's installed >>>>>>>>> in. >>>>>>>> >>>>>>>> IMO This has a big practical value. When you are fixing a bug you >>>>>>>> want >>>>>>>> to be sure that you have same rpm-gems installed and required as in >>>>>>>> production where the bug was discovered. >>>>>>> >>>>>>> Do you understand how ruby loads gem dependencies? Can you >>>>>>> explain the >>>>>>> difference between rpm-installed gem, and bundler-installed gem (for >>>>>>> system-wide installs)? >>>>>>> >>>>>> >>>>>> Yeah, I understand, We just don't understand each other :) How is >>>>>> this relevant to what I said before? I would like to give you an >>>>>> answer but I don't see the connection, please explain where are you >>>>>> heading with this. >>>>> >>>>> Ultimately, one way, or another, we are solving the problem of loading >>>>> gem dependencies. I'd like you to demonstrate the difference between >>>>> loading of a regular ruby gem and rpm-installed ruby gem by ruby >>>>> interpreter. >>>>> >>>> >>>> The patch I introduced does not affect how gems are required. It >>>> changes how bundler prioritizes gem matching against dependencies. >>>> Rpm-gems are moved to the top in the queue of gem candidates for the >>>> dependency matching. So rpm-gems are matched/picked before other gems. >>>> Rpm-gems are matched/picked even if there is newer version in gem-repo. >>>> >>>> To answer you question, plain ruby process requires newest available >>>> version of a given gem, regular or rpm-installed. There is no >>>> difference for Ruby. This is unchanged by the patch. >>>> >>>> Ruby process using Bundler (with or without the patch) to require gems >>>> will require gems in versions as they are specified in Gemfile.lock, >>>> regular or rpm-installed. This is also unchanged by the patch. >>>> >>>> The ruby requiring algorithm with or without bundler is unchanged by >>>> the patch. >>>> >>>> What gems are in Gemfile.lock is resolved when `bundle install` is >>>> run. What gems are resolved and picked to Gemfile.lock is altered by >>>> the patch. >>>> >>>> Does this help to answer your question? >>> It does, thank you. You have shown there's no difference between loading >>> gems from either of the sources. What benefits does your patch provide >>> over bundler using have platform-specific repository[ies]? >>> >>> -d >> >> You are able to install development dependencies on top of already >> installed rpm-gems (production dependencies) without overshadowing >> them with newer gems from gem-repo. Needed for RHEL and CentOS. On >> fedora 16 the rpm-gems have same versions as gems in our gem-repo. On >> non-rpm machine you get same versions as on fedora 16 because I also >> updated gem-repo with missing gems (this was not possible before). >> > > I thought we were going to have platform-specific gem repositories which > would contain platform-appropriate versions of gems? If we were to have > just one repository, how would you solve the problem of development > dependency requiring newer production dependency not available on the > target platform? > This was suggested by Lukas, I didn't intended to implement it now. I wanted quick-fix in 1 or 2 days. (This patch and adding missing gems to gem-repo were quick solution). The platform specific gems are kept (on fedora or rhel) because rpm-gems are preferred before regular gems. Seems to me that the problem you are describing is exotic and if we encounter something like that we should avoid it by specifying dependency on older version of the development gem. >> Petr >> >>>> >>>> Petr >>>> >>>>> >>>>>> >>>>>>> -d >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> On non-rpm-based machine, 'bundle install' installs all gems >>>>>>>>>> production and development from our gem-repo. >>>>>>>>>> >>>>>>>>>> == Gem Repository >>>>>>>>>> >>>>>>>>>> Bundler patch will work only if all development and production >>>>>>>>>> gems >>>>>>>>>> are in the gem-repo. To get it fixed quickly 'bundle package' >>>>>>>>>> can be >>>>>>>>>> used to get all the gems. Missing gems can be then uploaded to >>>>>>>>>> katello-thirdparty (source for our gem-repo) >>>>>>>>>> >>>>>>>>>> = Summary >>>>>>>>>> >>>>>>>>>> I think that Bundler patch and updating gem-repo to contain all >>>>>>>>>> gems >>>>>>>>>> is the only one which can be done fast and will work on any >>>>>>>>>> machine in >>>>>>>>>> deployment and development. I tried to be thorough but if I >>>>>>>>>> missed >>>>>>>>>> something or if you have better ideas please let me know. >>>>>>>>> The issue with dependency version variability needs solving. The >>>>>>>>> patch >>>>>>>>> itself has little practical value, bundle install from custom >>>>>>>>> repository >>>>>>>>> is sufficient. The irony is that you are trying to solve the >>>>>>>>> problem >>>>>>>>> Bundler has successfully solved awhile ago. I'm baffled as to >>>>>>>>> why we >>>>>>>>> continue to insist on solving the problems the "katello" way. >>>>>>>>> >>>>>>>>> -d >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Petr >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [2] https://github.com/aeolus-incubator/bundler_ext >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> >>>>>>>> [1] https://github.com/Katello/katello/pull/526 >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From calfonso at redhat.com Tue Aug 28 13:09:49 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Tue, 28 Aug 2012 09:09:49 -0400 Subject: [katello-devel] Foreman-api In-Reply-To: <503CBCD5.4040401@redhat.com> References: <503750EC.7020605@redhat.com> <20120824143815.GN3980@lzapx.brq.redhat.com> <503794AF.6030609@redhat.com> <50379545.40901@redhat.com> <50379653.9090507@redhat.com> <5037969E.7010403@redhat.com> <503B3D7F.6020102@redhat.com> <503C8DE6.7050905@redhat.com> <20120828122759.GA5270@dhcp-230-220.rdu.redhat.com> <503CBCD5.4040401@redhat.com> Message-ID: <20120828130949.GC5270@dhcp-230-220.rdu.redhat.com> On 28/08/12 13:43 +0100, Dmitri Dolguikh wrote: >On 28/08/12 01:27 PM, Chris Alfonso wrote: >>On 28/08/12 10:22 +0100, Dmitri Dolguikh wrote: >>>On 27/08/12 10:27 AM, Ivan Ne?as wrote: >>>>On 08/24/2012 04:58 PM, Dmitri Dolguikh wrote: >>>>>On 24/08/12 03:57 PM, Bryan Kearney wrote: >>>>>>On 08/24/2012 10:52 AM, Jason Rist wrote: >>>>>>>On 08/24/2012 10:50 AM, Dmitri Dolguikh wrote: [snip] >It certainly belongs on the client, there is no question about that >in my mind. I'm not sure that silently dropping an attribute from the >hash is a good approach though, as it may lead to a confusing >situation when a developer attempts to update an attribute, sees a >success, but the attribute hasn't been actually changed on the >server. > Thanks for the input, let me think on this a bit and I'll make updates accordingly. Once we have the autogenerated stuff in place for katello, I'll send this project to /dev/null :) - Chris >Haven't looked at how Aeolus/Conductor handles remote models though, >perhaps this is appropriate there. > >Cheers, >-d > >> >>- Chris [snip] >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From jrist at redhat.com Tue Aug 28 13:22:24 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 28 Aug 2012 07:22:24 -0600 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503CBFF7.9030500@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> Message-ID: <503CC610.7010003@redhat.com> On 08/28/2012 06:56 AM, Brad Buckingham wrote: > On 08/28/2012 08:10 AM, Miroslav Such? wrote: >> On 08/28/2012 12:29 PM, Lukas Zapletal wrote: >>> Hey, >>> >>> stumbled upon a bug (https://bugzilla.redhat.com/show_bug.cgi?id=835875) >>> that prevents you from creating a repository with a same name that has >>> been deleted (but promoted). >>> >>> Now the question - we now do support demotions (those promotions >>> opposite - not sure about wording). Therefore I guess the proper >>> solution would be to check if the repository (*) was already promoted. >>> If so, Katello will refuse to delete the object asking user to do the >>> demotion. >>> >>> Opinions? >> >> +1 >> I was thinking for a while about offering to do demotion for them >> (with big exclamation mark). But if that would be easy, you can easily >> destroy your set up. So I would leave it to admin to do that by hand. >> >> -- >> Miroslav Suchy >> Red Hat Systems Management Engineering >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Hi, > > The feature that was recently introduced in Katello is content > deletion. It allows for deletion of content (which includes things such > as products, repos, packages, errata, distributions and system > templates) from any environment along the promotion path, except for the > Library. It isn't really a demotion of content since it is possible to > delete content from the an environment that is in the middle of the path > (e.g. assuming Library->Dev->Test, user could delete a package from Dev > leaving it in Test). For content deletion, all deletions are done via > the Content->Changesets page in the UI. > > For reference, the following is a brief wiki on the feature: > https://fedorahosted.org/katello/wiki/ContentDeletionDesign . > > In the bug mentioned, the issue is with deleting content via Content -> > Repositories -> Custom Content Repositories. This deletes the > repository from the Library; however, it appears to be leaving some data > in the later environments along the path. > > For this one, a couple of solutions might be: > 1. Do not allow user to delete a repository. (Doesn't sound good). > 2. Allow the user to delete a repository, deleting it from the Library > and all environments that it has been promoted to. Prior to deletion, > in the Deletion Confirmation dialog provide them with additional > information detailing all environments that the Repository will be > deleted from. For example, > Are you sure you want to delete repo ABC? > Warning! This repo currently exists in: Library->Dev->Test and > Library->Dev2 > > thanks, > Brad > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I like 2 Will this also delete the data from the disk? -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From lzap at redhat.com Tue Aug 28 13:47:36 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 28 Aug 2012 15:47:36 +0200 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503CBFF7.9030500@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> Message-ID: <20120828134736.GC1383@lzapx.brq.redhat.com> On Tue, Aug 28, 2012 at 08:56:23AM -0400, Brad Buckingham wrote: > For this one, a couple of solutions might be: > 1. Do not allow user to delete a repository. (Doesn't sound good). > 2. Allow the user to delete a repository, deleting it from the > Library and all environments that it has been promoted to. Prior to > deletion, in the Deletion Confirmation dialog provide them with > additional information detailing all environments that the > Repository will be deleted from. For example, > Are you sure you want to delete repo ABC? > Warning! This repo currently exists in: Library->Dev->Test and > Library->Dev2 > I also like 2, but this is CFSE 1.1 bug. I'd prefer to implement 1 for CFSE 1.1 and then we could put number two on our backlogs. -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Tue Aug 28 14:17:46 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 28 Aug 2012 15:17:46 +0100 Subject: [katello-devel] Bundler vs rpm-gems - in more detail In-Reply-To: <503CC2FC.3060203@redhat.com> References: <50361A76.2070003@redhat.com> <5036251A.3050401@redhat.com> <503C715E.3060207@redhat.com> <503C8AA9.5050108@redhat.com> <503CA7EC.6060209@redhat.com> <503CAA87.8040708@redhat.com> <503CAFE2.6080209@redhat.com> <503CB12C.1070207@redhat.com> <503CB3CB.1060009@redhat.com> <503CB585.1030904@redhat.com> <503CC2FC.3060203@redhat.com> Message-ID: <503CD30A.9080500@redhat.com> On 28/08/12 02:09 PM, Petr Chalupa wrote: > > > On 28.08.12 14:11, Dmitri Dolguikh wrote: >> On 28/08/12 01:04 PM, Petr Chalupa wrote: >>> >>> >>> On 28.08.12 13:53, Dmitri Dolguikh wrote: >>>> On 28/08/12 12:47 PM, Petr Chalupa wrote: >>>>> >>>>> >>>>> On Tue Aug 28 13:24:55 2012, Dmitri Dolguikh wrote: >>>>>> On 28/08/12 12:13 PM, Petr Chalupa wrote: >>>>>>> >>>>>>> >>>>>>> On 28.08.12 11:08, Dmitri Dolguikh wrote: >>>>>>>> On 28/08/12 08:21 AM, Petr Chalupa wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 23.08.12 14:42, Dmitri Dolguikh wrote: >>>>>>>>>> On 23/08/12 12:56 PM, Petr Chalupa wrote: >>>>>>>>>>> My original email raised a lot of questions, I should wrote it >>>>>>>>>>> with >>>>>>>>>>> more details. I apology for that. I'll try again and elaborate. >>>>>>>>>>> >>>>>>>>>>> = Goals >>>>>>>>>>> >>>>>>>>>>> 1) To be able to implement the solution in a week or so. >>>>>>>>>>> 2) Not to affect deployment, keep it same way as now. >>>>>>>>>>> 3) When you are installing development environment on any >>>>>>>>>>> rpm-based >>>>>>>>>>> system rpm-gems are used even if they are older then gems in >>>>>>>>>>> our >>>>>>>>>>> gem-repo. (this is borken right now) >>>>>>>>>>> 4) When you are installing development environment in any >>>>>>>>>>> non-rpm-base >>>>>>>>>>> system you get installed gems as close as possible to what >>>>>>>>>>> would >>>>>>>>>>> you >>>>>>>>>>> get on fedora 16. (you cannot install with bundle install only >>>>>>>>>>> right >>>>>>>>>>> now) >>>>>>>>>>> * (optionally including the security patches, lets discuss >>>>>>>>>>> this >>>>>>>>>>> later) >>>>>>>>>>> >>>>>>>>>>> = What was discussed, why I think it wont work >>>>>>>>>>> >>>>>>>>>>> == Branch for each platform >>>>>>>>>>> >>>>>>>>>>> * There would be little difference between the branches (only >>>>>>>>>>> Gemfile >>>>>>>>>>> or Gemfile.lock). Rest of the code will be same. >>>>>>>>>>> * It would be too much work to maintain it. >>>>>>>>>>> >>>>>>>>>>> == Gemfile.lock per platform and environment >>>>>>>>>>> >>>>>>>>>>> * We would have to have 8 Gemfile.locks and maintain them >>>>>>>>>>> all (4 >>>>>>>>>>> platforms multiplied by two environments) >>>>>>>>>>> * Too much work unless its automated. >>>>>>>>>>> * Automation would take time to setup. >>>>>>>>>>> >>>>>>>>>>> == Aeolus solution, bundler_ext [2] >>>>>>>>>>> >>>>>>>>>>> * Dependencies resolution is unaffected so 'bundle install' >>>>>>>>>>> cannot be >>>>>>>>>>> used to install development dependencies, it would ignore >>>>>>>>>>> rpm-gems and >>>>>>>>>>> install gems from gem-repo. >>>>>>>>>>> * If bundler_ext is used for setup development environment, >>>>>>>>>>> control >>>>>>>>>>> over which versions are required is lost (requiring is not >>>>>>>>>>> done by >>>>>>>>>>> bundler) >>>>>>>>>>> * It affects only how requirements are loaded [1], it's useful >>>>>>>>>>> only >>>>>>>>>>> for deployment. >>>>>>>>>>> * (We could use it in deployment to get rid of bundler, but >>>>>>>>>>> that is >>>>>>>>>>> out of this discussion's scope see Goal.2) >>>>>>>>>>> >>>>>>>>>>> == bundle install --without default >>>>>>>>>>> >>>>>>>>>>> This installs only development gems, but: >>>>>>>>>>> >>>>>>>>>>> * If some of the development gems has a production gem as >>>>>>>>>>> dependency >>>>>>>>>>> (eg. ActiveSupport), the gem is reinstalled by bundler from a >>>>>>>>>>> gem-repo >>>>>>>>>>> over the older rpm-gem. >>>>>>>>>>> * If only development gems are installed, bundler cannot be >>>>>>>>>>> used to >>>>>>>>>>> require gems. It will raise LoadError because from bundler's >>>>>>>>>>> point of >>>>>>>>>>> view production gems are not installed. >>>>>>>>>>> * It would have to be combined with bundler_ext to find >>>>>>>>>>> production >>>>>>>>>>> rpm-gems, so you would loose control over which version are >>>>>>>>>>> loaded >>>>>>>>>>> again >>>>>>>>>>> * If you forget to add '--without default' when you run 'bundle >>>>>>>>>>> install' unwanted versions are installed. >>>>>>>>>>> >>>>>>>>>>> == vendor/cache >>>>>>>>>>> >>>>>>>>>>> Move all gems to src/vendor/cache (directly into katello/master >>>>>>>>>>> or as >>>>>>>>>>> a git sub-module) and remove sources form Gemfile completely. >>>>>>>>>>> 'bundle >>>>>>>>>>> install' installs gems form vendor/cache automatically if there >>>>>>>>>>> are no >>>>>>>>>>> sources in Gemfile. >>>>>>>>>>> >>>>>>>>>>> * to have .gem files directly in katello/master is ugly >>>>>>>>>>> * submodules are real pain >>>>>>>>>> no need to use sub-modules >>>>>>>>>>> * git is not that good with binary data >>>>>>>>>>> >>>>>>>>>> gems are mostly ruby, very not a lot of binary data. >>>>>>>>> >>>>>>>>> gems would be stored in vendor/cache as .gem files, one file per >>>>>>>>> gem >>>>>>>>> which are actually tar.gz (binary). That is what I meant sorry >>>>>>>>> about >>>>>>>>> the confusion. >>>>>>>>> >>>>>>>>>>> = My proposal >>>>>>>>>>> >>>>>>>>>>> == Bundler patch >>>>>>>>>>> >>>>>>>>>>> * it would be loaded in Gemfile, so every tool using bundler >>>>>>>>>>> will >>>>>>>>>>> get it >>>>>>>>>> I don't think a single Gemfile is going to solve the issue: >>>>>>>>>> we'll >>>>>>>>>> need >>>>>>>>>> to relax version constraints in Gemfile, and add a bunch of >>>>>>>>>> ruby-version >>>>>>>>>> specific gems... >>>>>>>>>>> >>>>>>>>>>> * it would ensure that if rpm-gem is present it's used even if >>>>>>>>>>> there >>>>>>>>>>> is newer version available in gem-repo >>>>>>>>>>> * ensure that locally installed gems are not confused with >>>>>>>>>>> rpm-gems >>>>>>>>>> You didn't explain how you are planning to differentiate between >>>>>>>>>> the two >>>>>>>>>> - system-wide bundler-/ruby-gem-installed gems and rpm-installed >>>>>>>>>> gems... >>>>>>>>> >>>>>>>>> I don't think this is a problem, see [1] how I did it. >>>>>>>> >>>>>>>> This is not a good approach - you introduced platform-specific >>>>>>>> code >>>>>>>> into >>>>>>>> main Katello code base. >>>>>>>> >>>>>>>>>>> * patch is optional, can be turned on/off by ENV variable or by >>>>>>>>>>> options >>>>>>>>>>> * (I am also considering to add optional check that all >>>>>>>>>>> production >>>>>>>>>>> gems are installed as rpms) >>>>>>>>>>> >>>>>>>>>>> Deployment is unaffected, all dependencies are satisfied by >>>>>>>>>>> rpm-gems. >>>>>>>>>>> >>>>>>>>>>> When you run bundle install to get development environment >>>>>>>>>>> on any >>>>>>>>>>> rpm-based machine, all your rpms have priority and they are >>>>>>>>>>> used. >>>>>>>>>>> All >>>>>>>>>>> missing development gems are installed from our gem-repo. >>>>>>>>>> I think this is the crux of the issue. Once we have a custom gem >>>>>>>>>> repository, the above step has very little practical value. A >>>>>>>>>> ruby >>>>>>>>>> gem >>>>>>>>>> is a ruby gem no matter what place in the system it's installed >>>>>>>>>> in. >>>>>>>>> >>>>>>>>> IMO This has a big practical value. When you are fixing a bug you >>>>>>>>> want >>>>>>>>> to be sure that you have same rpm-gems installed and required >>>>>>>>> as in >>>>>>>>> production where the bug was discovered. >>>>>>>> >>>>>>>> Do you understand how ruby loads gem dependencies? Can you >>>>>>>> explain the >>>>>>>> difference between rpm-installed gem, and bundler-installed gem >>>>>>>> (for >>>>>>>> system-wide installs)? >>>>>>>> >>>>>>> >>>>>>> Yeah, I understand, We just don't understand each other :) How is >>>>>>> this relevant to what I said before? I would like to give you an >>>>>>> answer but I don't see the connection, please explain where are you >>>>>>> heading with this. >>>>>> >>>>>> Ultimately, one way, or another, we are solving the problem of >>>>>> loading >>>>>> gem dependencies. I'd like you to demonstrate the difference between >>>>>> loading of a regular ruby gem and rpm-installed ruby gem by ruby >>>>>> interpreter. >>>>>> >>>>> >>>>> The patch I introduced does not affect how gems are required. It >>>>> changes how bundler prioritizes gem matching against dependencies. >>>>> Rpm-gems are moved to the top in the queue of gem candidates for the >>>>> dependency matching. So rpm-gems are matched/picked before other >>>>> gems. >>>>> Rpm-gems are matched/picked even if there is newer version in >>>>> gem-repo. >>>>> >>>>> To answer you question, plain ruby process requires newest available >>>>> version of a given gem, regular or rpm-installed. There is no >>>>> difference for Ruby. This is unchanged by the patch. >>>>> >>>>> Ruby process using Bundler (with or without the patch) to require >>>>> gems >>>>> will require gems in versions as they are specified in Gemfile.lock, >>>>> regular or rpm-installed. This is also unchanged by the patch. >>>>> >>>>> The ruby requiring algorithm with or without bundler is unchanged by >>>>> the patch. >>>>> >>>>> What gems are in Gemfile.lock is resolved when `bundle install` is >>>>> run. What gems are resolved and picked to Gemfile.lock is altered by >>>>> the patch. >>>>> >>>>> Does this help to answer your question? >>>> It does, thank you. You have shown there's no difference between >>>> loading >>>> gems from either of the sources. What benefits does your patch provide >>>> over bundler using have platform-specific repository[ies]? >>>> >>>> -d >>> >>> You are able to install development dependencies on top of already >>> installed rpm-gems (production dependencies) without overshadowing >>> them with newer gems from gem-repo. Needed for RHEL and CentOS. On >>> fedora 16 the rpm-gems have same versions as gems in our gem-repo. On >>> non-rpm machine you get same versions as on fedora 16 because I also >>> updated gem-repo with missing gems (this was not possible before). >>> >> >> I thought we were going to have platform-specific gem repositories which >> would contain platform-appropriate versions of gems? If we were to have >> just one repository, how would you solve the problem of development >> dependency requiring newer production dependency not available on the >> target platform? >> > > This was suggested by Lukas, I didn't intended to implement it now. I > wanted quick-fix in 1 or 2 days. (This patch and adding missing gems > to gem-repo were quick solution). I'd like to have an idea about a long-term solution as well. > The platform specific gems are kept (on fedora or rhel) because > rpm-gems are preferred before regular gems. > > Seems to me that the problem you are describing is exotic and if we > encounter something like that we should avoid it by specifying > dependency on older version of the development gem. I think I see now. The approach you are suggesting *is* the simplest, provided you discount the effort of installing a given target platform for development, and the changes between platforms are minimal. -d > >>> Petr >>> >>>>> >>>>> Petr >>>>> >>>>>> >>>>>>> >>>>>>>> -d >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On non-rpm-based machine, 'bundle install' installs all gems >>>>>>>>>>> production and development from our gem-repo. >>>>>>>>>>> >>>>>>>>>>> == Gem Repository >>>>>>>>>>> >>>>>>>>>>> Bundler patch will work only if all development and production >>>>>>>>>>> gems >>>>>>>>>>> are in the gem-repo. To get it fixed quickly 'bundle package' >>>>>>>>>>> can be >>>>>>>>>>> used to get all the gems. Missing gems can be then uploaded to >>>>>>>>>>> katello-thirdparty (source for our gem-repo) >>>>>>>>>>> >>>>>>>>>>> = Summary >>>>>>>>>>> >>>>>>>>>>> I think that Bundler patch and updating gem-repo to contain all >>>>>>>>>>> gems >>>>>>>>>>> is the only one which can be done fast and will work on any >>>>>>>>>>> machine in >>>>>>>>>>> deployment and development. I tried to be thorough but if I >>>>>>>>>>> missed >>>>>>>>>>> something or if you have better ideas please let me know. >>>>>>>>>> The issue with dependency version variability needs solving. The >>>>>>>>>> patch >>>>>>>>>> itself has little practical value, bundle install from custom >>>>>>>>>> repository >>>>>>>>>> is sufficient. The irony is that you are trying to solve the >>>>>>>>>> problem >>>>>>>>>> Bundler has successfully solved awhile ago. I'm baffled as to >>>>>>>>>> why we >>>>>>>>>> continue to insist on solving the problems the "katello" way. >>>>>>>>>> >>>>>>>>>> -d >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Petr >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb#L21 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [2] https://github.com/aeolus-incubator/bundler_ext >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> [1] https://github.com/Katello/katello/pull/526 >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> From jsherril at redhat.com Tue Aug 28 15:10:10 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 28 Aug 2012 11:10:10 -0400 Subject: [katello-devel] Demotions and deletions In-Reply-To: <20120828134736.GC1383@lzapx.brq.redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <20120828134736.GC1383@lzapx.brq.redhat.com> Message-ID: <503CDF52.8020907@redhat.com> On 08/28/2012 09:47 AM, Lukas Zapletal wrote: > On Tue, Aug 28, 2012 at 08:56:23AM -0400, Brad Buckingham wrote: >> For this one, a couple of solutions might be: >> 1. Do not allow user to delete a repository. (Doesn't sound good). >> 2. Allow the user to delete a repository, deleting it from the >> Library and all environments that it has been promoted to. Prior to >> deletion, in the Deletion Confirmation dialog provide them with >> additional information detailing all environments that the >> Repository will be deleted from. For example, >> Are you sure you want to delete repo ABC? >> Warning! This repo currently exists in: Library->Dev->Test and >> Library->Dev2 >> > I also like 2, but this is CFSE 1.1 bug. I'd prefer to implement 1 for > CFSE 1.1 and then we could put number two on our backlogs. > I can't access the bug at the moment, but as a user I would expect to a certain degree that deleting a repository would delete it across all environments. (What good would they be if it didn't?) I don't think its technically difficult to do that, so I would shoot for that in CFSE 1.1 IMHO -Justin From jsherril at redhat.com Tue Aug 28 15:15:44 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 28 Aug 2012 11:15:44 -0400 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503CDF52.8020907@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <20120828134736.GC1383@lzapx.brq.redhat.com> <503CDF52.8020907@redhat.com> Message-ID: <503CE0A0.5050508@redhat.com> On 08/28/2012 11:10 AM, Justin Sherrill wrote: > On 08/28/2012 09:47 AM, Lukas Zapletal wrote: >> On Tue, Aug 28, 2012 at 08:56:23AM -0400, Brad Buckingham wrote: >>> For this one, a couple of solutions might be: >>> 1. Do not allow user to delete a repository. (Doesn't sound good). >>> 2. Allow the user to delete a repository, deleting it from the >>> Library and all environments that it has been promoted to. Prior to >>> deletion, in the Deletion Confirmation dialog provide them with >>> additional information detailing all environments that the >>> Repository will be deleted from. For example, >>> Are you sure you want to delete repo ABC? >>> Warning! This repo currently exists in: Library->Dev->Test and >>> Library->Dev2 >>> >> I also like 2, but this is CFSE 1.1 bug. I'd prefer to implement 1 for >> CFSE 1.1 and then we could put number two on our backlogs. >> > I can't access the bug at the moment, but as a user I would expect to > a certain degree that deleting a repository would delete it across all > environments. (What good would they be if it didn't?) I don't think > its technically difficult to do that, so I would shoot for that in > CFSE 1.1 IMHO > > -Justin We also would probably need some sort of migration script to delete old stale repositories. -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Tue Aug 28 16:13:03 2012 From: mmccune at redhat.com (Mike McCune) Date: Tue, 28 Aug 2012 09:13:03 -0700 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503CC610.7010003@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> Message-ID: <503CEE0F.6000800@redhat.com> On 08/28/2012 06:22 AM, Jason Rist wrote: > On 08/28/2012 06:56 AM, Brad Buckingham wrote: >> On 08/28/2012 08:10 AM, Miroslav Such? wrote: >>> On 08/28/2012 12:29 PM, Lukas Zapletal wrote: >>>> Hey, >>>> >>>> stumbled upon a bug (https://bugzilla.redhat.com/show_bug.cgi?id=835875) >>>> that prevents you from creating a repository with a same name that has >>>> been deleted (but promoted). >>>> >>>> Now the question - we now do support demotions (those promotions >>>> opposite - not sure about wording). Therefore I guess the proper >>>> solution would be to check if the repository (*) was already promoted. >>>> If so, Katello will refuse to delete the object asking user to do the >>>> demotion. >>>> >>>> Opinions? >>> >>> +1 >>> I was thinking for a while about offering to do demotion for them >>> (with big exclamation mark). But if that would be easy, you can easily >>> destroy your set up. So I would leave it to admin to do that by hand. >>> >>> -- >>> Miroslav Suchy >>> Red Hat Systems Management Engineering >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> Hi, >> >> The feature that was recently introduced in Katello is content >> deletion. It allows for deletion of content (which includes things such >> as products, repos, packages, errata, distributions and system >> templates) from any environment along the promotion path, except for the >> Library. It isn't really a demotion of content since it is possible to >> delete content from the an environment that is in the middle of the path >> (e.g. assuming Library->Dev->Test, user could delete a package from Dev >> leaving it in Test). For content deletion, all deletions are done via >> the Content->Changesets page in the UI. >> >> For reference, the following is a brief wiki on the feature: >> https://fedorahosted.org/katello/wiki/ContentDeletionDesign . >> >> In the bug mentioned, the issue is with deleting content via Content -> >> Repositories -> Custom Content Repositories. This deletes the >> repository from the Library; however, it appears to be leaving some data >> in the later environments along the path. >> >> For this one, a couple of solutions might be: >> 1. Do not allow user to delete a repository. (Doesn't sound good). >> 2. Allow the user to delete a repository, deleting it from the Library >> and all environments that it has been promoted to. Prior to deletion, >> in the Deletion Confirmation dialog provide them with additional >> information detailing all environments that the Repository will be >> deleted from. For example, >> Are you sure you want to delete repo ABC? >> Warning! This repo currently exists in: Library->Dev->Test and >> Library->Dev2 >> >> thanks, >> Brad >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > I like 2 > > Will this also delete the data from the disk? > this violates our rule that: *** "All changes to content in any live environment must be through a changeset" *** as well as our current setup that changesets only effect one environment. I'll keep repeating that over and over whenever anyone suggests a feature that bypasses this rule or we decide we don't like this rule anymore. I'm hesitant to add any option that changes this core behavior of Katello without serious consideration. What about option 3: 3) Allow user to delete custom repositories in the Library and then message them that in order to re-create any repositories with the same name they will need to go through and execute changesets in each of their environments to delete the repos from anywhere they promoted to. We could auto create deletion changesets for them so all the changes to the live environments would be tracked and done through our existing mechanism. If people really want it we can allow the "apply" to mass-execute the changesets in order. We would be maintaining our existing rule above but allowing for an easier mechanism to mass delete repositories Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From jomara at redhat.com Tue Aug 28 18:55:55 2012 From: jomara at redhat.com (Jordan OMara) Date: Tue, 28 Aug 2012 14:55:55 -0400 Subject: [katello-devel] default orgs for LDAP users Message-ID: <20120828185555.GD16168@redhat.com> jrist & I were working on a bug and figured out an interesting side effect of LDAP user creation on the fly when you log on: If you don't have LDAP group / role mapping enabled, and if your admin hasn't pre-configured your account, you don't have an org assigned. Is the best behavior: 1. notifying the user to contact their admin (which they'll need to do anyway, to get their account set up properly) 2. choosing the only org if only 1 exists 3. choosing the first org if > 1 exists 4. letting them choose ANY org in the interstitial 5. A combination of 1 and 2-4 -- 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 jlabocki at redhat.com Tue Aug 28 18:57:29 2012 From: jlabocki at redhat.com (James Labocki) Date: Tue, 28 Aug 2012 14:57:29 -0400 (EDT) Subject: [katello-devel] default orgs for LDAP users In-Reply-To: <20120828185555.GD16168@redhat.com> Message-ID: <1297273813.14647237.1346180249925.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Jordan OMara" > To: katello-devel at redhat.com > Sent: Tuesday, August 28, 2012 2:55:55 PM > Subject: [katello-devel] default orgs for LDAP users > > jrist & I were working on a bug and figured out an interesting side > effect of LDAP user creation on the fly when you log on: > > If you don't have LDAP group / role mapping enabled, and if your > admin > hasn't pre-configured your account, you don't have an org assigned. > > Is the best behavior: > > 1. notifying the user to contact their admin (which they'll need to > do > anyway, to get their account set up properly) > > 2. choosing the only org if only 1 exists > > 3. choosing the first org if > 1 exists > > 4. letting them choose ANY org in the interstitial > > 5. A combination of 1 and 2-4 Is there an organization named "purgatory" we can stick them in along with the warning? :D > -- > Jordan O'Mara > Red Hat Engineering, Raleigh > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jsherril at redhat.com Tue Aug 28 19:00:37 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 28 Aug 2012 15:00:37 -0400 Subject: [katello-devel] default orgs for LDAP users In-Reply-To: <20120828185555.GD16168@redhat.com> References: <20120828185555.GD16168@redhat.com> Message-ID: <503D1555.4080600@redhat.com> On 08/28/2012 02:55 PM, Jordan OMara wrote: > jrist & I were working on a bug and figured out an interesting side > effect of LDAP user creation on the fly when you log on: > > If you don't have LDAP group / role mapping enabled, and if your admin > hasn't pre-configured your account, you don't have an org assigned. > > Is the best behavior: > > 1. notifying the user to contact their admin (which they'll need to do > anyway, to get their account set up properly) > > 2. choosing the only org if only 1 exists > > 3. choosing the first org if > 1 exists > > 4. letting them choose ANY org in the interstitial > > 5. A combination of 1 and 2-4 My vote would be for #1. I'm wary of giving a user permission to something automatically. Is there some way for the admin user to 'prepopulate' users from LDAP? So they could set up roles and assign orgs at that time? (This way it doesn't have to be a 2 step process) -Justin > > > _______________________________________________ > 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 Tue Aug 28 19:02:33 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 28 Aug 2012 15:02:33 -0400 Subject: [katello-devel] default orgs for LDAP users In-Reply-To: <1297273813.14647237.1346180249925.JavaMail.root@redhat.com> References: <1297273813.14647237.1346180249925.JavaMail.root@redhat.com> Message-ID: <503D15C9.8090908@redhat.com> On 08/28/2012 02:57 PM, James Labocki wrote: > > ----- Original Message ----- >> From: "Jordan OMara" >> To: katello-devel at redhat.com >> Sent: Tuesday, August 28, 2012 2:55:55 PM >> Subject: [katello-devel] default orgs for LDAP users >> >> jrist & I were working on a bug and figured out an interesting side >> effect of LDAP user creation on the fly when you log on: >> >> If you don't have LDAP group / role mapping enabled, and if your >> admin >> hasn't pre-configured your account, you don't have an org assigned. >> >> Is the best behavior: >> >> 1. notifying the user to contact their admin (which they'll need to >> do >> anyway, to get their account set up properly) >> >> 2. choosing the only org if only 1 exists >> >> 3. choosing the first org if > 1 exists >> >> 4. letting them choose ANY org in the interstitial >> >> 5. A combination of 1 and 2-4 > > Is there an organization named "purgatory" we can stick them in along with the warning? :D > Please.. no preferring one religion over another :) you have no orgs because of no permissions? If that is the case, lock them out with a friendly message such as "Pound Sand you hoser" -- bk From jomara at redhat.com Tue Aug 28 19:06:15 2012 From: jomara at redhat.com (Jordan OMara) Date: Tue, 28 Aug 2012 15:06:15 -0400 Subject: [katello-devel] default orgs for LDAP users In-Reply-To: <503D1555.4080600@redhat.com> References: <20120828185555.GD16168@redhat.com> <503D1555.4080600@redhat.com> Message-ID: <20120828190615.GE16168@redhat.com> On 28/08/12 15:00 -0400, Justin Sherrill wrote: >On 08/28/2012 02:55 PM, Jordan OMara wrote: > >My vote would be for #1. I'm wary of giving a user permission to >something automatically. > >Is there some way for the admin user to 'prepopulate' users from >LDAP? So they could set up roles and assign orgs at that time? >(This way it doesn't have to be a 2 step process) > Yes, absolutely, but we currently don't whitelist those users. ANY valid LDAP login works, you just have 0 permissions -- 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 ehelms at redhat.com Tue Aug 28 19:41:40 2012 From: ehelms at redhat.com (Eric Helms) Date: Tue, 28 Aug 2012 15:41:40 -0400 (EDT) Subject: [katello-devel] default orgs for LDAP users In-Reply-To: <20120828190615.GE16168@redhat.com> Message-ID: <318863616.14660124.1346182900719.JavaMail.root@redhat.com> +1 to #1 Even with 0 permissions, I don't think users should be assumed to be in an org, even if there is only one. Explicit setting over implicit. ----- Original Message ----- From: "Jordan OMara" To: "Justin Sherrill" Cc: katello-devel at redhat.com Sent: Tuesday, August 28, 2012 3:06:15 PM Subject: Re: [katello-devel] default orgs for LDAP users On 28/08/12 15:00 -0400, Justin Sherrill wrote: >On 08/28/2012 02:55 PM, Jordan OMara wrote: > >My vote would be for #1. I'm wary of giving a user permission to >something automatically. > >Is there some way for the admin user to 'prepopulate' users from >LDAP? So they could set up roles and assign orgs at that time? >(This way it doesn't have to be a 2 step process) > Yes, absolutely, but we currently don't whitelist those users. ANY valid LDAP login works, you just have 0 permissions -- Jordan O'Mara Red Hat Engineering, Raleigh _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From esammons at redhat.com Tue Aug 28 20:27:46 2012 From: esammons at redhat.com (Eric Sammons) Date: Tue, 28 Aug 2012 16:27:46 -0400 (EDT) Subject: [katello-devel] default orgs for LDAP users In-Reply-To: <318863616.14660124.1346182900719.JavaMail.root@redhat.com> Message-ID: <905449470.71789831.1346185666520.JavaMail.root@redhat.com> +1 to #1, This makes the most sense as a random user with no permission can login, but gets .... nothing. So a little you need to contact your sys admin to be set up, seems to be the most logically approach. --Eric ----- Original Message ----- > +1 to #1 > > Even with 0 permissions, I don't think users should be assumed to be > in an org, even if there is only one. Explicit setting over > implicit. > > ----- Original Message ----- > From: "Jordan OMara" > To: "Justin Sherrill" > Cc: katello-devel at redhat.com > Sent: Tuesday, August 28, 2012 3:06:15 PM > Subject: Re: [katello-devel] default orgs for LDAP users > > On 28/08/12 15:00 -0400, Justin Sherrill wrote: > >On 08/28/2012 02:55 PM, Jordan OMara wrote: > > > >My vote would be for #1. I'm wary of giving a user permission to > >something automatically. > > > >Is there some way for the admin user to 'prepopulate' users from > >LDAP? So they could set up roles and assign orgs at that time? > >(This way it doesn't have to be a 2 step process) > > > > Yes, absolutely, but we currently don't whitelist those users. ANY > valid LDAP login works, you just have 0 permissions > > -- > Jordan O'Mara > Red Hat Engineering, Raleigh > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jrist at redhat.com Tue Aug 28 20:33:48 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 28 Aug 2012 14:33:48 -0600 Subject: [katello-devel] default orgs for LDAP users In-Reply-To: <20120828185555.GD16168@redhat.com> References: <20120828185555.GD16168@redhat.com> Message-ID: <503D2B2C.3060404@redhat.com> On 08/28/2012 12:55 PM, Jordan OMara wrote: > jrist & I were working on a bug and figured out an interesting side > effect of LDAP user creation on the fly when you log on: > > If you don't have LDAP group / role mapping enabled, and if your admin > hasn't pre-configured your account, you don't have an org assigned. > > Is the best behavior: > > 1. notifying the user to contact their admin (which they'll need to do > anyway, to get their account set up properly) > > 2. choosing the only org if only 1 exists > > 3. choosing the first org if > 1 exists > > 4. letting them choose ANY org in the interstitial > > 5. A combination of 1 and 2-4 > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > The consensus seems to be #1, and I agree. Jordan - I can put this in as my work that I'm already doing on this front. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jomara at redhat.com Tue Aug 28 20:40:07 2012 From: jomara at redhat.com (Jordan OMara) Date: Tue, 28 Aug 2012 16:40:07 -0400 Subject: [katello-devel] default orgs for LDAP users In-Reply-To: <503D2B2C.3060404@redhat.com> References: <20120828185555.GD16168@redhat.com> <503D2B2C.3060404@redhat.com> Message-ID: <20120828204007.GF16168@redhat.com> On 28/08/12 14:33 -0600, Jason Rist wrote: >On 08/28/2012 12:55 PM, Jordan OMara wrote: >> jrist & I were working on a bug and figured out an interesting side >> effect of LDAP user creation on the fly when you log on: >> >> If you don't have LDAP group / role mapping enabled, and if your admin >> hasn't pre-configured your account, you don't have an org assigned. >> >> Is the best behavior: >> >> 1. notifying the user to contact their admin (which they'll need to do >> anyway, to get their account set up properly) >> >> 2. choosing the only org if only 1 exists >> >> 3. choosing the first org if > 1 exists >> >> 4. letting them choose ANY org in the interstitial >> >> 5. A combination of 1 and 2-4 >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> >The consensus seems to be #1, and I agree. Jordan - I can put this in >as my work that I'm already doing on this front. > Great! +10000 -- 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 jrist at redhat.com Tue Aug 28 20:44:53 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 28 Aug 2012 14:44:53 -0600 Subject: [katello-devel] default orgs for LDAP users In-Reply-To: <20120828204007.GF16168@redhat.com> References: <20120828185555.GD16168@redhat.com> <503D2B2C.3060404@redhat.com> <20120828204007.GF16168@redhat.com> Message-ID: <503D2DC5.7070000@redhat.com> On Tue 28 Aug 2012 02:40:07 PM MDT, Jordan OMara wrote: > On 28/08/12 14:33 -0600, Jason Rist wrote: >> On 08/28/2012 12:55 PM, Jordan OMara wrote: >>> jrist & I were working on a bug and figured out an interesting side >>> effect of LDAP user creation on the fly when you log on: >>> >>> If you don't have LDAP group / role mapping enabled, and if your admin >>> hasn't pre-configured your account, you don't have an org assigned. >>> >>> Is the best behavior: >>> >>> 1. notifying the user to contact their admin (which they'll need to do >>> anyway, to get their account set up properly) >>> >>> 2. choosing the only org if only 1 exists >>> >>> 3. choosing the first org if > 1 exists >>> >>> 4. letting them choose ANY org in the interstitial >>> >>> 5. A combination of 1 and 2-4 >>> >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> The consensus seems to be #1, and I agree. Jordan - I can put this in >> as my work that I'm already doing on this front. >> > > Great! +10000 Great, so can you stop calling me scope creep now? -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From msuchy at redhat.com Wed Aug 29 06:58:57 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Wed, 29 Aug 2012 08:58:57 +0200 Subject: [katello-devel] pymongo Message-ID: <503DBDB1.3020200@redhat.com> I just finished watching: Using Katello: Part 1 - Initial Setup http://www.youtube.com/watch?v=hDWvQBpa5UU and I'm courious - what is that issue with pymongo? Why we are talking about that in screencast, but there is nothing mentioned in wiki:Install and why it is not specified in rpm Requires? Mirek From lzap at redhat.com Wed Aug 29 10:24:39 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 29 Aug 2012 12:24:39 +0200 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503CE0A0.5050508@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <20120828134736.GC1383@lzapx.brq.redhat.com> <503CDF52.8020907@redhat.com> <503CE0A0.5050508@redhat.com> Message-ID: <20120829102439.GC1405@lzapx.brq.redhat.com> On Tue, Aug 28, 2012 at 11:15:44AM -0400, Justin Sherrill wrote: > >I can't access the bug at the moment, but as a user I would expect > >to a certain degree that deleting a repository would delete it > >across all environments. (What good would they be if it didn't?) > >I don't think its technically difficult to do that, so I would > >shoot for that in CFSE 1.1 IMHO > > We also would probably need some sort of migration script to delete > old stale repositories. See? ;-) It's not THAT easy. But this is a good point. You know what - I will try to investigate this and if it turns out it is easy to implement, I'll shoot. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Aug 29 10:29:28 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 29 Aug 2012 12:29:28 +0200 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503CEE0F.6000800@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> Message-ID: <20120829102928.GD1405@lzapx.brq.redhat.com> On Tue, Aug 28, 2012 at 09:13:03AM -0700, Michael McCune wrote: > this violates our rule that: > > *** "All changes to content in any live environment must be through > a changeset" *** Now THATS a good point! > 3) Allow user to delete custom repositories in the Library and then > message them that in order to re-create any repositories with the > same name they will need to go through and execute changesets in > each of their environments to delete the repos from anywhere they > promoted to. > > We could auto create deletion changesets for them so all the changes > to the live environments would be tracked and done through our > existing mechanism. If people really want it we can allow the > "apply" to mass-execute the changesets in order. We would be > maintaining our existing rule above but allowing for an easier > mechanism to mass delete repositories The question is how would you create a deletion changeset when repository is already GONE? I mean, you can't really insert it there, there is nothing to apply. I don't get it. Maybe I just don't understand how delete promotions works atm. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Aug 29 10:38:09 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 29 Aug 2012 12:38:09 +0200 Subject: [katello-devel] pymongo In-Reply-To: <503DBDB1.3020200@redhat.com> References: <503DBDB1.3020200@redhat.com> Message-ID: <20120829103809.GG1405@lzapx.brq.redhat.com> AFAIK there were some issues with Mongo in Fedora 16 without any updates. But that's mondo, not pymongo. Pulp pulls pymongo and mongo, it's not specific Katello bug. Not sure what Vinny meant. LZ On Wed, Aug 29, 2012 at 08:58:57AM +0200, Miroslav Suchy wrote: > I just finished watching: > Using Katello: Part 1 - Initial Setup > http://www.youtube.com/watch?v=hDWvQBpa5UU > and I'm courious - what is that issue with pymongo? > > Why we are talking about that in screencast, but there is nothing > mentioned in wiki:Install and why it is not specified in rpm > Requires? > > 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 pchalupa at redhat.com Wed Aug 29 11:21:02 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 29 Aug 2012 13:21:02 +0200 Subject: [katello-devel] Foreman integration model question In-Reply-To: <50364BE7.90504@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> <503511EC.1060701@redhat.com> <50364BE7.90504@redhat.com> Message-ID: <503DFB1E.3090008@redhat.com> On 23.08.12 17:27, Dmitri Dolguikh wrote: > On 22/08/12 06:07 PM, Justin Sherrill wrote: >> On 08/22/2012 08:26 AM, Petr Chalupa wrote: >>> Lukas is right, our motivation was to break the code into smaller >>> pieces (I am big fan of SOLID and 'single responsibility principle' >>> in particular). If you write code this way, you can then move things >>> around very quickly so you can develop features and fix bugs faster. >>> No to mention it can be testes more easily. >>> >>> app/models/user.rb (User) is representation of katello user which >>> mixes (if foreman is installed) foreman orchestration >>> app/models/glue/forema/user.rb. Orchestration is working with foreman >>> through children of ForemanModel which are representation of remote >>> resources app/models/foreman/user.rb (Foreman::User). Foreman::User >>> is using foreman-api bindings which are defined as singletons in >>> lib/resources/foreman.rb. >>> >>> So there are 4 layers: >>> - katello model >>> - foreman-katello orchestration >>> - foreman model (remote resource) >>> - foreman bindings (gem foreman-api) >>> >>> I also for splitting up big parts. >> I do like this auto generated api method better (aside from there >> being two distinct User models). To say a downside of the current >> model is a giant single file pulp.rb is kinda moot, as that was just >> how it was organized, we can organize it differently quite easily. >> What we are doing here with foreman is wayyyy more than just >> organizing it differently, its a fairly completely different way of >> orchestrating things, bypassing our lazy_accessor magic. > I will insist on using the orchestration layer for all access outside of > local model. Controller code shouldn't be aware of where a given model > attribute is, otherwise you are leaking orchestration outside of model. I am sorry I did not send an email about it before we started working on this. We had a discussion about it and we agreed that this is better approach, but we didn't feel that this is a big change. Sorry about that. I'll try to explain why I think this is better. The change is that we didn't use lazy_accessor but introduced new object representing remote resources. The reason is that katello models don't get any fatter. I agree that orchestration should be hidden from ActiveController. Because Foreman::User doesn't need to expose any of its attributes it's not clear how it would look like in KTEnvironment example. In KTEnvironment case it would look like this: There would be 4 files: - models/kt_environment.rb - class definition of katello model (KTEnvironment) - models/glue/foreman/kt_environment.rb - module defining foreman orchestration (Glue::Pulp::KTEnvironment) - models/foreman/kt_environment.rb - class definition of foreman remote resource (Foreman::KTEnvironment) - lib/resources/foreman.rb - defines singleton resource adapter using foreman_api (Resources::Foreman::KTEnvironment) Lets assume Foreman::KTEnvironment has two attributes :hidden and :exposed where :hidden should not be visible form ActiveController nad :exposed should. Then :hidden is hidden in Foreman::KTEnvironment and Foreman::KTEnvironment instance accesible from KTEnvironment instance should not be accessed directly, Foreman::KTEnvironment is private represantion managed by foreman orchestration (Glue::Pulp::KTEnvironment). To expose :exposed attribute in KTEnvironment you would define decelerators in Glue::Pulp::KTEnvironment: def exposed foreman.exposed end def exposed=(val) foreman.exposed = val end # or method .delegate can by used delegate :exposed, :exposed=, :to => :foreman :exposed is then accessible from ActiveController but everything else is hidden. We felt that foreman vs candlepin/pulp orchestration is clear enough border not to rise confusion. As I see it the drawback in consistency is much more less important than advantages of this approach: - no huge objects - easier testing - clearer distribution of responsibilities between objects +1 to keep the current approach I hope this is explaining motivation behind this. If you have more questions please ask. Petr > That aside, but why do we need to *generate* code in *ruby*? Does that > mean we have a lot of dumb code with very little logic in it? We can and > should do better. > > -d >> >> For example, lets say we do the same with environment, where there is >> a katello environment and a foreman environment. And lets say there >> is some special piece of information only stored in foreman (this is >> not a far-fetched scenario). >> >> With our current orchestration you would do something like: >> >> a = KTEnvironment.find(3) >> print a.remote_attribute >> a.remote_attribute = "foo" >> a.save! >> >> whereas the way i see it now, we'd have to do: >> >> a = KTEnvironment.find(3) >> a.foreman_user.remote_attribute = "foo" >> a.save! >> >> I don't really like this better as you'd have to remember which >> backend engine a particular attribute is. Today you don't. I don't >> really expect any of these arguments to change the way we are doing >> anything, its just annoying to change our entire way of working with a >> backend engine without any discussion :) >> >> We need to be aware that doing it this way is creating a 2nd way with >> working with fully (or partially) remote objects and that needs to be >> clear and apparent. It also needs to be justified :) >> >> -Justin >> >>> >>> Petr >>> >>> On 22.08.12 10:19, Lukas Zapletal wrote: >>>> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: >>>>> Taking user for example we would have: >>>>> >>>>> user.rb >>>>> glue/pulp/user.rb >>>> >>>> But you are missing one piece of the puzzle: >>>> >>>> lib/resources/pulp.rb (class User) >>>> >>>> And that is the piece which you can find in foreman/user.rb. >>>> >>>>> What I see with foreman is: >>>>> >>>>> user.rb >>>>> glue/foreman/user.rb >>>>> foreman/user.rb >>>> >>>> So instead having all the resources in a single class >>>> (lib/resources/foreman.rb), we are going to have (or better - generate) >>>> all resource (read also as "dumb") classes. Each in separate file. >>>> >>>>> Where foreman/user is a second class that can be instantiated and >>>>> used on its own, while glue/foreman/user.rb is simply the >>>>> orchestration to create that object. I see the use of >>>>> Resources::ForemanModel, but in this user instance the foreman user >>>>> could be manipulated completely apart from the katello user (which >>>>> is bad IMHO). This also is completely different from our existing >>>>> orchestration methods. >>>> >>>> Yes, it is different. I like this approach more. Creating a one >>>> instance >>>> per request is nothing, while the code is definitely better than eight >>>> hundred lines long pulp.rb with all the resources there as "class" >>>> methods. >>>> >>>> I think this is the correct approach and we may discuss splitting those >>>> big resource files in future into smaller pieces for other backend >>>> engines too. If we write a similar generator, we wont longer need to >>>> write them manually (and we will be able to track API changes too). >>>> >>>> I was not writing the code, but I believe those instances are treated >>>> like singletons, so you do not need to create instances by yourself: >>>> >>>> https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb >>>> >>>> >>>> Guys please elaborate what the intentions are. >>>> >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Wed Aug 29 12:17:16 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 29 Aug 2012 08:17:16 -0400 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503CEE0F.6000800@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> Message-ID: <503E084C.9090808@redhat.com> On 08/28/2012 12:13 PM, Mike McCune wrote: > On 08/28/2012 06:22 AM, Jason Rist wrote: >> On 08/28/2012 06:56 AM, Brad Buckingham wrote: >>> On 08/28/2012 08:10 AM, Miroslav Such? wrote: >>>> On 08/28/2012 12:29 PM, Lukas Zapletal wrote: >>>>> Hey, >>>>> >>>>> stumbled upon a bug >>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=835875) >>>>> that prevents you from creating a repository with a same name that has >>>>> been deleted (but promoted). >>>>> >>>>> Now the question - we now do support demotions (those promotions >>>>> opposite - not sure about wording). Therefore I guess the proper >>>>> solution would be to check if the repository (*) was already promoted. >>>>> If so, Katello will refuse to delete the object asking user to do the >>>>> demotion. >>>>> >>>>> Opinions? >>>> >>>> +1 >>>> I was thinking for a while about offering to do demotion for them >>>> (with big exclamation mark). But if that would be easy, you can easily >>>> destroy your set up. So I would leave it to admin to do that by hand. >>>> >>>> -- >>>> Miroslav Suchy >>>> Red Hat Systems Management Engineering >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> Hi, >>> >>> The feature that was recently introduced in Katello is content >>> deletion. It allows for deletion of content (which includes things such >>> as products, repos, packages, errata, distributions and system >>> templates) from any environment along the promotion path, except for the >>> Library. It isn't really a demotion of content since it is possible to >>> delete content from the an environment that is in the middle of the path >>> (e.g. assuming Library->Dev->Test, user could delete a package from Dev >>> leaving it in Test). For content deletion, all deletions are done via >>> the Content->Changesets page in the UI. >>> >>> For reference, the following is a brief wiki on the feature: >>> https://fedorahosted.org/katello/wiki/ContentDeletionDesign . >>> >>> In the bug mentioned, the issue is with deleting content via Content -> >>> Repositories -> Custom Content Repositories. This deletes the >>> repository from the Library; however, it appears to be leaving some data >>> in the later environments along the path. >>> >>> For this one, a couple of solutions might be: >>> 1. Do not allow user to delete a repository. (Doesn't sound good). >>> 2. Allow the user to delete a repository, deleting it from the Library >>> and all environments that it has been promoted to. Prior to deletion, >>> in the Deletion Confirmation dialog provide them with additional >>> information detailing all environments that the Repository will be >>> deleted from. For example, >>> Are you sure you want to delete repo ABC? >>> Warning! This repo currently exists in: Library->Dev->Test and >>> Library->Dev2 >>> >>> thanks, >>> Brad >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> >> I like 2 >> >> Will this also delete the data from the disk? >> > > this violates our rule that: > > *** "All changes to content in any live environment must be through a > changeset" *** > > as well as our current setup that changesets only effect one environment. > > I'll keep repeating that over and over whenever anyone suggests a > feature that bypasses this rule or we decide we don't like this rule > anymore. I'm hesitant to add any option that changes this core behavior > of Katello without serious consideration. > > What about option 3: > > 3) Allow user to delete custom repositories in the Library and then > message them that in order to re-create any repositories with the same > name they will need to go through and execute changesets in each of > their environments to delete the repos from anywhere they promoted to. How would they do the deletion of the repo is gone? Should the deletion of a repo be a new changeset? > > We could auto create deletion changesets for them so all the changes to > the live environments would be tracked and done through our existing > mechanism. If people really want it we can allow the "apply" to > mass-execute the changesets in order. We would be maintaining our > existing rule above but allowing for an easier mechanism to mass delete > repositories Agree.. but is this doable for 1.1? -- bk From jsherril at redhat.com Wed Aug 29 13:07:13 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 29 Aug 2012 09:07:13 -0400 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503CEE0F.6000800@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> Message-ID: <503E1401.4020501@redhat.com> On 08/28/2012 12:13 PM, Mike McCune wrote: > On 08/28/2012 06:22 AM, Jason Rist wrote: >> On 08/28/2012 06:56 AM, Brad Buckingham wrote: >>> On 08/28/2012 08:10 AM, Miroslav Such? wrote: >>>> On 08/28/2012 12:29 PM, Lukas Zapletal wrote: >>>>> Hey, >>>>> >>>>> stumbled upon a bug >>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=835875) >>>>> that prevents you from creating a repository with a same name that >>>>> has >>>>> been deleted (but promoted). >>>>> >>>>> Now the question - we now do support demotions (those promotions >>>>> opposite - not sure about wording). Therefore I guess the proper >>>>> solution would be to check if the repository (*) was already >>>>> promoted. >>>>> If so, Katello will refuse to delete the object asking user to do the >>>>> demotion. >>>>> >>>>> Opinions? >>>> >>>> +1 >>>> I was thinking for a while about offering to do demotion for them >>>> (with big exclamation mark). But if that would be easy, you can easily >>>> destroy your set up. So I would leave it to admin to do that by hand. >>>> >>>> -- >>>> Miroslav Suchy >>>> Red Hat Systems Management Engineering >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> Hi, >>> >>> The feature that was recently introduced in Katello is content >>> deletion. It allows for deletion of content (which includes things >>> such >>> as products, repos, packages, errata, distributions and system >>> templates) from any environment along the promotion path, except for >>> the >>> Library. It isn't really a demotion of content since it is possible to >>> delete content from the an environment that is in the middle of the >>> path >>> (e.g. assuming Library->Dev->Test, user could delete a package from Dev >>> leaving it in Test). For content deletion, all deletions are done via >>> the Content->Changesets page in the UI. >>> >>> For reference, the following is a brief wiki on the feature: >>> https://fedorahosted.org/katello/wiki/ContentDeletionDesign . >>> >>> In the bug mentioned, the issue is with deleting content via Content -> >>> Repositories -> Custom Content Repositories. This deletes the >>> repository from the Library; however, it appears to be leaving some >>> data >>> in the later environments along the path. >>> >>> For this one, a couple of solutions might be: >>> 1. Do not allow user to delete a repository. (Doesn't sound good). >>> 2. Allow the user to delete a repository, deleting it from the Library >>> and all environments that it has been promoted to. Prior to deletion, >>> in the Deletion Confirmation dialog provide them with additional >>> information detailing all environments that the Repository will be >>> deleted from. For example, >>> Are you sure you want to delete repo ABC? >>> Warning! This repo currently exists in: Library->Dev->Test and >>> Library->Dev2 >>> >>> thanks, >>> Brad >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> >> I like 2 >> >> Will this also delete the data from the disk? >> > > this violates our rule that: > > *** "All changes to content in any live environment must be through a > changeset" *** So I sorta disagree with this, just because i can think of 4 examples where this isn't the case: Deleting a product Deleting a provider Deleting an environment Deleting an organization At some point there are higher level concepts that modify the content in a live environment that isn't through a changeset. We just have to figure out where that line is :) To me deleting a 'repo' is similar to deleting a product and provider in that it is deleting a high level concept that is 'above' environments. If deleting a repo shouldn't delete across environments then the same should be for product and provider IMHO. -Justin > > as well as our current setup that changesets only effect one environment. > > I'll keep repeating that over and over whenever anyone suggests a > feature that bypasses this rule or we decide we don't like this rule > anymore. I'm hesitant to add any option that changes this core > behavior of Katello without serious consideration. > > What about option 3: > > 3) Allow user to delete custom repositories in the Library and then > message them that in order to re-create any repositories with the same > name they will need to go through and execute changesets in each of > their environments to delete the repos from anywhere they promoted to. > > We could auto create deletion changesets for them so all the changes > to the live environments would be tracked and done through our > existing mechanism. If people really want it we can allow the "apply" > to mass-execute the changesets in order. We would be maintaining our > existing rule above but allowing for an easier mechanism to mass > delete repositories > > > Mike From thomasmckay at redhat.com Wed Aug 29 14:03:49 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 29 Aug 2012 10:03:49 -0400 (EDT) Subject: [katello-devel] hazards of ajax page loading In-Reply-To: <441482141.14995404.1346248902730.JavaMail.root@redhat.com> Message-ID: <1416832298.14996124.1346249029403.JavaMail.root@redhat.com> You'll notice in the attached screenshot that the login window is displayed in the right hand panel. This is because the session expired/server restarted and the user needs to login again. Rather than open a BZ I thought I'd ask 1) Is this avoidable?, and 2) Do we care? -------------- next part -------------- A non-text attachment was scrubbed... Name: login.png Type: image/png Size: 65298 bytes Desc: not available URL: From jrist at redhat.com Wed Aug 29 14:06:25 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 29 Aug 2012 08:06:25 -0600 Subject: [katello-devel] hazards of ajax page loading In-Reply-To: <1416832298.14996124.1346249029403.JavaMail.root@redhat.com> References: <1416832298.14996124.1346249029403.JavaMail.root@redhat.com> Message-ID: <503E21E1.5000509@redhat.com> On 08/29/2012 08:03 AM, Tom McKay wrote: > > You'll notice in the attached screenshot that the login window is displayed in the right hand panel. This is because the session expired/server restarted and the user needs to login again. Rather than open a BZ I thought I'd ask 1) Is this avoidable?, and 2) Do we care? > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > I noticed this last week. This is a bug :) We need to do an ajax:beforesend and double check the session cookie. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From dmitri at redhat.com Wed Aug 29 14:36:09 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 29 Aug 2012 15:36:09 +0100 Subject: [katello-devel] Foreman integration model question In-Reply-To: <503DFB1E.3090008@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> <503511EC.1060701@redhat.com> <50364BE7.90504@redhat.com> <503DFB1E.3090008@redhat.com> Message-ID: <503E28D9.6040203@redhat.com> On 29/08/12 12:21 PM, Petr Chalupa wrote: > > > On 23.08.12 17:27, Dmitri Dolguikh wrote: >> On 22/08/12 06:07 PM, Justin Sherrill wrote: >>> On 08/22/2012 08:26 AM, Petr Chalupa wrote: >>>> Lukas is right, our motivation was to break the code into smaller >>>> pieces (I am big fan of SOLID and 'single responsibility principle' >>>> in particular). If you write code this way, you can then move things >>>> around very quickly so you can develop features and fix bugs faster. >>>> No to mention it can be testes more easily. >>>> >>>> app/models/user.rb (User) is representation of katello user which >>>> mixes (if foreman is installed) foreman orchestration >>>> app/models/glue/forema/user.rb. Orchestration is working with foreman >>>> through children of ForemanModel which are representation of remote >>>> resources app/models/foreman/user.rb (Foreman::User). Foreman::User >>>> is using foreman-api bindings which are defined as singletons in >>>> lib/resources/foreman.rb. >>>> >>>> So there are 4 layers: >>>> - katello model >>>> - foreman-katello orchestration >>>> - foreman model (remote resource) >>>> - foreman bindings (gem foreman-api) >>>> >>>> I also for splitting up big parts. >>> I do like this auto generated api method better (aside from there >>> being two distinct User models). To say a downside of the current >>> model is a giant single file pulp.rb is kinda moot, as that was just >>> how it was organized, we can organize it differently quite easily. >>> What we are doing here with foreman is wayyyy more than just >>> organizing it differently, its a fairly completely different way of >>> orchestrating things, bypassing our lazy_accessor magic. >> I will insist on using the orchestration layer for all access outside of >> local model. Controller code shouldn't be aware of where a given model >> attribute is, otherwise you are leaking orchestration outside of model. > > I am sorry I did not send an email about it before we started working > on this. We had a discussion about it and we agreed that this is > better approach, but we didn't feel that this is a big change. Sorry > about that. I'll try to explain why I think this is better. > > The change is that we didn't use lazy_accessor but introduced new > object representing remote resources. The reason is that katello > models don't get any fatter. > > I agree that orchestration should be hidden from ActiveController. > Because Foreman::User doesn't need to expose any of its attributes > it's not clear how it would look like in KTEnvironment example. > > In KTEnvironment case it would look like this: > > There would be 4 files: > - models/kt_environment.rb - class definition of katello model > (KTEnvironment) > - models/glue/foreman/kt_environment.rb - module defining foreman > orchestration (Glue::Pulp::KTEnvironment) > - models/foreman/kt_environment.rb - class definition of foreman > remote resource (Foreman::KTEnvironment) > - lib/resources/foreman.rb - defines singleton resource adapter using > foreman_api (Resources::Foreman::KTEnvironment) > > Lets assume Foreman::KTEnvironment has two attributes :hidden and > :exposed where :hidden should not be visible form ActiveController nad > :exposed should. > > Then :hidden is hidden in Foreman::KTEnvironment and > Foreman::KTEnvironment instance accesible from KTEnvironment instance > should not be accessed directly, Foreman::KTEnvironment is private > represantion managed by foreman orchestration > (Glue::Pulp::KTEnvironment). > > To expose :exposed attribute in KTEnvironment you would define > decelerators in Glue::Pulp::KTEnvironment: > > def exposed > foreman.exposed > end > > def exposed=(val) > foreman.exposed = val > end > > # or method .delegate can by used > delegate :exposed, :exposed=, :to => :foreman > > :exposed is then accessible from ActiveController but everything else > is hidden. Heh. I was thinking of something similar to encapsulate initialization of remote attributes and possibly having a longer-living cache shared by all remote attributes from a given sub-system. We could potentially leave the proxy object in place (instead of hiding it behind a delegate) - it would serve as a notice of different call semantic. -d > > We felt that foreman vs candlepin/pulp orchestration is clear enough > border not to rise confusion. As I see it the drawback in consistency > is much more less important than advantages of this approach: > - no huge objects > - easier testing > - clearer distribution of responsibilities between objects > > +1 to keep the current approach > > I hope this is explaining motivation behind this. If you have more > questions please ask. > > Petr > >> That aside, but why do we need to *generate* code in *ruby*? Does that >> mean we have a lot of dumb code with very little logic in it? We can and >> should do better. >> >> -d >>> >>> For example, lets say we do the same with environment, where there is >>> a katello environment and a foreman environment. And lets say there >>> is some special piece of information only stored in foreman (this is >>> not a far-fetched scenario). >>> >>> With our current orchestration you would do something like: >>> >>> a = KTEnvironment.find(3) >>> print a.remote_attribute >>> a.remote_attribute = "foo" >>> a.save! >>> >>> whereas the way i see it now, we'd have to do: >>> >>> a = KTEnvironment.find(3) >>> a.foreman_user.remote_attribute = "foo" >>> a.save! >>> >>> I don't really like this better as you'd have to remember which >>> backend engine a particular attribute is. Today you don't. I don't >>> really expect any of these arguments to change the way we are doing >>> anything, its just annoying to change our entire way of working with a >>> backend engine without any discussion :) >>> >>> We need to be aware that doing it this way is creating a 2nd way with >>> working with fully (or partially) remote objects and that needs to be >>> clear and apparent. It also needs to be justified :) >>> >>> -Justin >>> >>>> >>>> Petr >>>> >>>> On 22.08.12 10:19, Lukas Zapletal wrote: >>>>> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: >>>>>> Taking user for example we would have: >>>>>> >>>>>> user.rb >>>>>> glue/pulp/user.rb >>>>> >>>>> But you are missing one piece of the puzzle: >>>>> >>>>> lib/resources/pulp.rb (class User) >>>>> >>>>> And that is the piece which you can find in foreman/user.rb. >>>>> >>>>>> What I see with foreman is: >>>>>> >>>>>> user.rb >>>>>> glue/foreman/user.rb >>>>>> foreman/user.rb >>>>> >>>>> So instead having all the resources in a single class >>>>> (lib/resources/foreman.rb), we are going to have (or better - >>>>> generate) >>>>> all resource (read also as "dumb") classes. Each in separate file. >>>>> >>>>>> Where foreman/user is a second class that can be instantiated and >>>>>> used on its own, while glue/foreman/user.rb is simply the >>>>>> orchestration to create that object. I see the use of >>>>>> Resources::ForemanModel, but in this user instance the foreman user >>>>>> could be manipulated completely apart from the katello user (which >>>>>> is bad IMHO). This also is completely different from our existing >>>>>> orchestration methods. >>>>> >>>>> Yes, it is different. I like this approach more. Creating a one >>>>> instance >>>>> per request is nothing, while the code is definitely better than >>>>> eight >>>>> hundred lines long pulp.rb with all the resources there as "class" >>>>> methods. >>>>> >>>>> I think this is the correct approach and we may discuss splitting >>>>> those >>>>> big resource files in future into smaller pieces for other backend >>>>> engines too. If we write a similar generator, we wont longer need to >>>>> write them manually (and we will be able to track API changes too). >>>>> >>>>> I was not writing the code, but I believe those instances are treated >>>>> like singletons, so you do not need to create instances by yourself: >>>>> >>>>> https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb >>>>> >>>>> >>>>> >>>>> Guys please elaborate what the intentions are. >>>>> >>>> >>>> _______________________________________________ >>>> 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 Wed Aug 29 14:36:57 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 29 Aug 2012 16:36:57 +0200 Subject: [katello-devel] Number of tabs on the next line Message-ID: <20120829143657.GI1405@lzapx.brq.redhat.com> Hey, I noticed we have quite mix of various indention styles in our python code base (and ruby too). My biggest concern is line continuation. So if I have a line like this one (should work both for Python and Ruby): some_func(param1, and I want to continue on the next line, various editors we use different indent. In my case, Vim, it's always two tabs. And since we agreed to expand tabs with 4 spaces in Python (and 2 spaces in Ruby), the result is (switch to monospaced font): Python: some_func(param1, param2, param3) Ruby: some_func(param1, param2, param3) I see several different styles, it looks like it's pretty random, sometimes I see the next line aligned: some_func(param1, param2, param3) I personally hate this one, cos when you have a very long line than it looks like bla bla bla bla bla bla bla bla bla bla bla bla bla some_func(param1, param2, param3) and you obviously cannot use longer_param2 because it wraps. Also this alignment does not work always (sometimes structure of the first line does not have params). What is your preference in this case? http://micropoll.com/t/KE6MnZPqfS Do you see any other issues with our indenting or code style that we should discuss? -- Later, Lukas "lzap" Zapletal #katello #systemengine From thomasmckay at redhat.com Wed Aug 29 14:43:06 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 29 Aug 2012 10:43:06 -0400 (EDT) Subject: [katello-devel] Number of tabs on the next line In-Reply-To: <20120829143657.GI1405@lzapx.brq.redhat.com> Message-ID: <1535952299.15022064.1346251386458.JavaMail.root@redhat.com> I voted other: Whatever choice is fine as long as we make a choice. :) I'm all for code style consistency. My personal pet peeve is in the javascript code where code is a mix of 2 and 4 spaces. I hear @ehelms has a rake jslint task that checks this; perhaps he'll send that email out again. ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, August 29, 2012 10:36:57 AM > Subject: [katello-devel] Number of tabs on the next line > > Hey, > > I noticed we have quite mix of various indention styles in our python > code base (and ruby too). My biggest concern is line continuation. > > So if I have a line like this one (should work both for Python and > Ruby): > > some_func(param1, > > and I want to continue on the next line, various editors we use > different indent. In my case, Vim, it's always two tabs. And since we > agreed to expand tabs with 4 spaces in Python (and 2 spaces in Ruby), > the result is (switch to monospaced font): > > Python: > > some_func(param1, > param2, > param3) > > Ruby: > > some_func(param1, > param2, > param3) > > I see several different styles, it looks like it's pretty random, > sometimes I see the next line aligned: > > some_func(param1, > param2, > param3) > > I personally hate this one, cos when you have a very long line than > it > looks like > > bla bla bla bla bla bla bla bla bla bla bla bla bla some_func(param1, > param2, > param3) > > and you obviously cannot use longer_param2 because it wraps. Also > this > alignment does not work always (sometimes structure of the first line > does not have params). > > What is your preference in this case? > > http://micropoll.com/t/KE6MnZPqfS > > Do you see any other issues with our indenting or code style that we > should discuss? > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jrist at redhat.com Wed Aug 29 14:44:32 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 29 Aug 2012 08:44:32 -0600 Subject: [katello-devel] Number of tabs on the next line In-Reply-To: <1535952299.15022064.1346251386458.JavaMail.root@redhat.com> References: <20120829143657.GI1405@lzapx.brq.redhat.com> <1535952299.15022064.1346251386458.JavaMail.root@redhat.com> Message-ID: <503E2AD0.2050707@redhat.com> On Wed 29 Aug 2012 08:43:06 AM MDT, Tom McKay wrote: > I voted other: Whatever choice is fine as long as we make a choice. :) I'm all for code style consistency. > > My personal pet peeve is in the javascript code where code is a mix of 2 and 4 spaces. I hear @ehelms has a rake jslint task that checks this; perhaps he'll send that email out again. > > ----- Original Message ----- >> From: "Lukas Zapletal" >> To: katello-devel at redhat.com >> Sent: Wednesday, August 29, 2012 10:36:57 AM >> Subject: [katello-devel] Number of tabs on the next line >> >> Hey, >> >> I noticed we have quite mix of various indention styles in our python >> code base (and ruby too). My biggest concern is line continuation. >> >> So if I have a line like this one (should work both for Python and >> Ruby): >> >> some_func(param1, >> >> and I want to continue on the next line, various editors we use >> different indent. In my case, Vim, it's always two tabs. And since we >> agreed to expand tabs with 4 spaces in Python (and 2 spaces in Ruby), >> the result is (switch to monospaced font): >> >> Python: >> >> some_func(param1, >> param2, >> param3) >> >> Ruby: >> >> some_func(param1, >> param2, >> param3) >> >> I see several different styles, it looks like it's pretty random, >> sometimes I see the next line aligned: >> >> some_func(param1, >> param2, >> param3) >> >> I personally hate this one, cos when you have a very long line than >> it >> looks like >> >> bla bla bla bla bla bla bla bla bla bla bla bla bla some_func(param1, >> param2, >> param3) >> >> and you obviously cannot use longer_param2 because it wraps. Also >> this >> alignment does not work always (sometimes structure of the first line >> does not have params). >> >> What is your preference in this case? >> >> http://micropoll.com/t/KE6MnZPqfS >> >> Do you see any other issues with our indenting or code style that we >> should discuss? >> >> -- >> 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 Perhaps I'm missing something but can't we just create some task/script that normalizes all code? If it can be compiled/interpreted... -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From lzap at redhat.com Wed Aug 29 15:21:33 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 29 Aug 2012 17:21:33 +0200 Subject: [katello-devel] hazards of ajax page loading In-Reply-To: <503E21E1.5000509@redhat.com> References: <1416832298.14996124.1346249029403.JavaMail.root@redhat.com> <503E21E1.5000509@redhat.com> Message-ID: <20120829152133.GK1405@lzapx.brq.redhat.com> On Wed, Aug 29, 2012 at 08:06:25AM -0600, Jason Rist wrote: > I noticed this last week. This is a bug :) We need to do an > ajax:beforesend and double check the session cookie. FYI until the security patch from the last week, sessions survived restarts... LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Aug 29 15:29:18 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 29 Aug 2012 17:29:18 +0200 Subject: [katello-devel] Number of tabs on the next line In-Reply-To: <503E2AD0.2050707@redhat.com> References: <20120829143657.GI1405@lzapx.brq.redhat.com> <1535952299.15022064.1346251386458.JavaMail.root@redhat.com> <503E2AD0.2050707@redhat.com> Message-ID: <20120829152918.GL1405@lzapx.brq.redhat.com> On Wed, Aug 29, 2012 at 08:44:32AM -0600, Jason Rist wrote: > Perhaps I'm missing something but can't we just create some task/script > that normalizes all code? If it can be compiled/interpreted... Why not, but you will cherry-pick all the bugs, ok? ;-) I'd prefer manual (step by step) correcting of those while we see it (in separate commits) and setting maybe some lint or something instead of a big bang that could cause merging pains. Let's make a deal first. -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Wed Aug 29 15:43:20 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Wed, 29 Aug 2012 17:43:20 +0200 Subject: [katello-devel] Number of tabs on the next line In-Reply-To: <20120829143657.GI1405@lzapx.brq.redhat.com> References: <20120829143657.GI1405@lzapx.brq.redhat.com> Message-ID: <503E3898.1010605@redhat.com> On 29.8.2012 16:36, Lukas Zapletal wrote: > What is your preference in this case? I do not care as long as: * it is spaces and not tabs * it is indented at least two spaces to right Mirek From jrist at redhat.com Wed Aug 29 15:54:44 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 29 Aug 2012 09:54:44 -0600 Subject: [katello-devel] Number of tabs on the next line In-Reply-To: <503E3898.1010605@redhat.com> References: <20120829143657.GI1405@lzapx.brq.redhat.com> <503E3898.1010605@redhat.com> Message-ID: <503E3B44.9070506@redhat.com> On Wed 29 Aug 2012 09:43:20 AM MDT, Miroslav Suchy wrote: > On 29.8.2012 16:36, Lukas Zapletal wrote: >> What is your preference in this case? > > I do not care as long as: > * it is spaces and not tabs > * it is indented at least two spaces to right > > Mirek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel +1 -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From mmccune at redhat.com Wed Aug 29 16:33:22 2012 From: mmccune at redhat.com (Mike McCune) Date: Wed, 29 Aug 2012 09:33:22 -0700 Subject: [katello-devel] pymongo In-Reply-To: <503DBDB1.3020200@redhat.com> References: <503DBDB1.3020200@redhat.com> Message-ID: <503E4452.5030700@redhat.com> On 08/28/2012 11:58 PM, Miroslav Suchy wrote: > I just finished watching: > Using Katello: Part 1 - Initial Setup > http://www.youtube.com/watch?v=hDWvQBpa5UU > and I'm courious - what is that issue with pymongo? > > Why we are talking about that in screencast, but there is nothing > mentioned in wiki:Install and why it is not specified in rpm Requires? > > Mirek > he is speaking to this open issue: https://bugzilla.redhat.com/show_bug.cgi?id=843800#c3 -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From mmccune at redhat.com Wed Aug 29 16:58:45 2012 From: mmccune at redhat.com (Mike McCune) Date: Wed, 29 Aug 2012 09:58:45 -0700 Subject: [katello-devel] Demotions and deletions In-Reply-To: <20120829102928.GD1405@lzapx.brq.redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> <20120829102928.GD1405@lzapx.brq.redhat.com> Message-ID: <503E4A45.2030300@redhat.com> On 08/29/2012 03:29 AM, Lukas Zapletal wrote: > On Tue, Aug 28, 2012 at 09:13:03AM -0700, Michael McCune wrote: >> this violates our rule that: >> >> *** "All changes to content in any live environment must be through >> a changeset" *** > > Now THATS a good point! > >> 3) Allow user to delete custom repositories in the Library and then >> message them that in order to re-create any repositories with the >> same name they will need to go through and execute changesets in >> each of their environments to delete the repos from anywhere they >> promoted to. >> >> We could auto create deletion changesets for them so all the changes >> to the live environments would be tracked and done through our >> existing mechanism. If people really want it we can allow the >> "apply" to mass-execute the changesets in order. We would be >> maintaining our existing rule above but allowing for an easier >> mechanism to mass delete repositories > > The question is how would you create a deletion changeset when > repository is already GONE? I mean, you can't really insert it there, > there is nothing to apply. I don't get it. > > Maybe I just don't understand how delete promotions works atm. > If you delete a custom repo from the Library right now from the GUI or CLI the repo will still exist in all the environments you have promoted to. So to delete the repos from say ... DEV/TEST/PROD after you delete from the Library you just go in, create a 'deletion' changeset in DEV/TEST/PROD and add the repos you previously deleted from the Library to the Changeset. Then you apply that changeset and the repos are now gone from that env. EG: 1) Create custom product, CP1 and environments: DEV/TEST 2) Add 2 repos, repo1, repo2 3) sync to library 4) promote CP1 to DEV, now you have repo1, repo2 in DEV 5) promote CP2 to TEST, now you have repo1, repo2 in TEST 6) Go into Custom Providers, delete repo2. Now repo2 is deleted from the Library but still exists in DEV and TEST 7) Create a Deletion Changeset in DEV, add repo2 to this changeset 8) Apply the changeset, repo2 is now gone from DEV but still exists in TEST 9) Create a Deletion Changeset in TEST, add repo2 to this changeset 10) Apply changeset, repo2 is now gone from TEST and exists nowhere This is how it works in master now today but after running through the above scenario we are still getting that JDBC error so content deletion is *not* cleaning something up correctly. Brad/myself can take a look at why deleting all the repos from Library -> end of promotion path is still leaving something in Candlepin Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From pchalupa at redhat.com Wed Aug 29 17:00:01 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 29 Aug 2012 19:00:01 +0200 Subject: [katello-devel] Number of tabs on the next line In-Reply-To: <20120829143657.GI1405@lzapx.brq.redhat.com> References: <20120829143657.GI1405@lzapx.brq.redhat.com> Message-ID: <503E4A91.1090404@redhat.com> Hi, the convention for spaces in Ruby is: - to indent block of code use exactly 2 spaces (if, do..end, begin..end, ...) - for line continuation use 4 spaces, optionally you can indent more to align the attributes I think the optional alignment should not be forced either way. Both makes sense. some_func some.computaion.param1, get.me.number.of.developers.in.katello, :an_option => 'a value' Is more readable than some_func some.computaion.param1, get.me.number.of.developers.in.katello, :an_option => 'a value' The normal 4spaces indentation is needed as Lukas mentioned for longer calls. bla.bla.bla.bla.bla.bla.bla.bla.bla.bla.bla.bla.some_func( some.computaion.param1, get.me.number.of.developers.in.katello, :an_option => 'a value') +1 I would keep both options. +1 I would correct the bad formatting incrementally. PS: The most feature-complete Ruby formater I've ever found is part of RubyMine (it can also format all source files at once). Petr On 29.08.12 16:36, Lukas Zapletal wrote: > Hey, > > I noticed we have quite mix of various indention styles in our python > code base (and ruby too). My biggest concern is line continuation. > > So if I have a line like this one (should work both for Python and > Ruby): > > some_func(param1, > > and I want to continue on the next line, various editors we use > different indent. In my case, Vim, it's always two tabs. And since we > agreed to expand tabs with 4 spaces in Python (and 2 spaces in Ruby), > the result is (switch to monospaced font): > > Python: > > some_func(param1, > param2, > param3) > > Ruby: > > some_func(param1, > param2, > param3) > > I see several different styles, it looks like it's pretty random, > sometimes I see the next line aligned: > > some_func(param1, > param2, > param3) > > I personally hate this one, cos when you have a very long line than it > looks like > > bla bla bla bla bla bla bla bla bla bla bla bla bla some_func(param1, > param2, > param3) > > and you obviously cannot use longer_param2 because it wraps. Also this > alignment does not work always (sometimes structure of the first line > does not have params). > > What is your preference in this case? > > http://micropoll.com/t/KE6MnZPqfS > > Do you see any other issues with our indenting or code style that we > should discuss? > From pchalupa at redhat.com Wed Aug 29 17:23:17 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 29 Aug 2012 19:23:17 +0200 Subject: [katello-devel] Foreman integration model question In-Reply-To: <503E28D9.6040203@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> <503511EC.1060701@redhat.com> <50364BE7.90504@redhat.com> <503DFB1E.3090008@redhat.com> <503E28D9.6040203@redhat.com> Message-ID: <503E5005.2060404@redhat.com> On 29.08.12 16:36, Dmitri Dolguikh wrote: > On 29/08/12 12:21 PM, Petr Chalupa wrote: >> >> >> On 23.08.12 17:27, Dmitri Dolguikh wrote: >>> On 22/08/12 06:07 PM, Justin Sherrill wrote: >>>> On 08/22/2012 08:26 AM, Petr Chalupa wrote: >>>>> Lukas is right, our motivation was to break the code into smaller >>>>> pieces (I am big fan of SOLID and 'single responsibility principle' >>>>> in particular). If you write code this way, you can then move things >>>>> around very quickly so you can develop features and fix bugs faster. >>>>> No to mention it can be testes more easily. >>>>> >>>>> app/models/user.rb (User) is representation of katello user which >>>>> mixes (if foreman is installed) foreman orchestration >>>>> app/models/glue/forema/user.rb. Orchestration is working with foreman >>>>> through children of ForemanModel which are representation of remote >>>>> resources app/models/foreman/user.rb (Foreman::User). Foreman::User >>>>> is using foreman-api bindings which are defined as singletons in >>>>> lib/resources/foreman.rb. >>>>> >>>>> So there are 4 layers: >>>>> - katello model >>>>> - foreman-katello orchestration >>>>> - foreman model (remote resource) >>>>> - foreman bindings (gem foreman-api) >>>>> >>>>> I also for splitting up big parts. >>>> I do like this auto generated api method better (aside from there >>>> being two distinct User models). To say a downside of the current >>>> model is a giant single file pulp.rb is kinda moot, as that was just >>>> how it was organized, we can organize it differently quite easily. >>>> What we are doing here with foreman is wayyyy more than just >>>> organizing it differently, its a fairly completely different way of >>>> orchestrating things, bypassing our lazy_accessor magic. >>> I will insist on using the orchestration layer for all access outside of >>> local model. Controller code shouldn't be aware of where a given model >>> attribute is, otherwise you are leaking orchestration outside of model. >> >> I am sorry I did not send an email about it before we started working >> on this. We had a discussion about it and we agreed that this is >> better approach, but we didn't feel that this is a big change. Sorry >> about that. I'll try to explain why I think this is better. >> >> The change is that we didn't use lazy_accessor but introduced new >> object representing remote resources. The reason is that katello >> models don't get any fatter. >> >> I agree that orchestration should be hidden from ActiveController. >> Because Foreman::User doesn't need to expose any of its attributes >> it's not clear how it would look like in KTEnvironment example. >> >> In KTEnvironment case it would look like this: >> >> There would be 4 files: >> - models/kt_environment.rb - class definition of katello model >> (KTEnvironment) >> - models/glue/foreman/kt_environment.rb - module defining foreman >> orchestration (Glue::Pulp::KTEnvironment) >> - models/foreman/kt_environment.rb - class definition of foreman >> remote resource (Foreman::KTEnvironment) >> - lib/resources/foreman.rb - defines singleton resource adapter using >> foreman_api (Resources::Foreman::KTEnvironment) >> >> Lets assume Foreman::KTEnvironment has two attributes :hidden and >> :exposed where :hidden should not be visible form ActiveController nad >> :exposed should. >> >> Then :hidden is hidden in Foreman::KTEnvironment and >> Foreman::KTEnvironment instance accesible from KTEnvironment instance >> should not be accessed directly, Foreman::KTEnvironment is private >> represantion managed by foreman orchestration >> (Glue::Pulp::KTEnvironment). >> >> To expose :exposed attribute in KTEnvironment you would define >> decelerators in Glue::Pulp::KTEnvironment: >> >> def exposed >> foreman.exposed >> end >> >> def exposed=(val) >> foreman.exposed = val >> end >> >> # or method .delegate can by used >> delegate :exposed, :exposed=, :to => :foreman >> >> :exposed is then accessible from ActiveController but everything else >> is hidden. > > Heh. I was thinking of something similar to encapsulate initialization > of remote attributes and possibly having a longer-living cache shared by > all remote attributes from a given sub-system. I would not introduce any cache until it's measured that this a real bottleneck and needs to be cached. Caches are often introducing hard-to-find bugs, I would avoid them as long as possible. > We could potentially leave the proxy object in place (instead of hiding > it behind a delegate) - it would serve as a notice of different call > semantic. > > -d >> >> We felt that foreman vs candlepin/pulp orchestration is clear enough >> border not to rise confusion. As I see it the drawback in consistency >> is much more less important than advantages of this approach: >> - no huge objects >> - easier testing >> - clearer distribution of responsibilities between objects >> >> +1 to keep the current approach >> >> I hope this is explaining motivation behind this. If you have more >> questions please ask. >> >> Petr >> >>> That aside, but why do we need to *generate* code in *ruby*? Does that >>> mean we have a lot of dumb code with very little logic in it? We can and >>> should do better. >>> >>> -d >>>> >>>> For example, lets say we do the same with environment, where there is >>>> a katello environment and a foreman environment. And lets say there >>>> is some special piece of information only stored in foreman (this is >>>> not a far-fetched scenario). >>>> >>>> With our current orchestration you would do something like: >>>> >>>> a = KTEnvironment.find(3) >>>> print a.remote_attribute >>>> a.remote_attribute = "foo" >>>> a.save! >>>> >>>> whereas the way i see it now, we'd have to do: >>>> >>>> a = KTEnvironment.find(3) >>>> a.foreman_user.remote_attribute = "foo" >>>> a.save! >>>> >>>> I don't really like this better as you'd have to remember which >>>> backend engine a particular attribute is. Today you don't. I don't >>>> really expect any of these arguments to change the way we are doing >>>> anything, its just annoying to change our entire way of working with a >>>> backend engine without any discussion :) >>>> >>>> We need to be aware that doing it this way is creating a 2nd way with >>>> working with fully (or partially) remote objects and that needs to be >>>> clear and apparent. It also needs to be justified :) >>>> >>>> -Justin >>>> >>>>> >>>>> Petr >>>>> >>>>> On 22.08.12 10:19, Lukas Zapletal wrote: >>>>>> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: >>>>>>> Taking user for example we would have: >>>>>>> >>>>>>> user.rb >>>>>>> glue/pulp/user.rb >>>>>> >>>>>> But you are missing one piece of the puzzle: >>>>>> >>>>>> lib/resources/pulp.rb (class User) >>>>>> >>>>>> And that is the piece which you can find in foreman/user.rb. >>>>>> >>>>>>> What I see with foreman is: >>>>>>> >>>>>>> user.rb >>>>>>> glue/foreman/user.rb >>>>>>> foreman/user.rb >>>>>> >>>>>> So instead having all the resources in a single class >>>>>> (lib/resources/foreman.rb), we are going to have (or better - >>>>>> generate) >>>>>> all resource (read also as "dumb") classes. Each in separate file. >>>>>> >>>>>>> Where foreman/user is a second class that can be instantiated and >>>>>>> used on its own, while glue/foreman/user.rb is simply the >>>>>>> orchestration to create that object. I see the use of >>>>>>> Resources::ForemanModel, but in this user instance the foreman user >>>>>>> could be manipulated completely apart from the katello user (which >>>>>>> is bad IMHO). This also is completely different from our existing >>>>>>> orchestration methods. >>>>>> >>>>>> Yes, it is different. I like this approach more. Creating a one >>>>>> instance >>>>>> per request is nothing, while the code is definitely better than >>>>>> eight >>>>>> hundred lines long pulp.rb with all the resources there as "class" >>>>>> methods. >>>>>> >>>>>> I think this is the correct approach and we may discuss splitting >>>>>> those >>>>>> big resource files in future into smaller pieces for other backend >>>>>> engines too. If we write a similar generator, we wont longer need to >>>>>> write them manually (and we will be able to track API changes too). >>>>>> >>>>>> I was not writing the code, but I believe those instances are treated >>>>>> like singletons, so you do not need to create instances by yourself: >>>>>> >>>>>> https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb >>>>>> >>>>>> >>>>>> >>>>>> Guys please elaborate what the intentions are. >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From ehelms at redhat.com Wed Aug 29 17:44:49 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 29 Aug 2012 13:44:49 -0400 Subject: [katello-devel] ConvergeUI Mailing List Message-ID: <503E5511.5020806@redhat.com> For those interested, a previous email that included links to the new ConvergeUI mailing list went to an incorrectly setup external mailing list. To subscribe to the correct email list follow the link below: https://www.redhat.com/mailman/listinfo/converge-ui-devel Also note on Freenode #converge-ui -Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuchy at redhat.com Wed Aug 29 17:50:39 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Wed, 29 Aug 2012 19:50:39 +0200 Subject: [katello-devel] Foreman integration model question In-Reply-To: <503E5005.2060404@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> <503511EC.1060701@redhat.com> <50364BE7.90504@redhat.com> <503DFB1E.3090008@redhat.com> <503E28D9.6040203@redhat.com> <503E5005.2060404@redhat.com> Message-ID: <503E566F.5090909@redhat.com> On 29.8.2012 19:23, Petr Chalupa wrote: > > I would not introduce any cache until it's measured that this a real > bottleneck and needs to be cached. Which reminds me performance tests... Oh never mind. Mirek From jsherril at redhat.com Wed Aug 29 18:39:05 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 29 Aug 2012 14:39:05 -0400 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503E4A45.2030300@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> <20120829102928.GD1405@lzapx.brq.redhat.com> <503E4A45.2030300@redhat.com> Message-ID: <503E61C9.4060503@redhat.com> On 08/29/2012 12:58 PM, Mike McCune wrote: > On 08/29/2012 03:29 AM, Lukas Zapletal wrote: >> On Tue, Aug 28, 2012 at 09:13:03AM -0700, Michael McCune wrote: >>> this violates our rule that: >>> >>> *** "All changes to content in any live environment must be through >>> a changeset" *** >> >> Now THATS a good point! >> >>> 3) Allow user to delete custom repositories in the Library and then >>> message them that in order to re-create any repositories with the >>> same name they will need to go through and execute changesets in >>> each of their environments to delete the repos from anywhere they >>> promoted to. >>> >>> We could auto create deletion changesets for them so all the changes >>> to the live environments would be tracked and done through our >>> existing mechanism. If people really want it we can allow the >>> "apply" to mass-execute the changesets in order. We would be >>> maintaining our existing rule above but allowing for an easier >>> mechanism to mass delete repositories >> >> The question is how would you create a deletion changeset when >> repository is already GONE? I mean, you can't really insert it there, >> there is nothing to apply. I don't get it. >> >> Maybe I just don't understand how delete promotions works atm. >> > > If you delete a custom repo from the Library right now from the GUI or > CLI the repo will still exist in all the environments you have > promoted to. So to delete the repos from say ... DEV/TEST/PROD after > you delete from the Library you just go in, create a 'deletion' > changeset in DEV/TEST/PROD and add the repos you previously deleted > from the Library to the Changeset. Then you apply that changeset and > the repos are now gone from that env. > > EG: > > 1) Create custom product, CP1 and environments: DEV/TEST > 2) Add 2 repos, repo1, repo2 > 3) sync to library > 4) promote CP1 to DEV, now you have repo1, repo2 in DEV > 5) promote CP2 to TEST, now you have repo1, repo2 in TEST > 6) Go into Custom Providers, delete repo2. Now repo2 is deleted from > the Library but still exists in DEV and TEST > 7) Create a Deletion Changeset in DEV, add repo2 to this changeset > 8) Apply the changeset, repo2 is now gone from DEV but still exists in > TEST > 9) Create a Deletion Changeset in TEST, add repo2 to this changeset > 10) Apply changeset, repo2 is now gone from TEST and exists nowhere > > This is how it works in master now today but after running through the > above scenario we are still getting that JDBC error so content > deletion is *not* cleaning something up correctly. Brad/myself can > take a look at why deleting all the repos from Library -> end of > promotion path is still leaving something in Candlepin Is this consistent with product deletion? -Justin > > Mike From mmccune at redhat.com Wed Aug 29 18:48:55 2012 From: mmccune at redhat.com (Mike McCune) Date: Wed, 29 Aug 2012 11:48:55 -0700 Subject: [katello-devel] deprecated repos removed Message-ID: <503E6417.5010409@redhat.com> We still had repos for Candlepin, Pulp and Katello at: http://fedorapeople.org/groups/katello/candlepin/ http://fedorapeople.org/groups/katello/pulp/ http://fedorapeople.org/groups/katello/katello/ which had old content that was causing confusion. I moved them to: http://fedorapeople.org/groups/katello/deprecated/ I will delete that in a week or so if the move doesn't cause any pain. everything RPM related should be in: http://fedorapeople.org/groups/katello/releases/ Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From bbuckingham at redhat.com Wed Aug 29 21:02:49 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Wed, 29 Aug 2012 17:02:49 -0400 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503E4A45.2030300@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> <20120829102928.GD1405@lzapx.brq.redhat.com> <503E4A45.2030300@redhat.com> Message-ID: <503E8379.8030808@redhat.com> On 08/29/2012 12:58 PM, Mike McCune wrote: > On 08/29/2012 03:29 AM, Lukas Zapletal wrote: >> On Tue, Aug 28, 2012 at 09:13:03AM -0700, Michael McCune wrote: >>> this violates our rule that: >>> >>> *** "All changes to content in any live environment must be through >>> a changeset" *** >> >> Now THATS a good point! >> >>> 3) Allow user to delete custom repositories in the Library and then >>> message them that in order to re-create any repositories with the >>> same name they will need to go through and execute changesets in >>> each of their environments to delete the repos from anywhere they >>> promoted to. >>> >>> We could auto create deletion changesets for them so all the changes >>> to the live environments would be tracked and done through our >>> existing mechanism. If people really want it we can allow the >>> "apply" to mass-execute the changesets in order. We would be >>> maintaining our existing rule above but allowing for an easier >>> mechanism to mass delete repositories >> >> The question is how would you create a deletion changeset when >> repository is already GONE? I mean, you can't really insert it there, >> there is nothing to apply. I don't get it. >> >> Maybe I just don't understand how delete promotions works atm. >> > > If you delete a custom repo from the Library right now from the GUI or > CLI the repo will still exist in all the environments you have > promoted to. So to delete the repos from say ... DEV/TEST/PROD after > you delete from the Library you just go in, create a 'deletion' > changeset in DEV/TEST/PROD and add the repos you previously deleted > from the Library to the Changeset. Then you apply that changeset and > the repos are now gone from that env. > > EG: > > 1) Create custom product, CP1 and environments: DEV/TEST > 2) Add 2 repos, repo1, repo2 > 3) sync to library > 4) promote CP1 to DEV, now you have repo1, repo2 in DEV > 5) promote CP2 to TEST, now you have repo1, repo2 in TEST > 6) Go into Custom Providers, delete repo2. Now repo2 is deleted from > the Library but still exists in DEV and TEST > 7) Create a Deletion Changeset in DEV, add repo2 to this changeset > 8) Apply the changeset, repo2 is now gone from DEV but still exists in > TEST > 9) Create a Deletion Changeset in TEST, add repo2 to this changeset > 10) Apply changeset, repo2 is now gone from TEST and exists nowhere > > This is how it works in master now today but after running through the > above scenario we are still getting that JDBC error so content > deletion is *not* cleaning something up correctly. Brad/myself can > take a look at why deleting all the repos from Library -> end of > promotion path is still leaving something in Candlepin > > Mike All, I took a brief look at the error that Mike mentioned above and it is the same one described in the bugzilla that Lukas is working on a solution for (i.e. https://bugzilla.redhat.com/show_bug.cgi?id=835875 ). (I didn't realize it was the same one until I ran through the reproducer.) What I observed was essentially what was mentioned in the bz and thread. When a user deletes a repository from Library, Katello cleans up content in candlepin's cp_product and cp_content tables; however, if the repository has been promoted to another environment (e.g. Dev), the records will remain in candlepin. This appears to be the reason the error is generated. Note, the following are the log references that perform that cleanup: Resource DELETE request: /candlepin/products/1346272223107/content/1346272248579 Resource DELETE request: /candlepin/content/1346272248579 We could possibly trigger the deletion of those records to also occur when deleting repositories from Library that were previously promoted; however, I wonder if that might cause problems when using the content that remains in the later environments (e.g. Dev, Test). For example, assume: 1. create provider/product/repo : zoo/zoo/zoo 2. sync repo: zoo 3. promote zoo product to dev & test When 1 occurs, the cp_product will get a record for 'zoo' and cp_content will get a record for 'ACME_Corporation_zoo_zoo'. There are no additional records created in these tables during 3; therefore, I wonder if this information needed for a consumer to be able to subscribe to and receive content from the dev and test environments? If so, we may want to prohibit deleting a repository from Library, if it has been promoted. This would essentially mean that Katello would need to warn the user that the content has been promoted to dev and test, the user would need to first delete it from those environments and then they may delete it from Library. thanks Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From lzap at redhat.com Thu Aug 30 08:52:31 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 30 Aug 2012 10:52:31 +0200 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503E8379.8030808@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> <20120829102928.GD1405@lzapx.brq.redhat.com> <503E4A45.2030300@redhat.com> <503E8379.8030808@redhat.com> Message-ID: <20120830085231.GB1440@lzapx.brq.redhat.com> On Wed, Aug 29, 2012 at 05:02:49PM -0400, Brad Buckingham wrote: > I took a brief look at the error that Mike mentioned above and it is > the same one described in the bugzilla that Lukas is working on a > solution for (i.e. > https://bugzilla.redhat.com/show_bug.cgi?id=835875 ). (I didn't > realize it was the same one until I ran through the reproducer.) > > What I observed was essentially what was mentioned in the bz and > thread. When a user deletes a repository from Library, Katello > cleans up content in candlepin's cp_product and cp_content tables; > however, if the repository has been promoted to another environment > (e.g. Dev), the records will remain in candlepin. This appears to > be the reason the error is generated. > > Note, the following are the log references that perform that cleanup: > Resource DELETE request: > /candlepin/products/1346272223107/content/1346272248579 > Resource DELETE request: /candlepin/content/1346272248579 > > We could possibly trigger the deletion of those records to also > occur when deleting repositories from Library that were previously > promoted; however, I wonder if that might cause problems when using > the content that remains in the later environments (e.g. Dev, Test). > > For example, assume: > 1. create provider/product/repo : zoo/zoo/zoo > 2. sync repo: zoo > 3. promote zoo product to dev & test > > When 1 occurs, the cp_product will get a record for 'zoo' and > cp_content will get a record for 'ACME_Corporation_zoo_zoo'. There > are no additional records created in these tables during 3; > therefore, I wonder if this information needed for a consumer to be > able to subscribe to and receive content from the dev and test > environments? If so, we may want to prohibit deleting a repository > from Library, if it has been promoted. This would essentially mean > that Katello would need to warn the user that the content has been > promoted to dev and test, the user would need to first delete it > from those environments and then they may delete it from Library. Brad++ what an analysis! So to test your assumption, I just need to consume some content from an environment after the content is deleted from the Library, right? If this is confirmed, we are back to the scenario 1 - just don't let user to delete it until it's promoted. Opinions? -- Later, Lukas "lzap" Zapletal #katello #systemengine From pchalupa at redhat.com Thu Aug 30 10:29:46 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Thu, 30 Aug 2012 12:29:46 +0200 Subject: [katello-devel] Foreman integration model question In-Reply-To: <503DFB1E.3090008@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> <503511EC.1060701@redhat.com> <50364BE7.90504@redhat.com> <503DFB1E.3090008@redhat.com> Message-ID: <503F409A.9000007@redhat.com> Pull request for foreman integration was created https://github.com/Katello/katello/pull/546 On 29.08.12 13:21, Petr Chalupa wrote: > > > On 23.08.12 17:27, Dmitri Dolguikh wrote: >> On 22/08/12 06:07 PM, Justin Sherrill wrote: >>> On 08/22/2012 08:26 AM, Petr Chalupa wrote: >>>> Lukas is right, our motivation was to break the code into smaller >>>> pieces (I am big fan of SOLID and 'single responsibility principle' >>>> in particular). If you write code this way, you can then move things >>>> around very quickly so you can develop features and fix bugs faster. >>>> No to mention it can be testes more easily. >>>> >>>> app/models/user.rb (User) is representation of katello user which >>>> mixes (if foreman is installed) foreman orchestration >>>> app/models/glue/forema/user.rb. Orchestration is working with foreman >>>> through children of ForemanModel which are representation of remote >>>> resources app/models/foreman/user.rb (Foreman::User). Foreman::User >>>> is using foreman-api bindings which are defined as singletons in >>>> lib/resources/foreman.rb. >>>> >>>> So there are 4 layers: >>>> - katello model >>>> - foreman-katello orchestration >>>> - foreman model (remote resource) >>>> - foreman bindings (gem foreman-api) >>>> >>>> I also for splitting up big parts. >>> I do like this auto generated api method better (aside from there >>> being two distinct User models). To say a downside of the current >>> model is a giant single file pulp.rb is kinda moot, as that was just >>> how it was organized, we can organize it differently quite easily. >>> What we are doing here with foreman is wayyyy more than just >>> organizing it differently, its a fairly completely different way of >>> orchestrating things, bypassing our lazy_accessor magic. >> I will insist on using the orchestration layer for all access outside of >> local model. Controller code shouldn't be aware of where a given model >> attribute is, otherwise you are leaking orchestration outside of model. > > I am sorry I did not send an email about it before we started working on > this. We had a discussion about it and we agreed that this is better > approach, but we didn't feel that this is a big change. Sorry about > that. I'll try to explain why I think this is better. > > The change is that we didn't use lazy_accessor but introduced new object > representing remote resources. The reason is that katello models don't > get any fatter. > > I agree that orchestration should be hidden from ActiveController. > Because Foreman::User doesn't need to expose any of its attributes it's > not clear how it would look like in KTEnvironment example. > > In KTEnvironment case it would look like this: > > There would be 4 files: > - models/kt_environment.rb - class definition of katello model > (KTEnvironment) > - models/glue/foreman/kt_environment.rb - module defining foreman > orchestration (Glue::Pulp::KTEnvironment) > - models/foreman/kt_environment.rb - class definition of foreman remote > resource (Foreman::KTEnvironment) > - lib/resources/foreman.rb - defines singleton resource adapter using > foreman_api (Resources::Foreman::KTEnvironment) > > Lets assume Foreman::KTEnvironment has two attributes :hidden and > :exposed where :hidden should not be visible form ActiveController nad > :exposed should. > > Then :hidden is hidden in Foreman::KTEnvironment and > Foreman::KTEnvironment instance accesible from KTEnvironment instance > should not be accessed directly, Foreman::KTEnvironment is private > represantion managed by foreman orchestration (Glue::Pulp::KTEnvironment). > > To expose :exposed attribute in KTEnvironment you would define > decelerators in Glue::Pulp::KTEnvironment: > > def exposed > foreman.exposed > end > > def exposed=(val) > foreman.exposed = val > end > > # or method .delegate can by used > delegate :exposed, :exposed=, :to => :foreman > > :exposed is then accessible from ActiveController but everything else is > hidden. > > We felt that foreman vs candlepin/pulp orchestration is clear enough > border not to rise confusion. As I see it the drawback in consistency is > much more less important than advantages of this approach: > - no huge objects > - easier testing > - clearer distribution of responsibilities between objects > > +1 to keep the current approach > > I hope this is explaining motivation behind this. If you have more > questions please ask. > > Petr > >> That aside, but why do we need to *generate* code in *ruby*? Does that >> mean we have a lot of dumb code with very little logic in it? We can and >> should do better. >> >> -d >>> >>> For example, lets say we do the same with environment, where there is >>> a katello environment and a foreman environment. And lets say there >>> is some special piece of information only stored in foreman (this is >>> not a far-fetched scenario). >>> >>> With our current orchestration you would do something like: >>> >>> a = KTEnvironment.find(3) >>> print a.remote_attribute >>> a.remote_attribute = "foo" >>> a.save! >>> >>> whereas the way i see it now, we'd have to do: >>> >>> a = KTEnvironment.find(3) >>> a.foreman_user.remote_attribute = "foo" >>> a.save! >>> >>> I don't really like this better as you'd have to remember which >>> backend engine a particular attribute is. Today you don't. I don't >>> really expect any of these arguments to change the way we are doing >>> anything, its just annoying to change our entire way of working with a >>> backend engine without any discussion :) >>> >>> We need to be aware that doing it this way is creating a 2nd way with >>> working with fully (or partially) remote objects and that needs to be >>> clear and apparent. It also needs to be justified :) >>> >>> -Justin >>> >>>> >>>> Petr >>>> >>>> On 22.08.12 10:19, Lukas Zapletal wrote: >>>>> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: >>>>>> Taking user for example we would have: >>>>>> >>>>>> user.rb >>>>>> glue/pulp/user.rb >>>>> >>>>> But you are missing one piece of the puzzle: >>>>> >>>>> lib/resources/pulp.rb (class User) >>>>> >>>>> And that is the piece which you can find in foreman/user.rb. >>>>> >>>>>> What I see with foreman is: >>>>>> >>>>>> user.rb >>>>>> glue/foreman/user.rb >>>>>> foreman/user.rb >>>>> >>>>> So instead having all the resources in a single class >>>>> (lib/resources/foreman.rb), we are going to have (or better - >>>>> generate) >>>>> all resource (read also as "dumb") classes. Each in separate file. >>>>> >>>>>> Where foreman/user is a second class that can be instantiated and >>>>>> used on its own, while glue/foreman/user.rb is simply the >>>>>> orchestration to create that object. I see the use of >>>>>> Resources::ForemanModel, but in this user instance the foreman user >>>>>> could be manipulated completely apart from the katello user (which >>>>>> is bad IMHO). This also is completely different from our existing >>>>>> orchestration methods. >>>>> >>>>> Yes, it is different. I like this approach more. Creating a one >>>>> instance >>>>> per request is nothing, while the code is definitely better than eight >>>>> hundred lines long pulp.rb with all the resources there as "class" >>>>> methods. >>>>> >>>>> I think this is the correct approach and we may discuss splitting >>>>> those >>>>> big resource files in future into smaller pieces for other backend >>>>> engines too. If we write a similar generator, we wont longer need to >>>>> write them manually (and we will be able to track API changes too). >>>>> >>>>> I was not writing the code, but I believe those instances are treated >>>>> like singletons, so you do not need to create instances by yourself: >>>>> >>>>> https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb >>>>> >>>>> >>>>> >>>>> Guys please elaborate what the intentions are. >>>>> >>>> >>>> _______________________________________________ >>>> 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 dmitri at redhat.com Thu Aug 30 10:52:38 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 30 Aug 2012 11:52:38 +0100 Subject: [katello-devel] Foreman integration model question In-Reply-To: <503E5005.2060404@redhat.com> References: <5033D818.5090203@redhat.com> <20120822081950.GA3044@lzapx.brq.redhat.com> <5034CFE5.1080702@redhat.com> <503511EC.1060701@redhat.com> <50364BE7.90504@redhat.com> <503DFB1E.3090008@redhat.com> <503E28D9.6040203@redhat.com> <503E5005.2060404@redhat.com> Message-ID: <503F45F6.9010108@redhat.com> On 29/08/12 06:23 PM, Petr Chalupa wrote: > > > On 29.08.12 16:36, Dmitri Dolguikh wrote: >> On 29/08/12 12:21 PM, Petr Chalupa wrote: >>> >>> >>> On 23.08.12 17:27, Dmitri Dolguikh wrote: >>>> On 22/08/12 06:07 PM, Justin Sherrill wrote: >>>>> On 08/22/2012 08:26 AM, Petr Chalupa wrote: >>>>>> Lukas is right, our motivation was to break the code into smaller >>>>>> pieces (I am big fan of SOLID and 'single responsibility principle' >>>>>> in particular). If you write code this way, you can then move things >>>>>> around very quickly so you can develop features and fix bugs faster. >>>>>> No to mention it can be testes more easily. >>>>>> >>>>>> app/models/user.rb (User) is representation of katello user which >>>>>> mixes (if foreman is installed) foreman orchestration >>>>>> app/models/glue/forema/user.rb. Orchestration is working with >>>>>> foreman >>>>>> through children of ForemanModel which are representation of remote >>>>>> resources app/models/foreman/user.rb (Foreman::User). Foreman::User >>>>>> is using foreman-api bindings which are defined as singletons in >>>>>> lib/resources/foreman.rb. >>>>>> >>>>>> So there are 4 layers: >>>>>> - katello model >>>>>> - foreman-katello orchestration >>>>>> - foreman model (remote resource) >>>>>> - foreman bindings (gem foreman-api) >>>>>> >>>>>> I also for splitting up big parts. >>>>> I do like this auto generated api method better (aside from there >>>>> being two distinct User models). To say a downside of the current >>>>> model is a giant single file pulp.rb is kinda moot, as that was just >>>>> how it was organized, we can organize it differently quite easily. >>>>> What we are doing here with foreman is wayyyy more than just >>>>> organizing it differently, its a fairly completely different way of >>>>> orchestrating things, bypassing our lazy_accessor magic. >>>> I will insist on using the orchestration layer for all access >>>> outside of >>>> local model. Controller code shouldn't be aware of where a given model >>>> attribute is, otherwise you are leaking orchestration outside of >>>> model. >>> >>> I am sorry I did not send an email about it before we started working >>> on this. We had a discussion about it and we agreed that this is >>> better approach, but we didn't feel that this is a big change. Sorry >>> about that. I'll try to explain why I think this is better. >>> >>> The change is that we didn't use lazy_accessor but introduced new >>> object representing remote resources. The reason is that katello >>> models don't get any fatter. >>> >>> I agree that orchestration should be hidden from ActiveController. >>> Because Foreman::User doesn't need to expose any of its attributes >>> it's not clear how it would look like in KTEnvironment example. >>> >>> In KTEnvironment case it would look like this: >>> >>> There would be 4 files: >>> - models/kt_environment.rb - class definition of katello model >>> (KTEnvironment) >>> - models/glue/foreman/kt_environment.rb - module defining foreman >>> orchestration (Glue::Pulp::KTEnvironment) >>> - models/foreman/kt_environment.rb - class definition of foreman >>> remote resource (Foreman::KTEnvironment) >>> - lib/resources/foreman.rb - defines singleton resource adapter using >>> foreman_api (Resources::Foreman::KTEnvironment) >>> >>> Lets assume Foreman::KTEnvironment has two attributes :hidden and >>> :exposed where :hidden should not be visible form ActiveController nad >>> :exposed should. >>> >>> Then :hidden is hidden in Foreman::KTEnvironment and >>> Foreman::KTEnvironment instance accesible from KTEnvironment instance >>> should not be accessed directly, Foreman::KTEnvironment is private >>> represantion managed by foreman orchestration >>> (Glue::Pulp::KTEnvironment). >>> >>> To expose :exposed attribute in KTEnvironment you would define >>> decelerators in Glue::Pulp::KTEnvironment: >>> >>> def exposed >>> foreman.exposed >>> end >>> >>> def exposed=(val) >>> foreman.exposed = val >>> end >>> >>> # or method .delegate can by used >>> delegate :exposed, :exposed=, :to => :foreman >>> >>> :exposed is then accessible from ActiveController but everything else >>> is hidden. >> >> Heh. I was thinking of something similar to encapsulate initialization >> of remote attributes and possibly having a longer-living cache shared by >> all remote attributes from a given sub-system. > > I would not introduce any cache until it's measured that this a real > bottleneck and needs to be cached. Caches are often introducing > hard-to-find bugs, I would avoid them as long as possible. Optimization should be done only when needed. Katello is slow, when we are orchestrating two remote systems, and we are adding another. I think we need to discuss how to speed up the whole thing (caching of http responses is a straightforward route to take), not how to avoid caching. As I said it in the private conversation - the answer is more tests and better tests, not avoiding useful features because of the fear of breaking things. > >> We could potentially leave the proxy object in place (instead of hiding >> it behind a delegate) - it would serve as a notice of different call >> semantic. >> >> -d >>> >>> We felt that foreman vs candlepin/pulp orchestration is clear enough >>> border not to rise confusion. As I see it the drawback in consistency >>> is much more less important than advantages of this approach: >>> - no huge objects >>> - easier testing >>> - clearer distribution of responsibilities between objects >>> >>> +1 to keep the current approach >>> >>> I hope this is explaining motivation behind this. If you have more >>> questions please ask. >>> >>> Petr >>> >>>> That aside, but why do we need to *generate* code in *ruby*? Does that >>>> mean we have a lot of dumb code with very little logic in it? We >>>> can and >>>> should do better. >>>> >>>> -d >>>>> >>>>> For example, lets say we do the same with environment, where there is >>>>> a katello environment and a foreman environment. And lets say there >>>>> is some special piece of information only stored in foreman (this is >>>>> not a far-fetched scenario). >>>>> >>>>> With our current orchestration you would do something like: >>>>> >>>>> a = KTEnvironment.find(3) >>>>> print a.remote_attribute >>>>> a.remote_attribute = "foo" >>>>> a.save! >>>>> >>>>> whereas the way i see it now, we'd have to do: >>>>> >>>>> a = KTEnvironment.find(3) >>>>> a.foreman_user.remote_attribute = "foo" >>>>> a.save! >>>>> >>>>> I don't really like this better as you'd have to remember which >>>>> backend engine a particular attribute is. Today you don't. I don't >>>>> really expect any of these arguments to change the way we are doing >>>>> anything, its just annoying to change our entire way of working >>>>> with a >>>>> backend engine without any discussion :) >>>>> >>>>> We need to be aware that doing it this way is creating a 2nd way with >>>>> working with fully (or partially) remote objects and that needs to be >>>>> clear and apparent. It also needs to be justified :) >>>>> >>>>> -Justin >>>>> >>>>>> >>>>>> Petr >>>>>> >>>>>> On 22.08.12 10:19, Lukas Zapletal wrote: >>>>>>> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote: >>>>>>>> Taking user for example we would have: >>>>>>>> >>>>>>>> user.rb >>>>>>>> glue/pulp/user.rb >>>>>>> >>>>>>> But you are missing one piece of the puzzle: >>>>>>> >>>>>>> lib/resources/pulp.rb (class User) >>>>>>> >>>>>>> And that is the piece which you can find in foreman/user.rb. >>>>>>> >>>>>>>> What I see with foreman is: >>>>>>>> >>>>>>>> user.rb >>>>>>>> glue/foreman/user.rb >>>>>>>> foreman/user.rb >>>>>>> >>>>>>> So instead having all the resources in a single class >>>>>>> (lib/resources/foreman.rb), we are going to have (or better - >>>>>>> generate) >>>>>>> all resource (read also as "dumb") classes. Each in separate file. >>>>>>> >>>>>>>> Where foreman/user is a second class that can be instantiated and >>>>>>>> used on its own, while glue/foreman/user.rb is simply the >>>>>>>> orchestration to create that object. I see the use of >>>>>>>> Resources::ForemanModel, but in this user instance the foreman >>>>>>>> user >>>>>>>> could be manipulated completely apart from the katello user (which >>>>>>>> is bad IMHO). This also is completely different from our existing >>>>>>>> orchestration methods. >>>>>>> >>>>>>> Yes, it is different. I like this approach more. Creating a one >>>>>>> instance >>>>>>> per request is nothing, while the code is definitely better than >>>>>>> eight >>>>>>> hundred lines long pulp.rb with all the resources there as "class" >>>>>>> methods. >>>>>>> >>>>>>> I think this is the correct approach and we may discuss splitting >>>>>>> those >>>>>>> big resource files in future into smaller pieces for other backend >>>>>>> engines too. If we write a similar generator, we wont longer >>>>>>> need to >>>>>>> write them manually (and we will be able to track API changes too). >>>>>>> >>>>>>> I was not writing the code, but I believe those instances are >>>>>>> treated >>>>>>> like singletons, so you do not need to create instances by >>>>>>> yourself: >>>>>>> >>>>>>> https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Guys please elaborate what the intentions are. >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> _______________________________________________ >> 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 Thu Aug 30 12:27:56 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 30 Aug 2012 08:27:56 -0400 Subject: [katello-devel] Demotions and deletions In-Reply-To: <20120830085231.GB1440@lzapx.brq.redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> <20120829102928.GD1405@lzapx.brq.redhat.com> <503E4A45.2030300@redhat.com> <503E8379.8030808@redhat.com> <20120830085231.GB1440@lzapx.brq.redhat.com> Message-ID: <503F5C4C.1000904@redhat.com> On 08/30/2012 04:52 AM, Lukas Zapletal wrote: > On Wed, Aug 29, 2012 at 05:02:49PM -0400, Brad Buckingham wrote: >> I took a brief look at the error that Mike mentioned above and it is >> the same one described in the bugzilla that Lukas is working on a >> solution for (i.e. >> https://bugzilla.redhat.com/show_bug.cgi?id=835875 ). (I didn't >> realize it was the same one until I ran through the reproducer.) >> >> What I observed was essentially what was mentioned in the bz and >> thread. When a user deletes a repository from Library, Katello >> cleans up content in candlepin's cp_product and cp_content tables; >> however, if the repository has been promoted to another environment >> (e.g. Dev), the records will remain in candlepin. This appears to >> be the reason the error is generated. >> >> Note, the following are the log references that perform that cleanup: >> Resource DELETE request: >> /candlepin/products/1346272223107/content/1346272248579 >> Resource DELETE request: /candlepin/content/1346272248579 >> >> We could possibly trigger the deletion of those records to also >> occur when deleting repositories from Library that were previously >> promoted; however, I wonder if that might cause problems when using >> the content that remains in the later environments (e.g. Dev, Test). >> >> For example, assume: >> 1. create provider/product/repo : zoo/zoo/zoo >> 2. sync repo: zoo >> 3. promote zoo product to dev & test >> >> When 1 occurs, the cp_product will get a record for 'zoo' and >> cp_content will get a record for 'ACME_Corporation_zoo_zoo'. There >> are no additional records created in these tables during 3; >> therefore, I wonder if this information needed for a consumer to be >> able to subscribe to and receive content from the dev and test >> environments? If so, we may want to prohibit deleting a repository >> from Library, if it has been promoted. This would essentially mean >> that Katello would need to warn the user that the content has been >> promoted to dev and test, the user would need to first delete it >> from those environments and then they may delete it from Library. > > Brad++ what an analysis! > > So to test your assumption, I just need to consume some content from an > environment after the content is deleted from the Library, right? > > If this is confirmed, we are back to the scenario 1 - just don't let > user to delete it until it's promoted. > > Opinions? > unitl its promoted? Or, you have to delete the promotions and then you can delete the repo? -- bk From lzap at redhat.com Thu Aug 30 12:40:45 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 30 Aug 2012 14:40:45 +0200 Subject: [katello-devel] ApiDocs link in the webui Message-ID: <20120830124045.GE10928@lzapx.brq.redhat.com> Hey, just wondering - do we have a link in the UI for API docs? LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Thu Aug 30 12:42:31 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 30 Aug 2012 14:42:31 +0200 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503F5C4C.1000904@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> <20120829102928.GD1405@lzapx.brq.redhat.com> <503E4A45.2030300@redhat.com> <503E8379.8030808@redhat.com> <20120830085231.GB1440@lzapx.brq.redhat.com> <503F5C4C.1000904@redhat.com> Message-ID: <20120830124231.GF10928@lzapx.brq.redhat.com> On Thu, Aug 30, 2012 at 08:27:56AM -0400, Bryan Kearney wrote: > >If this is confirmed, we are back to the scenario 1 - just don't let > >user to delete it until it's promoted. > > > unitl its promoted? Or, you have to delete the promotions and then > you can delete the repo? Sorry bad word. Don't let user to delete already promoted content. -- Later, Lukas "lzap" Zapletal #katello #systemengine From bbuckingham at redhat.com Thu Aug 30 12:59:57 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Thu, 30 Aug 2012 08:59:57 -0400 Subject: [katello-devel] Demotions and deletions In-Reply-To: <20120830085231.GB1440@lzapx.brq.redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> <20120829102928.GD1405@lzapx.brq.redhat.com> <503E4A45.2030300@redhat.com> <503E8379.8030808@redhat.com> <20120830085231.GB1440@lzapx.brq.redhat.com> Message-ID: <503F63CD.4000509@redhat.com> On 08/30/2012 04:52 AM, Lukas Zapletal wrote: > On Wed, Aug 29, 2012 at 05:02:49PM -0400, Brad Buckingham wrote: >> I took a brief look at the error that Mike mentioned above and it is >> the same one described in the bugzilla that Lukas is working on a >> solution for (i.e. >> https://bugzilla.redhat.com/show_bug.cgi?id=835875 ). (I didn't >> realize it was the same one until I ran through the reproducer.) >> >> What I observed was essentially what was mentioned in the bz and >> thread. When a user deletes a repository from Library, Katello >> cleans up content in candlepin's cp_product and cp_content tables; >> however, if the repository has been promoted to another environment >> (e.g. Dev), the records will remain in candlepin. This appears to >> be the reason the error is generated. >> >> Note, the following are the log references that perform that cleanup: >> Resource DELETE request: >> /candlepin/products/1346272223107/content/1346272248579 >> Resource DELETE request: /candlepin/content/1346272248579 >> >> We could possibly trigger the deletion of those records to also >> occur when deleting repositories from Library that were previously >> promoted; however, I wonder if that might cause problems when using >> the content that remains in the later environments (e.g. Dev, Test). >> >> For example, assume: >> 1. create provider/product/repo : zoo/zoo/zoo >> 2. sync repo: zoo >> 3. promote zoo product to dev& test >> >> When 1 occurs, the cp_product will get a record for 'zoo' and >> cp_content will get a record for 'ACME_Corporation_zoo_zoo'. There >> are no additional records created in these tables during 3; >> therefore, I wonder if this information needed for a consumer to be >> able to subscribe to and receive content from the dev and test >> environments? If so, we may want to prohibit deleting a repository >> from Library, if it has been promoted. This would essentially mean >> that Katello would need to warn the user that the content has been >> promoted to dev and test, the user would need to first delete it >> from those environments and then they may delete it from Library. > Brad++ what an analysis! > > So to test your assumption, I just need to consume some content from an > environment after the content is deleted from the Library, right? [brad] Hey Lukas, correct. I'd probably try the following: 1. assume the repo has been promoted to dev 2. register system1 to dev, subscribe to repo, consume some content 3. delete repo from library 4. register system2 to dev, subscribe to repo 5. consumer content from system1 and system2 The reason for the difference in 2 and 4 is that I'd want to make sure that the subscribing still works after the repo is deleted from library. > If this is confirmed, we are back to the scenario 1 - just don't let > user to delete it until it's promoted. > > Opinions? > From bkearney at redhat.com Thu Aug 30 13:21:17 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 30 Aug 2012 09:21:17 -0400 Subject: [katello-devel] ApiDocs link in the webui In-Reply-To: <503F6201.80106@redhat.com> References: <20120830124045.GE10928@lzapx.brq.redhat.com> <503F6201.80106@redhat.com> Message-ID: <503F68CD.4090704@redhat.com> On 08/30/2012 08:52 AM, Bryan Kearney wrote: > On 08/30/2012 08:40 AM, Lukas Zapletal wrote: >> Hey, >> >> just wondering - do we have a link in the UI for API docs? >> >> LZ >> > Not that I know of. Is there a way to test if the api package is > installed and add it? > > -- bk > From lzap at redhat.com Thu Aug 30 13:22:40 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 30 Aug 2012 15:22:40 +0200 Subject: [katello-devel] ApiDocs link in the webui In-Reply-To: <503F68CD.4090704@redhat.com> References: <20120830124045.GE10928@lzapx.brq.redhat.com> <503F6201.80106@redhat.com> <503F68CD.4090704@redhat.com> Message-ID: <20120830132240.GH10928@lzapx.brq.redhat.com> I would add an initializer checking for a directory. That would do it. LZ On Thu, Aug 30, 2012 at 09:21:17AM -0400, Bryan Kearney wrote: > On 08/30/2012 08:52 AM, Bryan Kearney wrote: > >On 08/30/2012 08:40 AM, Lukas Zapletal wrote: > >>Hey, > >> > >>just wondering - do we have a link in the UI for API docs? > >> > >>LZ > >> > >Not that I know of. Is there a way to test if the api package is > >installed and add it? > > > >-- bk > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From gkhachik at redhat.com Thu Aug 30 13:23:10 2012 From: gkhachik at redhat.com (Garik Khachikyan) Date: Thu, 30 Aug 2012 15:23:10 +0200 Subject: [katello-devel] ApiDocs link in the webui In-Reply-To: <20120830124045.GE10928@lzapx.brq.redhat.com> References: <20120830124045.GE10928@lzapx.brq.redhat.com> Message-ID: <503F693E.1010902@redhat.com> On 30/08/12 14:40, Lukas Zapletal wrote: > Hey, > > just wondering - do we have a link in the UI for API docs? > > LZ > if you looking for: katello/apidoc ? From lzap at redhat.com Thu Aug 30 13:25:34 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 30 Aug 2012 15:25:34 +0200 Subject: [katello-devel] ApiDocs link in the webui In-Reply-To: <503F693E.1010902@redhat.com> References: <20120830124045.GE10928@lzapx.brq.redhat.com> <503F693E.1010902@redhat.com> Message-ID: <20120830132534.GJ10928@lzapx.brq.redhat.com> On Thu, Aug 30, 2012 at 03:23:10PM +0200, Garik Khachikyan wrote: > if you looking for: katello/apidoc ? Well in Satellite there is a link. I mean, customers maybe won't notice we have this superb documentation. Just a self-promotion :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From vvaldez at redhat.com Thu Aug 30 19:56:20 2012 From: vvaldez at redhat.com (Vincent Valdez) Date: Thu, 30 Aug 2012 15:56:20 -0400 (EDT) Subject: [katello-devel] pymongo In-Reply-To: <503E4452.5030700@redhat.com> References: <503DBDB1.3020200@redhat.com> <503E4452.5030700@redhat.com> Message-ID: <0FF908B1-65FD-49A1-8D7E-0D0C0677DDF3@redhat.com> On Aug 29, 2012, at 11:33 AM, Mike McCune wrote: > On 08/28/2012 11:58 PM, Miroslav Suchy wrote: >> I just finished watching: >> Using Katello: Part 1 - Initial Setup >> http://www.youtube.com/watch?v=hDWvQBpa5UU >> and I'm courious - what is that issue with pymongo? >> >> Why we are talking about that in screencast, but there is nothing >> mentioned in wiki:Install and why it is not specified in rpm Requires? >> >> Mirek > > he is speaking to this open issue: > > https://bugzilla.redhat.com/show_bug.cgi?id=843800#c3 Exactly, using a newly updated F16 was causing synch issues with the openoffice packages until I downgraded as mentioned here: http://pulpproject.org/ug/UGFAQ.html#rpmname Should I add an annotation to the video, or remove that part? Vinny > > -- > Mike McCune > mmccune AT redhat.com > Red Hat Engineering | Portland, OR > Systems Management | 650-254-4248 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From ehelms at redhat.com Fri Aug 31 11:55:30 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 31 Aug 2012 07:55:30 -0400 (EDT) Subject: [katello-devel] Katello Website Code Released Message-ID: <718356597.16172116.1346414130526.JavaMail.root@redhat.com> Previously due to the early development and the way configuration lived on OpenShift for our new Wordpress based website, the code was relegated to living on our OpenShift instance. This configuration no longer lives in the repository and I have thus pushed out the code to Github for local hacking and updating. If you would like push access to the OpenShift hosted site please contact me directly. https://github.com/Katello/katello-website Thanks, -Eric From mmccune at redhat.com Fri Aug 31 15:07:38 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 31 Aug 2012 08:07:38 -0700 Subject: [katello-devel] Katello Website Code Released In-Reply-To: <718356597.16172116.1346414130526.JavaMail.root@redhat.com> References: <718356597.16172116.1346414130526.JavaMail.root@redhat.com> Message-ID: <5040D33A.1000906@redhat.com> On 08/31/2012 04:55 AM, Eric Helms wrote: > Previously due to the early development and the way configuration lived on OpenShift for our new Wordpress based website, the code was relegated to living on our OpenShift instance. This configuration no longer lives in the repository and I have thus pushed out the code to Github for local hacking and updating. If you would like push access to the OpenShift hosted site please contact me directly. > > https://github.com/Katello/katello-website > > Thanks, > -Eric > nice, thanks! From lzap at redhat.com Fri Aug 31 15:27:27 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 31 Aug 2012 17:27:27 +0200 Subject: [katello-devel] Demotions and deletions In-Reply-To: <503F63CD.4000509@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <503CB51B.9060002@redhat.com> <503CBFF7.9030500@redhat.com> <503CC610.7010003@redhat.com> <503CEE0F.6000800@redhat.com> <20120829102928.GD1405@lzapx.brq.redhat.com> <503E4A45.2030300@redhat.com> <503E8379.8030808@redhat.com> <20120830085231.GB1440@lzapx.brq.redhat.com> <503F63CD.4000509@redhat.com> Message-ID: <20120831152727.GG3902@lzapx.brq.redhat.com> On Thu, Aug 30, 2012 at 08:59:57AM -0400, Brad Buckingham wrote: > 1. assume the repo has been promoted to dev > 2. register system1 to dev, subscribe to repo, consume some content > 3. delete repo from library > 4. register system2 to dev, subscribe to repo > 5. consumer content from system1 and system2 So I tested this scenario and it works, both systems are able to consume content after I delete the repository from Library without any issues. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Aug 31 15:59:40 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 31 Aug 2012 17:59:40 +0200 Subject: [katello-devel] Demotions and deletions - solution In-Reply-To: <20120828102947.GB1383@lzapx.brq.redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> Message-ID: <20120831155940.GH3902@lzapx.brq.redhat.com> After chat with Brad, we came to conclusion there are two good solution: A) Do not let user to delete a repo that has promoted content A) Do not allow a user to delete a repo that has been promoted... in this case, give the user a strong warning that it must first be deleted from A,B,C environments B) Allow users to delete repos. When creating a repo, first check if the name is already used in any environment. If so, do not let user to create the repo telling him/her he need to choose a different one or to delete all repositories with that name using changesets. C) B + auto create deletion changeset when deleting repos. This is what Mike recommend I guess plus with the B check. (*) (*) The question is do we want to auto create for ALL possible environment paths? That could be lots of changesets. Maybe to do this optional, or maybe even a separate command/action. Something like "recursive promote". LZ On Tue, Aug 28, 2012 at 12:29:47PM +0200, Lukas Zapletal wrote: > Hey, > > stumbled upon a bug (https://bugzilla.redhat.com/show_bug.cgi?id=835875) > that prevents you from creating a repository with a same name that has > been deleted (but promoted). > > Now the question - we now do support demotions (those promotions > opposite - not sure about wording). Therefore I guess the proper > solution would be to check if the repository (*) was already promoted. > If so, Katello will refuse to delete the object asking user to do the > demotion. > > Opinions? > > (*) this should apply to anything that is promotable: > > - product > - repo > - template > - package > - erratum > - distribution > > -- > 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 paji at redhat.com Fri Aug 31 21:02:55 2012 From: paji at redhat.com (Partha Aji) Date: Fri, 31 Aug 2012 17:02:55 -0400 (EDT) Subject: [katello-devel] Repo i18n names question In-Reply-To: <2062603714.2116685.1346446707856.JavaMail.root@redhat.com> Message-ID: <1456187225.2117460.1346446975068.JavaMail.root@redhat.com> So I started working on a bz which had issues syncing repos with i18n names. But I can't even create those in the UI since repo names and id are tied up and pulp won't let me create repos with i18n characters in its id. I saw the whole thread on this topic https://www.redhat.com/archives/katello-devel/2012-June/msg00084.html, but don't think its been addressed yet. I want to reopen this topic for suggestions. Please let me know if any of the issues below have already been addressed or being addressed. 1) Do we want an immutable label for repo name that is ascii based or are we auto generating ids based on some magical 2) What happens to pulp repos that already have i18n ids. Does pulp have some mechanism to upgrade those to "ascii" names ? Partha From bbuckingham at redhat.com Fri Aug 31 21:08:19 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Fri, 31 Aug 2012 17:08:19 -0400 Subject: [katello-devel] Demotions and deletions - solution In-Reply-To: <20120831155940.GH3902@lzapx.brq.redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <20120831155940.GH3902@lzapx.brq.redhat.com> Message-ID: <504127C3.6070005@redhat.com> Given that deleting a repo (from the custom providers screen) after the it has been promoted, puts the server in a state where you cannot recreate a repo with the same name, I lean towards something like the following in the short-term: 1. If the user attempts to delete a repo (from providers screen) and the repo was not previously promoted, allow the deletion to occur. 2. If the user attempts to delete a repo (from providers screen) and the repo was previously promoted: a. Do not allow the repo to be deleted. A couple of ways this could be handled might be: i. Disable the 'remove' link so the user doesn't have the option. Add a tipsy next to the remove link that when hovered the user can be given information on 'why' the remove link is disabled. (e.g. "Before removing this repo from the product, it must first be deleted from the following environments using a deletion changeset: A, B, C.") ii. Allow the user to click the link, but provide them a dialog similar to the one mentioned in i. above. b. Update the code such that once the last instance of the repo is deleted from the environment paths, it is also removed from candlepin (e.g. cp_product/cp_content). I.e. this is currently done today for 1; however, in order to address the jdbc error described in the bugzilla, we need to do the same in cases where the repo has been promoted. In the longer-term, we need investigate and provide a more robust solution similar to what Mike described to make it easier for users to delete the repo from multiple or all environments (after it has been promoted). For example, we could auto-create deletion changesets (as suggested previously), provide the ability to execute multiple changesets in some predefined order...etc. On 08/31/2012 11:59 AM, Lukas Zapletal wrote: > After chat with Brad, we came to conclusion there are two good solution: > > A) Do not let user to delete a repo that has promoted content > > A) Do not allow a user to delete a repo that has been promoted... in > this case, give the user a strong warning that it must first be deleted > from A,B,C environments > > B) Allow users to delete repos. When creating a repo, first check if the > name is already used in any environment. If so, do not let user to > create the repo telling him/her he need to choose a different one or to > delete all repositories with that name using changesets. > > C) B + auto create deletion changeset when deleting repos. This is what > Mike recommend I guess plus with the B check. (*) > > (*) The question is do we want to auto create for ALL possible > environment paths? That could be lots of changesets. Maybe to do this > optional, or maybe even a separate command/action. Something like > "recursive promote". > > LZ > > > On Tue, Aug 28, 2012 at 12:29:47PM +0200, Lukas Zapletal wrote: >> Hey, >> >> stumbled upon a bug (https://bugzilla.redhat.com/show_bug.cgi?id=835875) >> that prevents you from creating a repository with a same name that has >> been deleted (but promoted). >> >> Now the question - we now do support demotions (those promotions >> opposite - not sure about wording). Therefore I guess the proper >> solution would be to check if the repository (*) was already promoted. >> If so, Katello will refuse to delete the object asking user to do the >> demotion. >> >> Opinions? >> >> (*) this should apply to anything that is promotable: >> >> - product >> - repo >> - template >> - package >> - erratum >> - distribution >> >> -- >> Later, >> >> Lukas "lzap" Zapletal >> #katello #systemengine >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Fri Aug 31 21:24:41 2012 From: mmccune at redhat.com (Mike McCune) Date: Fri, 31 Aug 2012 14:24:41 -0700 Subject: [katello-devel] Demotions and deletions - solution In-Reply-To: <504127C3.6070005@redhat.com> References: <20120828102947.GB1383@lzapx.brq.redhat.com> <20120831155940.GH3902@lzapx.brq.redhat.com> <504127C3.6070005@redhat.com> Message-ID: <50412B99.9070703@redhat.com> On 08/31/2012 02:08 PM, Brad Buckingham wrote: > Given that deleting a repo (from the custom providers screen) after > the it has been promoted, puts the server in a state where you > cannot recreate a repo with the same name, I lean towards something > like the following in the short-term: > > 1. If the user attempts to delete a repo (from providers screen) and the > repo was not previously promoted, allow the deletion to occur. > > 2. If the user attempts to delete a repo (from providers screen) and the > repo was previously promoted: > > a. Do not allow the repo to be deleted. A couple of ways this could be > handled might be: > > i. Disable the 'remove' link so the user doesn't have the option. > Add a tipsy next to the remove link that when hovered the > user can > be given information on 'why' the remove link is disabled. > (e.g. > "Before removing this repo from the product, it must first > be deleted > from the following environments using a deletion changeset: > A, B, C.") > +1 to (i) > ii. Allow the user to click the link, but provide them a dialog > similar to > the one mentioned in i. above. > > b. Update the code such that once the last instance of the repo is > deleted > from the environment paths, it is also removed from candlepin > (e.g. cp_product/cp_content). I.e. this is currently done > today for 1; > however, in order to address the jdbc error described in the > bugzilla, > we need to do the same in cases where the repo has been promoted. > > In the longer-term, we need investigate and provide a more robust > solution similar > to what Mike described to make it easier for users to delete the repo > from multiple or all environments (after it has been promoted). For > example, > we could auto-create deletion changesets (as suggested previously), provide > the ability to execute multiple changesets in some predefined order...etc. > +1 to the above approach. it will be relatively clear to the user and there is a path to actually delete the repo. Mike > > On 08/31/2012 11:59 AM, Lukas Zapletal wrote: >> After chat with Brad, we came to conclusion there are two good solution: >> >> A) Do not let user to delete a repo that has promoted content >> >> A) Do not allow a user to delete a repo that has been promoted... in >> this case, give the user a strong warning that it must first be deleted >> from A,B,C environments >> >> B) Allow users to delete repos. When creating a repo, first check if the >> name is already used in any environment. If so, do not let user to >> create the repo telling him/her he need to choose a different one or to >> delete all repositories with that name using changesets. >> >> C) B + auto create deletion changeset when deleting repos. This is what >> Mike recommend I guess plus with the B check. (*) >> >> (*) The question is do we want to auto create for ALL possible >> environment paths? That could be lots of changesets. Maybe to do this >> optional, or maybe even a separate command/action. Something like >> "recursive promote". >> >> LZ >> >> >> On Tue, Aug 28, 2012 at 12:29:47PM +0200, Lukas Zapletal wrote: >>> Hey, >>> >>> stumbled upon a bug (https://bugzilla.redhat.com/show_bug.cgi?id=835875) >>> that prevents you from creating a repository with a same name that has >>> been deleted (but promoted). >>> >>> Now the question - we now do support demotions (those promotions >>> opposite - not sure about wording). Therefore I guess the proper >>> solution would be to check if the repository (*) was already promoted. >>> If so, Katello will refuse to delete the object asking user to do the >>> demotion. >>> >>> Opinions? >>> >>> (*) this should apply to anything that is promotable: >>> >>> - product >>> - repo >>> - template >>> - package >>> - erratum >>> - distribution >>> >>> -- >>> 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 -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248