From tsanders at redhat.com Mon May 16 14:05:49 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Mon, 16 May 2011 10:05:49 -0400 Subject: [katello-devel] Testing....1....2....3 Message-ID: <4DD12F3D.5090207@redhat.com> Is this thing on? -Todd From dmitri at redhat.com Mon May 16 18:19:43 2011 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 16 May 2011 15:19:43 -0300 Subject: [katello-devel] pls. upgrade to pulp version 0.0.177 Message-ID: <4DD16ABF.706@redhat.com> I updated Katello-backend to use new repository urls (which do not have repository type in them). The change is in b34127b0c7416add1a073ed4ebc6174844fe8f38. Please make sure to update your pulp to version 0.0.177 before/after pulling in this change. Cheers, -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkearney at redhat.com Mon May 16 20:44:29 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 16 May 2011 16:44:29 -0400 Subject: [katello-devel] Current roles/permissions in the seeds file Message-ID: <4DD18CAD.7000909@redhat.com> I put in the facts table from SAM, and I noticed that I needed to add a role/permission to the seed data for this to work. Here is the diff: -Role.allow 'admin_role', { :systems => [:index, :create, :new, :edit, :show, :update, :destroy,:packages, :subscriptions,:update_subscriptions] +Role.allow 'admin_role', { :systems => [:index, :create, :new, :edit, :show, :update, :destroy,:packages, :subscriptions,:update_subscriptions, :facts] Can I assume that we want to move away from UI centric permission such as this? I would assume that we would put :systems => :read around the following controller actions: :show, :subscriptions, :facts To do this, we would need to change how the ApplicationController works, but it will move us to more business permissions which work across the CLI and the UI. Is this correct, or off base? -- bk From lzap at redhat.com Tue May 17 11:18:14 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 17 May 2011 13:18:14 +0200 Subject: [katello-devel] Current roles/permissions in the seeds file In-Reply-To: <4DD18CAD.7000909@redhat.com> References: <4DD18CAD.7000909@redhat.com> Message-ID: <4DD25976.3060203@redhat.com> On 05/16/2011 10:44 PM, Bryan Kearney wrote: > To do this, we would need to change how the ApplicationController works, > but it will move us to more business permissions which work across the > CLI and the UI. Is this correct, or off base? That's what we've agreed on. The current approach is taken from the Foreman. Nice thing is it works automatic - every action is protected and no checking code is necessary. It also allows separate rules for UI and API which turns out to be disadvantage for us. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From bkearney at redhat.com Tue May 17 12:18:49 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 17 May 2011 08:18:49 -0400 Subject: [katello-devel] Current roles/permissions in the seeds file In-Reply-To: <4DD25976.3060203@redhat.com> References: <4DD18CAD.7000909@redhat.com> <4DD25976.3060203@redhat.com> Message-ID: <4DD267A9.1020607@redhat.com> On 05/17/2011 07:18 AM, Lukas Zapletal wrote: > On 05/16/2011 10:44 PM, Bryan Kearney wrote: >> To do this, we would need to change how the ApplicationController works, >> but it will move us to more business permissions which work across the >> CLI and the UI. Is this correct, or off base? > > That's what we've agreed on. > > The current approach is taken from the Foreman. Nice thing is it works > automatic - every action is protected and no checking code is necessary. > It also allows separate rules for UI and API which turns out to be > disadvantage for us. > Ok.. so what I have on the backlog below is replacing that? # As a dev, I'd like to protect ActiveRecord? resources 1. Design and implement API for AR resoures 2. Align with the current REST resources API 1. unify the approach (tags) so single checking code can be used 3. Change the way how static permissions are stored from multiple Permission records to one with multiple Verb records 1.Update documentation on the wiki # Add CRUD permission checks to all Glue model objects. -- bk From lzap at redhat.com Tue May 17 12:25:42 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 17 May 2011 14:25:42 +0200 Subject: [katello-devel] Current roles/permissions in the seeds file In-Reply-To: <4DD267A9.1020607@redhat.com> References: <4DD18CAD.7000909@redhat.com> <4DD25976.3060203@redhat.com> <4DD267A9.1020607@redhat.com> Message-ID: <4DD26946.7010806@redhat.com> On 05/17/2011 02:18 PM, Bryan Kearney wrote: > On 05/17/2011 07:18 AM, Lukas Zapletal wrote: >> On 05/16/2011 10:44 PM, Bryan Kearney wrote: >>> To do this, we would need to change how the ApplicationController works, >>> but it will move us to more business permissions which work across the >>> CLI and the UI. Is this correct, or off base? >> >> That's what we've agreed on. >> >> The current approach is taken from the Foreman. Nice thing is it works >> automatic - every action is protected and no checking code is necessary. >> It also allows separate rules for UI and API which turns out to be >> disadvantage for us. >> > Ok.. so what I have on the backlog below is replacing that? > > # As a dev, I'd like to protect ActiveRecord? resources > > 1. Design and implement API for AR resoures > 2. Align with the current REST resources API > 1. unify the approach (tags) so single checking code can be used > 3. Change the way how static permissions are stored from multiple > Permission records to one with multiple Verb records 1.Update > documentation on the wiki > > # Add CRUD permission checks to all Glue model objects. > > -- bk > Here is what I sent you recently, marking with [***] As a dev, I'd like to protect ActiveRecord resources - Design and implement API for AR resoures - Align with the current REST resources API - unify the approach (tags) so single checking code can be used - Change the way how static permissions are stored - from multiple Permission records to one with multiple Verb records - Update documentation on the wiki As a dev, I'd like to unify UI and API protection [***] - Move the protection layer from UI controllers to glue layer OR - Add protection of API controllers - Update documentation on the wiki As a dev, I'd like to have security design document - Design out roles and permissions for UI - Design out roles and permissions for API Obviously its the former option. But prior to that we need to unify and clean our glue layer. Using the former option means there must not be any business code before the check is executed. This implies there should not be any business code in our controller's actions. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From bkearney at redhat.com Tue May 17 15:19:58 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 17 May 2011 11:19:58 -0400 Subject: [katello-devel] Content Set Prepending Message-ID: <4DD2921E.2000404@redhat.com> I want to verify my understanding of a change we need to make to Candlepin. Today, when loading a subscription manifest, it comes with a repository URL. Lets say it is /super/cool/content Katello will configure pulp to expose this repo for an owner, in an environment. Lets assume ACME has DEV, TEST, PROD. Pulp will expose the following urls: /ACME/DEV/super/cool/content /ACME/TEST/super/cool/content /ACME/PROD/super/cool/content I believe the plan is for subscription manager to receive a content set which looks like: /$owner/$env/super/cool/content and to expand the variables. Is that correct? If so, I believe the requirement on Candlepin is to be able to prefix all content sets with a standard prefix before generating the certificates. Does this sound incorrect to anyone? -- bk From bkearney at redhat.com Tue May 17 15:55:36 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 17 May 2011 11:55:36 -0400 Subject: [katello-devel] Current roles/permissions in the seeds file In-Reply-To: <4DD26946.7010806@redhat.com> References: <4DD18CAD.7000909@redhat.com> <4DD25976.3060203@redhat.com> <4DD267A9.1020607@redhat.com> <4DD26946.7010806@redhat.com> Message-ID: <4DD29A78.5060908@redhat.com> On 05/17/2011 08:25 AM, Lukas Zapletal wrote: > On 05/17/2011 02:18 PM, Bryan Kearney wrote: >> On 05/17/2011 07:18 AM, Lukas Zapletal wrote: >>> On 05/16/2011 10:44 PM, Bryan Kearney wrote: >>>> To do this, we would need to change how the ApplicationController >>>> works, >>>> but it will move us to more business permissions which work across the >>>> CLI and the UI. Is this correct, or off base? >>> >>> That's what we've agreed on. >>> >>> The current approach is taken from the Foreman. Nice thing is it works >>> automatic - every action is protected and no checking code is necessary. >>> It also allows separate rules for UI and API which turns out to be >>> disadvantage for us. >>> >> Ok.. so what I have on the backlog below is replacing that? >> >> # As a dev, I'd like to protect ActiveRecord? resources >> >> 1. Design and implement API for AR resoures >> 2. Align with the current REST resources API >> 1. unify the approach (tags) so single checking code can be used >> 3. Change the way how static permissions are stored from multiple >> Permission records to one with multiple Verb records 1.Update >> documentation on the wiki >> >> # Add CRUD permission checks to all Glue model objects. >> >> -- bk >> > > Here is what I sent you recently, marking with [***] > > As a dev, I'd like to protect ActiveRecord resources > - Design and implement API for AR resoures > - Align with the current REST resources API > - unify the approach (tags) so single checking code can be used > - Change the way how static permissions are stored > - from multiple Permission records to one with multiple Verb records > - Update documentation on the wiki ok.. these are in.. good. > > As a dev, I'd like to unify UI and API protection [***] > - Move the protection layer from UI controllers to glue layer > OR > - Add protection of API controllers > - Update documentation on the wiki So.. this is the design choice to make.. one or the other.. got it. > > As a dev, I'd like to have security design document > - Design out roles and permissions for UI > - Design out roles and permissions for API There should only be one set of roles.. yes? -- bk From mmccune at redhat.com Tue May 17 16:13:53 2011 From: mmccune at redhat.com (Mike McCune) Date: Tue, 17 May 2011 09:13:53 -0700 Subject: [katello-devel] Content Set Prepending In-Reply-To: <4DD2921E.2000404@redhat.com> References: <4DD2921E.2000404@redhat.com> Message-ID: <4DD29EC1.2070005@redhat.com> On 05/17/2011 08:19 AM, Bryan Kearney wrote: > I want to verify my understanding of a change we need to make to Candlepin. > > Today, when loading a subscription manifest, it comes with a repository > URL. Lets say it is > > /super/cool/content > > Katello will configure pulp to expose this repo for an owner, in an > environment. Lets assume ACME has DEV, TEST, PROD. Pulp will expose the > following urls: > > /ACME/DEV/super/cool/content > /ACME/TEST/super/cool/content > /ACME/PROD/super/cool/content > > I believe the plan is for subscription manager to receive a content set > which looks like: > > /$owner/$env/super/cool/content > > and to expand the variables. Is that correct? > > If so, I believe the requirement on Candlepin is to be able to prefix > all content sets with a standard prefix before generating the > certificates. Does this sound incorrect to anyone? > the above is the way it should work but I'm not certain it is all working the way you describe yet, specifically with the way we are exposing the cloned repos to include the environment in the path. what we need to make sure we do is to set the relativepath field on the repos to include the environment: --relativepath=RELATIVE_PATH relative path where the repository is stored and exposed to clients; this defaults to feed path if not specified (repository must be empty) Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From wpoteat at redhat.com Tue May 17 19:05:42 2011 From: wpoteat at redhat.com (William Poteat) Date: Tue, 17 May 2011 15:05:42 -0400 Subject: [katello-devel] Content Set Prepending In-Reply-To: <4DD29EC1.2070005@redhat.com> References: <4DD2921E.2000404@redhat.com> <4DD29EC1.2070005@redhat.com> Message-ID: <4DD2C706.8070406@redhat.com> On 05/17/2011 12:13 PM, Mike McCune wrote: > On 05/17/2011 08:19 AM, Bryan Kearney wrote: >> I want to verify my understanding of a change we need to make to >> Candlepin. >> >> Today, when loading a subscription manifest, it comes with a repository >> URL. Lets say it is >> >> /super/cool/content >> >> Katello will configure pulp to expose this repo for an owner, in an >> environment. Lets assume ACME has DEV, TEST, PROD. Pulp will expose the >> following urls: >> >> /ACME/DEV/super/cool/content >> /ACME/TEST/super/cool/content >> /ACME/PROD/super/cool/content >> >> I believe the plan is for subscription manager to receive a content set >> which looks like: >> >> /$owner/$env/super/cool/content >> >> and to expand the variables. Is that correct? >> >> If so, I believe the requirement on Candlepin is to be able to prefix >> all content sets with a standard prefix before generating the >> certificates. Does this sound incorrect to anyone? >> > > the above is the way it should work but I'm not certain it is all > working the way you describe yet, specifically with the way we are > exposing the cloned repos to include the environment in the path. > > what we need to make sure we do is to set the relativepath field on > the repos to include the environment: > > --relativepath=RELATIVE_PATH > relative path where the repository is stored and > exposed to clients; this defaults to feed path > if not > specified (repository must be empty) > > Mike So both URL's [Content URL and GPG Url] need to be prepended with /$owner/$env/ when retrieved from CP? -- +-----------------------------+ William Poteat Senior Software Engineer Red Hat 919.890.8823 Phone 919.830.7189 Cell wpoteat at redhat.com +-----------------------------+ From bkearney at redhat.com Tue May 17 19:25:14 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 17 May 2011 15:25:14 -0400 Subject: [katello-devel] Content Set Prepending In-Reply-To: <4DD2C706.8070406@redhat.com> References: <4DD2921E.2000404@redhat.com> <4DD29EC1.2070005@redhat.com> <4DD2C706.8070406@redhat.com> Message-ID: <4DD2CB9A.6040402@redhat.com> On 05/17/2011 03:05 PM, William Poteat wrote: > On 05/17/2011 12:13 PM, Mike McCune wrote: >> On 05/17/2011 08:19 AM, Bryan Kearney wrote: >>> I want to verify my understanding of a change we need to make to >>> Candlepin. >>> >>> Today, when loading a subscription manifest, it comes with a repository >>> URL. Lets say it is >>> >>> /super/cool/content >>> >>> Katello will configure pulp to expose this repo for an owner, in an >>> environment. Lets assume ACME has DEV, TEST, PROD. Pulp will expose the >>> following urls: >>> >>> /ACME/DEV/super/cool/content >>> /ACME/TEST/super/cool/content >>> /ACME/PROD/super/cool/content >>> >>> I believe the plan is for subscription manager to receive a content set >>> which looks like: >>> >>> /$owner/$env/super/cool/content >>> >>> and to expand the variables. Is that correct? >>> >>> If so, I believe the requirement on Candlepin is to be able to prefix >>> all content sets with a standard prefix before generating the >>> certificates. Does this sound incorrect to anyone? >>> >> >> the above is the way it should work but I'm not certain it is all >> working the way you describe yet, specifically with the way we are >> exposing the cloned repos to include the environment in the path. >> >> what we need to make sure we do is to set the relativepath field on >> the repos to include the environment: >> >> --relativepath=RELATIVE_PATH >> relative path where the repository is stored and >> exposed to clients; this defaults to feed path if not >> specified (repository must be empty) >> >> Mike > So both URL's [Content URL and GPG Url] need to be prepended with > /$owner/$env/ when retrieved from CP? > hmmm... Good question... I thought GPG tended to be a file url. Is that not correct? -- bk From lzap at redhat.com Wed May 18 08:18:52 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 May 2011 10:18:52 +0200 Subject: [katello-devel] Current roles/permissions in the seeds file In-Reply-To: <4DD29A78.5060908@redhat.com> References: <4DD18CAD.7000909@redhat.com> <4DD25976.3060203@redhat.com> <4DD267A9.1020607@redhat.com> <4DD26946.7010806@redhat.com> <4DD29A78.5060908@redhat.com> Message-ID: <4DD380EC.5060601@redhat.com> On 05/17/2011 05:55 PM, Bryan Kearney wrote: > > So.. this is the design choice to make.. one or the other.. got it. Yeah sorry, was not so obvious. >> As a dev, I'd like to have security design document >> - Design out roles and permissions for UI >> - Design out roles and permissions for API > > There should only be one set of roles.. yes? Yes, something like that. It's not part of our requirements document AFAIK. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From lzap at redhat.com Wed May 18 09:47:03 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 May 2011 11:47:03 +0200 Subject: [katello-devel] New config value: rest_client_timeout Message-ID: <4DD39597.6010108@redhat.com> Hello all, I just added new config value rest_client_timeout. Defaults to 60 secs in production and 2 secs in development. It sets both read and open HTTP timeouts. Good for timeout debugging :-) LZ -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From jsherril at redhat.com Wed May 18 15:12:38 2011 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 18 May 2011 11:12:38 -0400 Subject: [katello-devel] Proposed change to meaning of an environment's "current changeset" Message-ID: <4DD3E1E6.80401@redhat.com> Hi, So currently an environment has a changeset (KPEnvironment#changeset) and a changeset history (KPEnvironment#changeset_history). Say we have environments A->B->C Currently the meaning of B.changeset is the set of content that will be promoted FROM B TO C. That is when you promote the changeset in B everything is added to C. I'm proposing a change to make it so that B.changeset is actually the content that will be promoted FROM A to B. To me it makes more sense logically as B.changeset is the changeset for B, not for C. This really comes into play with multiple paths, as currently the Locker only has 1 changeset for an environment. So it doesn't really work if you can promote from locker to multiple places. That is: Locker -> A Locker -> B Today, we only have Locker.changeset, so the same changeset used when deciding what content should be promoted to A or to B doesn't really make any sense. Most of the work is actually front end work (changing the promotions page) which we need to do to add the environment selector widget anyways. -Justin From bkearney at redhat.com Wed May 18 15:34:41 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 May 2011 11:34:41 -0400 Subject: [katello-devel] Proposed change to meaning of an environment's "current changeset" In-Reply-To: <4DD3E1E6.80401@redhat.com> References: <4DD3E1E6.80401@redhat.com> Message-ID: <4DD3E711.50900@redhat.com> On 05/18/2011 11:12 AM, Justin Sherrill wrote: > Hi, > > So currently an environment has a changeset (KPEnvironment#changeset) > and a changeset history (KPEnvironment#changeset_history). > > Say we have environments A->B->C > > Currently the meaning of B.changeset is the set of content that will be > promoted FROM B TO C. That is when you promote the changeset in B > everything is added to C. > > > I'm proposing a change to make it so that B.changeset is actually the > content that will be promoted FROM A to B. To me it makes more sense > logically as B.changeset is the changeset for B, not for C. > > This really comes into play with multiple paths, as currently the Locker > only has 1 changeset for an environment. So it doesn't really work if > you can promote from locker to multiple places. That is: > > Locker -> A > Locker -> B > > Today, we only have Locker.changeset, so the same changeset used when > deciding what content should be promoted to A or to B doesn't really > make any sense. > Why does this not make sense? If my changeset is "Latest RHEL" I could see wanting to move it to both A and B. Is hte issue that we are getting too fancy looking into the next environemnt to see what to move? If so, I would be willing to hold back on that stuff. -- bk From jsherril at redhat.com Wed May 18 15:53:13 2011 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 18 May 2011 11:53:13 -0400 Subject: [katello-devel] Proposed change to meaning of an environment's "current changeset" In-Reply-To: <4DD3E711.50900@redhat.com> References: <4DD3E1E6.80401@redhat.com> <4DD3E711.50900@redhat.com> Message-ID: <4DD3EB69.5080300@redhat.com> On 05/18/2011 11:34 AM, Bryan Kearney wrote: > On 05/18/2011 11:12 AM, Justin Sherrill wrote: >> Hi, >> >> So currently an environment has a changeset (KPEnvironment#changeset) >> and a changeset history (KPEnvironment#changeset_history). >> >> Say we have environments A->B->C >> >> Currently the meaning of B.changeset is the set of content that will be >> promoted FROM B TO C. That is when you promote the changeset in B >> everything is added to C. >> >> >> I'm proposing a change to make it so that B.changeset is actually the >> content that will be promoted FROM A to B. To me it makes more sense >> logically as B.changeset is the changeset for B, not for C. >> >> This really comes into play with multiple paths, as currently the Locker >> only has 1 changeset for an environment. So it doesn't really work if >> you can promote from locker to multiple places. That is: >> >> Locker -> A >> Locker -> B >> >> Today, we only have Locker.changeset, so the same changeset used when >> deciding what content should be promoted to A or to B doesn't really >> make any sense. >> > > Why does this not make sense? If my changeset is "Latest RHEL" I could > see wanting to move it to both A and B. > > Is hte issue that we are getting too fancy looking into the next > environemnt to see what to move? If so, I would be willing to hold > back on that stuff. > > -- bk That could make sense, but the current promotion UI is not really designed around that. We had discussed re-using changesets as well, so you could 'copy' a changeset to allow you to re-use them when promoting through a path. No reason you couldn't reuse them across paths. To me it doesn't make sense to have Locker only have a single changeset, because say Admin1 goes and prepares a changeset for Environment A but waits to promote it, admin 1 (or any other user) can't prepare another changeset for B until the first one is promoted. For that one case where a user would want to promote a changeset into 2 environments, he could copy as i mention above, or we could incorporate the copy into the promotion process, so he'd still be promoting to two environments, it would just be copying the changeset and promoting for B as well in a single step (so this change does not preclude your use case necessarily). We also don't allow you to select some content for a changeset if it already exists in the 'next' environment. This would allow you to select content for A that already exists in B and then promote it to B. It seems more confusing to the user if the locker's working changeset is shared across the next environments. -Justin From mmccune at redhat.com Wed May 18 17:34:44 2011 From: mmccune at redhat.com (Mike McCune) Date: Wed, 18 May 2011 10:34:44 -0700 Subject: [katello-devel] New config value: rest_client_timeout In-Reply-To: <4DD39597.6010108@redhat.com> References: <4DD39597.6010108@redhat.com> Message-ID: <4DD40334.2000606@redhat.com> On 05/18/2011 02:47 AM, Lukas Zapletal wrote: > Hello all, > > I just added new config value rest_client_timeout. Defaults to 60 secs > in production and 2 secs in development. It sets both read and open HTTP > timeouts. > > Good for timeout debugging :-) > > LZ > I tried in master to reset my data but got this during rake setup: == AddChangesetPromotionDate: migrating ====================================== -- add_column(:changesets, :promotion_date, :datetime) -> 0.0011s == AddChangesetPromotionDate: migrated (0.0012s) ============================= rake aborted! uncaught throw `Unable to create first org: baseFailed to create candlepin owner ACME_Corporation: Request Timeout' I bumped it up to 20 locally and it worked fine. Perhaps 2 is a bit too short? Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From bkearney at redhat.com Wed May 18 17:50:24 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 May 2011 13:50:24 -0400 Subject: [katello-devel] User Integration between Katello and Candlepin Message-ID: <4DD406E0.7020603@redhat.com> Per the discussion, this is my understanding: 1) Katello with authenticate vs. LDAP or an onboard store. 2) Katello will pass requests to Candlepin via oauth. 3) Katello will use the cp-user header to pass the actual user name. 4) Candlepin will have no user data, and will not be configured to use LDAP. 5) Candlepin will create a principal for that user, and give the user a "Trusted" Role. In this way, Katello owns all Authn/Authz but Candlepin can still audit who is doing waht. Is the above model correct? Would the same model work for pulp? Would the same model work for foreman? -- bk From bkearney at redhat.com Wed May 18 19:00:41 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 May 2011 15:00:41 -0400 Subject: [katello-devel] Admin user? Message-ID: <4DD41759.3050908@redhat.com> A bug was opened about an admin user. What are folks thoughts on this: 1) Have an admin user which is backed by a config file even if the candlepin is set up to LDAP? 2) Trust the user to not be an idiot and delete the admin user. If they do, use DB tools to fix it. -- bk From jrist at redhat.com Wed May 18 19:24:17 2011 From: jrist at redhat.com (Jason Rist) Date: Wed, 18 May 2011 13:24:17 -0600 Subject: [katello-devel] Admin user? In-Reply-To: <4DD41759.3050908@redhat.com> References: <4DD41759.3050908@redhat.com> Message-ID: <4DD41CE1.3030406@redhat.com> On 05/18/2011 01:00 PM, Bryan Kearney wrote: > A bug was opened about an admin user. What are folks thoughts on this: > > 1) Have an admin user which is backed by a config file even if the > candlepin is set up to LDAP? > 2) Trust the user to not be an idiot and delete the admin user. If they > do, use DB tools to fix it. > > -- bk > I don't think we should trust the user to not delete it. -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 Wed May 18 20:52:31 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 May 2011 22:52:31 +0200 Subject: [katello-devel] New config value: rest_client_timeout In-Reply-To: <4DD40334.2000606@redhat.com> References: <4DD39597.6010108@redhat.com> <4DD40334.2000606@redhat.com> Message-ID: <4DD4318F.9010805@redhat.com> On 05/18/2011 07:34 PM, Mike McCune wrote: > rake aborted! > uncaught throw `Unable to create first org: baseFailed to create > candlepin owner ACME_Corporation: Request Timeout' > > I bumped it up to 20 locally and it worked fine. Perhaps 2 is a bit too > short? Ah sorry about that. Thats too short. Lemme not to override it for development. I can do myself when I need. Pushing the change in our default configuration now. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From bkearney at redhat.com Wed May 18 21:02:38 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 18 May 2011 17:02:38 -0400 Subject: [katello-devel] Admin user? In-Reply-To: <4DD41CE1.3030406@redhat.com> References: <4DD41759.3050908@redhat.com> <4DD41CE1.3030406@redhat.com> Message-ID: <4DD433EE.2070202@redhat.com> On 05/18/2011 03:24 PM, Jason Rist wrote: > On 05/18/2011 01:00 PM, Bryan Kearney wrote: >> A bug was opened about an admin user. What are folks thoughts on this: >> >> 1) Have an admin user which is backed by a config file even if the >> candlepin is set up to LDAP? >> 2) Trust the user to not be an idiot and delete the admin user. If they >> do, use DB tools to fix it. >> >> -- bk >> > > I don't think we should trust the user to not delete it. > > -J > yes, but if they can use DB tools to fix it.. it may be ok. I am also concerned about the setup. What if the users selects LDAP.. we may not have a user with the correct permissions to log in. Perhaps LDAP is used except for what is in the local table? -- bk From lzap at redhat.com Wed May 18 21:01:24 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 18 May 2011 23:01:24 +0200 Subject: [katello-devel] Admin user? In-Reply-To: <4DD433EE.2070202@redhat.com> References: <4DD41759.3050908@redhat.com> <4DD41CE1.3030406@redhat.com> <4DD433EE.2070202@redhat.com> Message-ID: <4DD433A4.90306@redhat.com> On 05/18/2011 11:02 PM, Bryan Kearney wrote: >> > yes, but if they can use DB tools to fix it.. it may be ok. > > I am also concerned about the setup. What if the users selects LDAP.. we > may not have a user with the correct permissions to log in. Perhaps LDAP > is used except for what is in the local table? My understanding of LDAP "mode" is that local users always override. Means that during all auth/auth stuff local tables are consulted first and if not found then LDAP search is done. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From lzap at redhat.com Thu May 19 06:45:50 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 May 2011 08:45:50 +0200 Subject: [katello-devel] Admin user? In-Reply-To: <4DD41759.3050908@redhat.com> References: <4DD41759.3050908@redhat.com> Message-ID: <4DD4BC9E.6080108@redhat.com> On 05/18/2011 09:00 PM, Bryan Kearney wrote: > 1) Have an admin user which is backed by a config file even if the > candlepin is set up to LDAP? > 2) Trust the user to not be an idiot and delete the admin user. If they > do, use DB tools to fix it. Or maybe 3) Add "locked" column to the user table which could prevent from deleting. We wont allow the user to change it. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From tsanders at redhat.com Thu May 19 11:27:50 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Thu, 19 May 2011 07:27:50 -0400 Subject: [katello-devel] Admin user? In-Reply-To: <4DD433A4.90306@redhat.com> References: <4DD41759.3050908@redhat.com> <4DD41CE1.3030406@redhat.com> <4DD433EE.2070202@redhat.com> <4DD433A4.90306@redhat.com> Message-ID: <4DD4FEB6.708@redhat.com> On 05/18/2011 05:01 PM, Lukas Zapletal wrote: > On 05/18/2011 11:02 PM, Bryan Kearney wrote: >>> >> yes, but if they can use DB tools to fix it.. it may be ok. >> >> I am also concerned about the setup. What if the users selects LDAP.. we >> may not have a user with the correct permissions to log in. Perhaps LDAP >> is used except for what is in the local table? > > My understanding of LDAP "mode" is that local users always override. > Means that during all auth/auth stuff local tables are consulted first > and if not found then LDAP search is done. > +1 This is my understanding as well. -Todd From tsanders at redhat.com Thu May 19 11:29:11 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Thu, 19 May 2011 07:29:11 -0400 Subject: [katello-devel] Admin user? In-Reply-To: <4DD4BC9E.6080108@redhat.com> References: <4DD41759.3050908@redhat.com> <4DD4BC9E.6080108@redhat.com> Message-ID: <4DD4FF07.2050909@redhat.com> On 05/19/2011 02:45 AM, Lukas Zapletal wrote: > On 05/18/2011 09:00 PM, Bryan Kearney wrote: >> 1) Have an admin user which is backed by a config file even if the >> candlepin is set up to LDAP? >> 2) Trust the user to not be an idiot and delete the admin user. If they >> do, use DB tools to fix it. > > Or maybe 3) Add "locked" column to the user table which could prevent > from deleting. We wont allow the user to change it. > > Or atleast prevent the user from removing the *last* user with "admin" privileges. -Todd From lzap at redhat.com Thu May 19 11:38:19 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 May 2011 13:38:19 +0200 Subject: [katello-devel] CLI command expanding question Message-ID: <4DD5012B.3040706@redhat.com> Hello, there's task to expand certain cli commands (like prov -> provider) and I agree with that. It's better to define bash completition. But I have a question: Do we want to expand parameters as well? I mean --org=XXX or --prov=YYY. It makes sense to me. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From lzap at redhat.com Thu May 19 11:42:03 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 May 2011 13:42:03 +0200 Subject: [katello-devel] Admin user? In-Reply-To: <4DD4FF07.2050909@redhat.com> References: <4DD41759.3050908@redhat.com> <4DD4BC9E.6080108@redhat.com> <4DD4FF07.2050909@redhat.com> Message-ID: <4DD5020B.60005@redhat.com> On 05/19/2011 01:29 PM, Todd B Sanders wrote: >> >> > Or atleast prevent the user from removing the *last* user with "admin" > privileges. Yes. But define "admin privileges"? We do have a user with all possible permissions set with the name of "admin". Maybe we should prevent to delete the last user with permission to create user. Or something like that. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From bkearney at redhat.com Thu May 19 12:00:41 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 May 2011 08:00:41 -0400 Subject: [katello-devel] Admin user? In-Reply-To: <4DD4FEB6.708@redhat.com> References: <4DD41759.3050908@redhat.com> <4DD41CE1.3030406@redhat.com> <4DD433EE.2070202@redhat.com> <4DD433A4.90306@redhat.com> <4DD4FEB6.708@redhat.com> Message-ID: <4DD50669.9030707@redhat.com> On 05/19/2011 07:27 AM, Todd B Sanders wrote: > On 05/18/2011 05:01 PM, Lukas Zapletal wrote: >> On 05/18/2011 11:02 PM, Bryan Kearney wrote: >>>> >>> yes, but if they can use DB tools to fix it.. it may be ok. >>> >>> I am also concerned about the setup. What if the users selects LDAP.. we >>> may not have a user with the correct permissions to log in. Perhaps LDAP >>> is used except for what is in the local table? >> >> My understanding of LDAP "mode" is that local users always override. >> Means that during all auth/auth stuff local tables are consulted first >> and if not found then LDAP search is done. >> > +1 This is my understanding as well. > > -Todd > Ok.. if we do that then the user can always us DB tools to reset things. I am fine with that. -- bk From bkearney at redhat.com Thu May 19 12:32:03 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 May 2011 08:32:03 -0400 Subject: [katello-devel] Admin user? In-Reply-To: <4DD5020B.60005@redhat.com> References: <4DD41759.3050908@redhat.com> <4DD4BC9E.6080108@redhat.com> <4DD4FF07.2050909@redhat.com> <4DD5020B.60005@redhat.com> Message-ID: <4DD50DC3.4090208@redhat.com> On 05/19/2011 07:42 AM, Lukas Zapletal wrote: > On 05/19/2011 01:29 PM, Todd B Sanders wrote: >>> >>> >> Or atleast prevent the user from removing the *last* user with "admin" >> privileges. > > Yes. But define "admin privileges"? We do have a user with all possible > permissions set with the name of "admin". > > Maybe we should prevent to delete the last user with permission to > create user. Or something like that. > That is my concern. I had not considered using the local tables as a look aside... so.. that alleviates some of hte issues. If we have db scripts to add new users then I think we can not worry about deleting the last user. -- bk From bkearney at redhat.com Thu May 19 13:15:06 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 May 2011 09:15:06 -0400 Subject: [katello-devel] CLI command expanding question In-Reply-To: <4DD5012B.3040706@redhat.com> References: <4DD5012B.3040706@redhat.com> Message-ID: <4DD517DA.1010108@redhat.com> On 05/19/2011 07:38 AM, Lukas Zapletal wrote: > Hello, > > there's task to expand certain cli commands (like prov -> provider) and > I agree with that. It's better to define bash completition. But I have a > question: > > Do we want to expand parameters as well? I mean --org=XXX or --prov=YYY. > It makes sense to me. > The rule should be full words except for org and repo. Those are "approved" abbreviations. -- bk From lzap at redhat.com Thu May 19 13:47:55 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 May 2011 15:47:55 +0200 Subject: [katello-devel] Admin user? In-Reply-To: <4DD50DC3.4090208@redhat.com> References: <4DD41759.3050908@redhat.com> <4DD4BC9E.6080108@redhat.com> <4DD4FF07.2050909@redhat.com> <4DD5020B.60005@redhat.com> <4DD50DC3.4090208@redhat.com> Message-ID: <4DD51F8B.1010007@redhat.com> On 05/19/2011 02:32 PM, Bryan Kearney wrote: > That is my concern. I had not considered using the local tables as a > look aside... so.. that alleviates some of hte issues. If we have db > scripts to add new users then I think we can not worry about deleting > the last user. We don't have yet. It's a part of your seed.rb script. We should take it out and provide it as an different "server" command. What name do you suggest? katello-admin ? -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From lzap at redhat.com Thu May 19 13:50:38 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 May 2011 15:50:38 +0200 Subject: [katello-devel] Katello client name Message-ID: <4DD5202E.1080802@redhat.com> Hello all We might need to change the client command kp-cmd in near future. I vote for something short and nice to type in. Usual patterns are "something-cmd", "somethingcmd" or "csomething". ckatello ckt ckl cko ctt cte Or maybe some shortcut made out of CloudForms System Engine: syseng-client syseng-cmd se-cmd sec seg cse ceg cseg cse I know CFSE is the product and Katello the project, but this is just a command name. Well I like "sec" the most. Advantages: - short - we are able to type in with only left hand (very cool for pasties!) - well I mean 10fingers typing - one can always use one hand :-) Cons: - there is already a sec command in Fedora (sec-2.5.3-0.fc13.noarch) The "seg" command is not in Fedora and is almost the same as well as "cseg". From the Katello based ones my favourites are "ctt" or "cte" -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From bkearney at redhat.com Thu May 19 13:57:49 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 May 2011 09:57:49 -0400 Subject: [katello-devel] Katello client name In-Reply-To: <4DD5202E.1080802@redhat.com> References: <4DD5202E.1080802@redhat.com> Message-ID: <4DD521DD.5050604@redhat.com> On 05/19/2011 09:50 AM, Lukas Zapletal wrote: > Hello all > > We might need to change the client command kp-cmd in near future. I vote > for something short and nice to type in. Usual patterns are > "something-cmd", "somethingcmd" or "csomething". > > ckatello > ckt > ckl > cko > ctt > cte > > Or maybe some shortcut made out of CloudForms System Engine: > > syseng-client > syseng-cmd > se-cmd > sec > seg > cse > ceg > cseg > cse > > I know CFSE is the product and Katello the project, but this is just a > command name. > > Well I like "sec" the most. Advantages: > > - short > - we are able to type in with only left hand (very cool for pasties!) > - well I mean 10fingers typing - one can always use one hand :-) > > Cons: > > - there is already a sec command in Fedora (sec-2.5.3-0.fc13.noarch) > > The "seg" command is not in Fedora and is almost the same as well as > "cseg". > > From the Katello based ones my favourites are "ctt" or "cte" > +1 ckt. -- bk From jesusr at redhat.com Thu May 19 13:55:43 2011 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 19 May 2011 09:55:43 -0400 Subject: [katello-devel] Katello client name In-Reply-To: <4DD5202E.1080802@redhat.com> References: <4DD5202E.1080802@redhat.com> Message-ID: <4DD5215F.80201@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/19/2011 09:50 AM, Lukas Zapletal wrote: > Hello all > > We might need to change the client command kp-cmd in near future. I vote > for something short and nice to type in. Usual patterns are > "something-cmd", "somethingcmd" or "csomething". > > ckatello > ckt > ckl > cko > ctt > cte > > Or maybe some shortcut made out of CloudForms System Engine: > > syseng-client > syseng-cmd > se-cmd > sec > seg > cse > ceg > cseg > cse > > I know CFSE is the product and Katello the project, but this is just a > command name. > > Well I like "sec" the most. Advantages: > > - short > - we are able to type in with only left hand (very cool for pasties!) > - well I mean 10fingers typing - one can always use one hand :-) > > Cons: > > - there is already a sec command in Fedora (sec-2.5.3-0.fc13.noarch) > > The "seg" command is not in Fedora and is almost the same as well as "cseg". > > From the Katello based ones my favourites are "ctt" or "cte" > How about: kat? - -- 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 | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3VIV8ACgkQvJZ57YntiYP+EgCfUhxva2drTrXfV4ZznAnYrJle MasAnR7PgA9UVKz7whclusLosLLFkTb8 =ssKC -----END PGP SIGNATURE----- From bkearney at redhat.com Thu May 19 14:00:58 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 May 2011 10:00:58 -0400 Subject: [katello-devel] Katello client name In-Reply-To: <4DD5215F.80201@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD5215F.80201@redhat.com> Message-ID: <4DD5229A.4080906@redhat.com> On 05/19/2011 09:55 AM, jesus m. rodriguez wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/19/2011 09:50 AM, Lukas Zapletal wrote: >> Hello all >> >> We might need to change the client command kp-cmd in near future. I vote >> for something short and nice to type in. Usual patterns are >> "something-cmd", "somethingcmd" or "csomething". >> >> ckatello >> ckt >> ckl >> cko >> ctt >> cte >> >> Or maybe some shortcut made out of CloudForms System Engine: >> >> syseng-client >> syseng-cmd >> se-cmd >> sec >> seg >> cse >> ceg >> cseg >> cse >> >> I know CFSE is the product and Katello the project, but this is just a >> command name. >> >> Well I like "sec" the most. Advantages: >> >> - short >> - we are able to type in with only left hand (very cool for pasties!) >> - well I mean 10fingers typing - one can always use one hand :-) >> >> Cons: >> >> - there is already a sec command in Fedora (sec-2.5.3-0.fc13.noarch) >> >> The "seg" command is not in Fedora and is almost the same as well as "cseg". >> >> From the Katello based ones my favourites are "ctt" or "cte" >> > > How about: kat? > oooh.. +1 -- bk From lzap at redhat.com Thu May 19 13:59:59 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 May 2011 15:59:59 +0200 Subject: [katello-devel] Katello client name In-Reply-To: <4DD5229A.4080906@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD5215F.80201@redhat.com> <4DD5229A.4080906@redhat.com> Message-ID: <4DD5225F.1080900@redhat.com> On 05/19/2011 04:00 PM, Bryan Kearney wrote: >> >> How about: kat? >> > > > oooh.. +1 -1 Two hands. ------------------------------------ T A K ------------------------------------ :-) -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From lzap at redhat.com Thu May 19 14:02:04 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 May 2011 16:02:04 +0200 Subject: [katello-devel] Katello client name In-Reply-To: <4DD521DD.5050604@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD521DD.5050604@redhat.com> Message-ID: <4DD522DC.9080501@redhat.com> On 05/19/2011 03:57 PM, Bryan Kearney wrote: >> From the Katello based ones my favourites are "ctt" or "cte" >> > +1 ckt. I understand "ctt" is not that intuitive but keys are really close to each other. How about to let everybody to post their recommendations and then we can vote somewhere... -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From jesusr at redhat.com Thu May 19 14:12:48 2011 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 19 May 2011 10:12:48 -0400 Subject: [katello-devel] Katello client name In-Reply-To: <4DD5225F.1080900@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD5215F.80201@redhat.com> <4DD5229A.4080906@redhat.com> <4DD5225F.1080900@redhat.com> Message-ID: <4DD52560.6050804@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/19/2011 09:59 AM, Lukas Zapletal wrote: > On 05/19/2011 04:00 PM, Bryan Kearney wrote: >>> >>> How about: kat? >>> >> >> >> oooh.. +1 > > -1 > > Two hands. > > > > ------------------------------------ > T > A K > ------------------------------------ > > :-) > Please let's not pick a command simply because you can type it with one hand. I suggested kat because it is short and resembles the project name: Katello. ls requires two hands, so does cp, and mv, and rm. But they resemble the actions. So -1 to ctt simply because you can type it with one hand. Honestly I'd be happier with ktt and IMO the command should include a K because we are Katello not Catello. 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 | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3VJWAACgkQvJZ57YntiYPtpACgjFi7M7xlZi6Kj8puH7JT5LMl WLoAn1XwGvtPymV82n+kj+yI+pB6ivOQ =jNeX -----END PGP SIGNATURE----- From jrist at redhat.com Thu May 19 14:16:33 2011 From: jrist at redhat.com (Jason Rist) Date: Thu, 19 May 2011 08:16:33 -0600 Subject: [katello-devel] Katello client name In-Reply-To: <4DD5215F.80201@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD5215F.80201@redhat.com> Message-ID: <4DD52641.5060902@redhat.com> On 05/19/2011 07:55 AM, jesus m. rodriguez wrote: > On 05/19/2011 09:50 AM, Lukas Zapletal wrote: >> Hello all > >> We might need to change the client command kp-cmd in near future. I vote >> for something short and nice to type in. Usual patterns are >> "something-cmd", "somethingcmd" or "csomething". > >> ckatello >> ckt >> ckl >> cko >> ctt >> cte > >> Or maybe some shortcut made out of CloudForms System Engine: > >> syseng-client >> syseng-cmd >> se-cmd >> sec >> seg >> cse >> ceg >> cseg >> cse > >> I know CFSE is the product and Katello the project, but this is just a >> command name. > >> Well I like "sec" the most. Advantages: > >> - short >> - we are able to type in with only left hand (very cool for pasties!) >> - well I mean 10fingers typing - one can always use one hand :-) > >> Cons: > >> - there is already a sec command in Fedora (sec-2.5.3-0.fc13.noarch) > >> The "seg" command is not in Fedora and is almost the same as well as "cseg". > >> From the Katello based ones my favourites are "ctt" or "cte" > > > How about: kat? > Definitely +1 to kat - it's awesome! Two hands or not... -J _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel -- 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 Thu May 19 14:17:36 2011 From: mmccune at redhat.com (Mike McCune) Date: Thu, 19 May 2011 07:17:36 -0700 Subject: [katello-devel] Katello client name In-Reply-To: <4DD522DC.9080501@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD521DD.5050604@redhat.com> <4DD522DC.9080501@redhat.com> Message-ID: <4DD52680.8030309@redhat.com> On 05/19/2011 07:02 AM, Lukas Zapletal wrote: > On 05/19/2011 03:57 PM, Bryan Kearney wrote: >>> From the Katello based ones my favourites are "ctt" or "cte" >>> >> +1 ckt. > > I understand "ctt" is not that intuitive but keys are really close to > each other. > > How about to let everybody to post their recommendations and then we can > vote somewhere... > why not something totally obvious to the user: katello takes 4 keystrokes: kat- IMHO, the most important thing should be a unique and obvious name that stands out from the thousands of other commands available from my shell but makes people think of katello. My vote goes to either: katello kat Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From bkearney at redhat.com Thu May 19 14:21:56 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 May 2011 10:21:56 -0400 Subject: [katello-devel] Katello client name In-Reply-To: <4DD5225F.1080900@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD5215F.80201@redhat.com> <4DD5229A.4080906@redhat.com> <4DD5225F.1080900@redhat.com> Message-ID: <4DD52784.6060800@redhat.com> On 05/19/2011 09:59 AM, Lukas Zapletal wrote: > On 05/19/2011 04:00 PM, Bryan Kearney wrote: >>> >>> How about: kat? >>> >> >> >> oooh.. +1 > > -1 > > Two hands. > > > > ------------------------------------ > T > A K > ------------------------------------ > > :-) > All for tab completion. -- bk From jason.dobies at redhat.com Thu May 19 14:21:20 2011 From: jason.dobies at redhat.com (Jay Dobies) Date: Thu, 19 May 2011 10:21:20 -0400 Subject: [katello-devel] Katello client name In-Reply-To: <4DD52680.8030309@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD521DD.5050604@redhat.com> <4DD522DC.9080501@redhat.com> <4DD52680.8030309@redhat.com> Message-ID: <4DD52760.8080407@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/19/2011 10:17 AM, Mike McCune wrote: > On 05/19/2011 07:02 AM, Lukas Zapletal wrote: >> On 05/19/2011 03:57 PM, Bryan Kearney wrote: >>>> From the Katello based ones my favourites are "ctt" or "cte" >>>> >>> +1 ckt. >> >> I understand "ctt" is not that intuitive but keys are really close to >> each other. >> >> How about to let everybody to post their recommendations and then we can >> vote somewhere... >> > > why not something totally obvious to the user: +1 IMO, we're past the days of having to use obscure abbreviations to make things fit. They know the project name and it's not killer to type, especially with auto-complete. > katello > > takes 4 keystrokes: > > kat- > > IMHO, the most important thing should be a unique and obvious name that > stands out from the thousands of other commands available from my shell > but makes people think of katello. > > My vote goes to either: > > katello > kat > > Mike - -- Jay Dobies RHCE# 805008743336126 Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN1SdgAAoJEOMmcTqOSQHCvugH/i5Pv1T/pTkReylI8r4FNbmG j59/wHR5l5fkZiDlk355Q0kQqrrmTIdnKy0tEw01wTyUtxfqmeW0aHnbfSnoUREb nXnhtGkAqynKZ52gpDoZ+n582fOumiZa1vuUAeo1R8k4cRRiiCu7tVmM35RXBqZD BZqH4qWeJI5oPshcDIVEEynJZhkq0rgcmf2HHZSayKmmxxHnfVO+pTXUicxGGyRH Z924NKO/KHmOmgKzi/Cfius3ZKuC+7W52ed85mz7lgMmXhjzDA7E/yxu5JSMMX1h 48j4gdYo0V9Lq15ihFG58gjbsl+Dvywvmh8gn2Z+I1KlNqejATs1FTCHwImlb/4= =dcXf -----END PGP SIGNATURE----- From bbuckingham at redhat.com Thu May 19 14:24:54 2011 From: bbuckingham at redhat.com (Brad Buckingham) Date: Thu, 19 May 2011 10:24:54 -0400 Subject: [katello-devel] Katello client name In-Reply-To: <4DD52680.8030309@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD521DD.5050604@redhat.com> <4DD522DC.9080501@redhat.com> <4DD52680.8030309@redhat.com> Message-ID: <4DD52836.20000@redhat.com> On 05/19/2011 10:17 AM, Mike McCune wrote: > On 05/19/2011 07:02 AM, Lukas Zapletal wrote: >> On 05/19/2011 03:57 PM, Bryan Kearney wrote: >>>> From the Katello based ones my favourites are "ctt" or "cte" >>>> >>> +1 ckt. >> >> I understand "ctt" is not that intuitive but keys are really close to >> each other. >> >> How about to let everybody to post their recommendations and then we can >> vote somewhere... >> > > why not something totally obvious to the user: > > katello > > takes 4 keystrokes: > > kat- > > IMHO, the most important thing should be a unique and obvious name > that stands out from the thousands of other commands available from my > shell but makes people think of katello. > > My vote goes to either: > > katello > kat > > Mike +1 to katello (w/ tab completion). I am actually pro on 2 hands... Don't want to bulk up the fingers on only one; otherwise, my gloves may no longer fit... :) From jesusr at redhat.com Thu May 19 14:28:52 2011 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 19 May 2011 10:28:52 -0400 Subject: [katello-devel] Katello client name In-Reply-To: <4DD52680.8030309@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD521DD.5050604@redhat.com> <4DD522DC.9080501@redhat.com> <4DD52680.8030309@redhat.com> Message-ID: <4DD52924.20207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/19/2011 10:17 AM, Mike McCune wrote: [snip]> > why not something totally obvious to the user: > [snip] > My vote goes to either: > > katello > kat > > Mike I'm ok with katello as well. My votes would be: +1 kat +0 katello - -1 c* 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 | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3VKSQACgkQvJZ57YntiYNJ9gCg3DE89W0aWLbT2ZyUo6x2wVzZ hykAoJ4ncXiJC1ZfPqrmaUm4cBBK40Ed =hejU -----END PGP SIGNATURE----- From jesusr at redhat.com Thu May 19 14:32:50 2011 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 19 May 2011 10:32:50 -0400 Subject: [katello-devel] Katello client name In-Reply-To: <4DD52924.20207@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD521DD.5050604@redhat.com> <4DD522DC.9080501@redhat.com> <4DD52680.8030309@redhat.com> <4DD52924.20207@redhat.com> Message-ID: <4DD52A12.9020906@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/19/2011 10:28 AM, jesus m. rodriguez wrote: > On 05/19/2011 10:17 AM, Mike McCune wrote: > [snip]> >> why not something totally obvious to the user: > > > [snip] > >> My vote goes to either: > >> katello >> kat > >> Mike > > I'm ok with katello as well. My votes would be: > > +1 kat > +0 katello > -1 c* > > jesus > +1 tak :) _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel - -- 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 | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3VKhIACgkQvJZ57YntiYPLZQCeIeNe67Wnow03PedYkB+buyaH tHYAn2a3uRo0SwfSo3X1meZS1tbEq98n =tb7P -----END PGP SIGNATURE----- From tsanders at redhat.com Thu May 19 14:46:43 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Thu, 19 May 2011 10:46:43 -0400 Subject: [katello-devel] Katello client name In-Reply-To: <4DD52760.8080407@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD521DD.5050604@redhat.com> <4DD522DC.9080501@redhat.com> <4DD52680.8030309@redhat.com> <4DD52760.8080407@redhat.com> Message-ID: <4DD52D53.4080302@redhat.com> On 05/19/2011 10:21 AM, Jay Dobies wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/19/2011 10:17 AM, Mike McCune wrote: >> On 05/19/2011 07:02 AM, Lukas Zapletal wrote: >>> On 05/19/2011 03:57 PM, Bryan Kearney wrote: >>>>> From the Katello based ones my favourites are "ctt" or "cte" >>>>> >>>> +1 ckt. >>> I understand "ctt" is not that intuitive but keys are really close to >>> each other. >>> >>> How about to let everybody to post their recommendations and then we can >>> vote somewhere... >>> >> why not something totally obvious to the user: > +1 > > IMO, we're past the days of having to use obscure abbreviations to make > things fit. They know the project name and it's not killer to type, > especially with auto-complete. +1 Sure abbreviations are short-hand, but can be confusing to the end-user. I was concerned also when I saw "prov" and "pack" in the demo the other day. -Todd >> katello >> >> takes 4 keystrokes: >> >> kat- >> >> IMHO, the most important thing should be a unique and obvious name that >> stands out from the thousands of other commands available from my shell >> but makes people think of katello. >> >> My vote goes to either: >> >> katello >> kat >> >> Mike > > - -- > Jay Dobies > RHCE# 805008743336126 > Freenode: jdob @ #pulp > http://pulpproject.org | http://blog.pulpproject.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJN1SdgAAoJEOMmcTqOSQHCvugH/i5Pv1T/pTkReylI8r4FNbmG > j59/wHR5l5fkZiDlk355Q0kQqrrmTIdnKy0tEw01wTyUtxfqmeW0aHnbfSnoUREb > nXnhtGkAqynKZ52gpDoZ+n582fOumiZa1vuUAeo1R8k4cRRiiCu7tVmM35RXBqZD > BZqH4qWeJI5oPshcDIVEEynJZhkq0rgcmf2HHZSayKmmxxHnfVO+pTXUicxGGyRH > Z924NKO/KHmOmgKzi/Cfius3ZKuC+7W52ed85mz7lgMmXhjzDA7E/yxu5JSMMX1h > 48j4gdYo0V9Lq15ihFG58gjbsl+Dvywvmh8gn2Z+I1KlNqejATs1FTCHwImlb/4= > =dcXf > -----END PGP SIGNATURE----- > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jharris at redhat.com Thu May 19 15:20:19 2011 From: jharris at redhat.com (Justin Harris) Date: Thu, 19 May 2011 11:20:19 -0400 (EDT) Subject: [katello-devel] Katello client name In-Reply-To: <4DD52A12.9020906@redhat.com> Message-ID: <892024111.96977.1305818419162.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> I agree that tab completion fixes the typing, and why not make it completely clear? +1 katello +0 kat -1 tak (and other obscure 3-letter commands) ----- Original Message ----- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/19/2011 10:28 AM, jesus m. rodriguez wrote: > > On 05/19/2011 10:17 AM, Mike McCune wrote: > > [snip]> > >> why not something totally obvious to the user: > > > > > > [snip] > > > >> My vote goes to either: > > > >> katello > >> kat > > > >> Mike > > > > I'm ok with katello as well. My votes would be: > > > > +1 kat > > +0 katello > > -1 c* > > > > jesus > > > > +1 tak :) > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > > - -- > 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 | > +---------------------------------------------+ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk3VKhIACgkQvJZ57YntiYPLZQCeIeNe67Wnow03PedYkB+buyaH > tHYAn2a3uRo0SwfSo3X1meZS1tbEq98n > =tb7P > -----END PGP SIGNATURE----- > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Thu May 19 15:44:08 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 19 May 2011 17:44:08 +0200 Subject: [katello-devel] Katello client name In-Reply-To: <4DD52560.6050804@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD5215F.80201@redhat.com> <4DD5229A.4080906@redhat.com> <4DD5225F.1080900@redhat.com> <4DD52560.6050804@redhat.com> Message-ID: <4DD53AC8.8010706@redhat.com> On 05/19/2011 04:12 PM, jesus m. rodriguez wrote: > Please let's not pick a command simply because you can > type it with one hand. I suggested kat because it is short > and resembles the project name: Katello. > > ls requires two hands, so does cp, and mv, and rm. But they > resemble the actions. > > So -1 to ctt simply because you can type it with one hand. > Honestly I'd be happier with ktt and IMO the command should > include a K because we are Katello not Catello. Good argument. Not going to swim against the current. Was a terrible idea. Non-KDE users can really use "kat" and I will define a "kk" alias or something :-) +1 for "katello" -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From mmccune at redhat.com Thu May 19 17:39:08 2011 From: mmccune at redhat.com (Mike McCune) Date: Thu, 19 May 2011 10:39:08 -0700 Subject: [katello-devel] provider URL: reverted a few changes Message-ID: <4DD555BC.1090503@redhat.com> Lukas: I had to revert some of your changes that removed provider URL from the validations, the seeds and other parts of the code. I loath reverting code and apologize undoing some of your work but by removing the URL and the validations you broke the UI and any ability to: 1) import a manifest correctly 2) have the import setup repos correctly so they can sync 3) create a new red hat provider and import manifests The changes I reverted are below and again, I wouldn't have done this normally but it broke a pretty big piece of functionality in the UI such that I think we need to step back and refactor the URLs and Providers before we go forward with their removal. We have to have a URL associated with a Red Hat provider and *not* with Custom Providers. The URL in a Red Hat provider is the base URL that all the relative paths in the import manifest are based on. If you look at a manifest's JSON you will see: "contentUrl":"/content/dist/rhel/rhui/server/5Server/x86_64/rhui/1.2/os/" we take the URL from the Red Hat provider and combine that with the contentUrl to produce the full path to Pulp to sync the content: "url":"https://some-redhat-provider.redhat.com/pulp/repos//content/dist/rhel/rhui/server/5Server/x86_64/rhui/1.2/os/" by removing the URL from the Red Hat provider removed that linkage and nothing could sync. If we want to remove the actual URL from the UI and not require it from the CLI (which we can possibly do) we would need to include it as a configurable value that is embedded with each provider but it definitely still needs to exist in the model. commit 51ab9c610574564662face6c27d699c58f3fb1b3 Author: Mike McCune Revert "fixing seeds file to not use a url for a redhat provider" commit 87d95fea34d3b553894b5711e4e6074c9069ec20 Author: Mike McCune Revert "fixing unit tests for new provider url validation" commit 50631337d67312204d37468dbe13f40263a77c21 Author: Mike McCune Revert "disabling url format check - not working for client shell" commit a5dfe25f2b7e75a47fd62a945733eb7e85d352d5 Author: Mike McCune Revert "provider url is required for yum and prohibited for rhn in the CLI" commit a464193ea0e4108e06d16ee5e467df6a1ae79d3f Author: Mike McCune Revert "provider url is required for yum and prohibited for rhn" Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From jweiss at redhat.com Thu May 19 17:45:04 2011 From: jweiss at redhat.com (Jeff Weiss) Date: Thu, 19 May 2011 13:45:04 -0400 Subject: [katello-devel] provider URL: reverted a few changes In-Reply-To: <4DD555BC.1090503@redhat.com> References: <4DD555BC.1090503@redhat.com> Message-ID: <1305827105.9381.0.camel@blinky> On Thu, 2011-05-19 at 10:39 -0700, Mike McCune wrote: > Lukas: > > I had to revert some of your changes that removed provider URL from the > validations, the seeds and other parts of the code. I loath reverting > code and apologize undoing some of your work but by removing the URL and > the validations you broke the UI and any ability to: > > 1) import a manifest correctly > 2) have the import setup repos correctly so they can sync > 3) create a new red hat provider and import manifests 4) Create custom providers > The changes I reverted are below and again, I wouldn't have done this > normally but it broke a pretty big piece of functionality in the UI such > that I think we need to step back and refactor the URLs and Providers > before we go forward with their removal. > > We have to have a URL associated with a Red Hat provider and *not* with > Custom Providers. The URL in a Red Hat provider is the base URL that > all the relative paths in the import manifest are based on. If you look > at a manifest's JSON you will see: > > "contentUrl":"/content/dist/rhel/rhui/server/5Server/x86_64/rhui/1.2/os/" > > we take the URL from the Red Hat provider and combine that with the > contentUrl to produce the full path to Pulp to sync the content: > > "url":"https://some-redhat-provider.redhat.com/pulp/repos//content/dist/rhel/rhui/server/5Server/x86_64/rhui/1.2/os/" > > by removing the URL from the Red Hat provider removed that linkage and > nothing could sync. > > If we want to remove the actual URL from the UI and not require it from > the CLI (which we can possibly do) we would need to include it as a > configurable value that is embedded with each provider but it definitely > still needs to exist in the model. > > commit 51ab9c610574564662face6c27d699c58f3fb1b3 > Author: Mike McCune > > Revert "fixing seeds file to not use a url for a redhat provider" > > commit 87d95fea34d3b553894b5711e4e6074c9069ec20 > Author: Mike McCune > > Revert "fixing unit tests for new provider url validation" > > commit 50631337d67312204d37468dbe13f40263a77c21 > Author: Mike McCune > > Revert "disabling url format check - not working for client shell" > > commit a5dfe25f2b7e75a47fd62a945733eb7e85d352d5 > Author: Mike McCune > > Revert "provider url is required for yum and prohibited for rhn in > the CLI" > > commit a464193ea0e4108e06d16ee5e467df6a1ae79d3f > Author: Mike McCune > > Revert "provider url is required for yum and prohibited for rhn" > > > Mike From jesusr at redhat.com Thu May 19 18:09:14 2011 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 19 May 2011 14:09:14 -0400 Subject: [katello-devel] katello wins (was Re: Katello client name) In-Reply-To: <4DD53AC8.8010706@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD5215F.80201@redhat.com> <4DD5229A.4080906@redhat.com> <4DD5225F.1080900@redhat.com> <4DD52560.6050804@redhat.com> <4DD53AC8.8010706@redhat.com> Message-ID: <4DD55CCA.1070602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/19/2011 11:44 AM, Lukas Zapletal wrote: > On 05/19/2011 04:12 PM, jesus m. rodriguez wrote: >> Please let's not pick a command simply because you can >> type it with one hand. I suggested kat because it is short >> and resembles the project name: Katello. >> >> ls requires two hands, so does cp, and mv, and rm. But they >> resemble the actions. >> >> So -1 to ctt simply because you can type it with one hand. >> Honestly I'd be happier with ktt and IMO the command should >> include a K because we are Katello not Catello. > > Good argument. Not going to swim against the current. > > Was a terrible idea. Non-KDE users can really use "kat" and I will > define a "kk" alias or something :-) > > +1 for "katello" > It sounds like katello will be the client name. Great voting. Thanks Lukas for starting this thread. mmccune thanks for suggesting the winner. 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 | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3VXMoACgkQvJZ57YntiYPjpwCeIfqf45adHohaMQs+LjHz7nnj 9XUAoMJSoNeyPdfPMjUgqWydMvszVXMn =yNaX -----END PGP SIGNATURE----- From bbuckingham at redhat.com Thu May 19 19:17:56 2011 From: bbuckingham at redhat.com (Brad Buckingham) Date: Thu, 19 May 2011 15:17:56 -0400 Subject: [katello-devel] Notifications branch merged to master -> need to wipe-all.sh Message-ID: <4DD56CE4.8040602@redhat.com> Team, I have just merged the notifications branch to master. As a result, folks will need to run wipe-all.sh after pulling in these changes. The changes introduced provide the ability for a user to create a notice that contains optional "additional details" (i.e. new DB column). This will allow developers to include stack traces...etc (if needed) as part of a notice, if needed. Once the notice is created, the user can view them from the notices page (e.g. /notices) by clicking on the notice containing the additional details. Notices with additional details are denoted by the (i). The following would be an example of creating an error with additional details: errors "An error has occurred.", {:details => "These are the optional additional details..."} The first string is the text that will be shown to the user immediately as part of the notice dialog. That text along with the additional details can then be viewed from the /notices page. Thanks, Brad From bkearney at redhat.com Thu May 19 22:44:11 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 May 2011 18:44:11 -0400 Subject: [katello-devel] Admin user? In-Reply-To: <4DD51F8B.1010007@redhat.com> References: <4DD41759.3050908@redhat.com> <4DD4BC9E.6080108@redhat.com> <4DD4FF07.2050909@redhat.com> <4DD5020B.60005@redhat.com> <4DD50DC3.4090208@redhat.com> <4DD51F8B.1010007@redhat.com> Message-ID: <4DD59D3B.2060700@redhat.com> On 05/19/2011 09:47 AM, Lukas Zapletal wrote: > On 05/19/2011 02:32 PM, Bryan Kearney wrote: >> That is my concern. I had not considered using the local tables as a >> look aside... so.. that alleviates some of hte issues. If we have db >> scripts to add new users then I think we can not worry about deleting >> the last user. > > We don't have yet. It's a part of your seed.rb script. > > We should take it out and provide it as an different "server" command. > > What name do you suggest? > > katello-admin ? > I dunno... could be part of that or a seperate command. -- bk From bkearney at redhat.com Thu May 19 22:47:04 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 19 May 2011 18:47:04 -0400 Subject: [katello-devel] provider URL: reverted a few changes In-Reply-To: <4DD555BC.1090503@redhat.com> References: <4DD555BC.1090503@redhat.com> Message-ID: <4DD59DE8.9010201@redhat.com> This one was my fault. Lemme explain my thinking: If this is just for RedHat providers, then I think that the manifest should have it embedded or it should be coded in the app (config file). Now.. should we support using the same Provider type for upstream candlepins? If so, that negates the idea of the config file.. but may be that we add it into the maniest. -- bk On 05/19/2011 01:39 PM, Mike McCune wrote: > Lukas: > > I had to revert some of your changes that removed provider URL from the > validations, the seeds and other parts of the code. I loath reverting > code and apologize undoing some of your work but by removing the URL and > the validations you broke the UI and any ability to: > > 1) import a manifest correctly > 2) have the import setup repos correctly so they can sync > 3) create a new red hat provider and import manifests > > The changes I reverted are below and again, I wouldn't have done this > normally but it broke a pretty big piece of functionality in the UI such > that I think we need to step back and refactor the URLs and Providers > before we go forward with their removal. > > We have to have a URL associated with a Red Hat provider and *not* with > Custom Providers. The URL in a Red Hat provider is the base URL that all > the relative paths in the import manifest are based on. If you look at a > manifest's JSON you will see: > > "contentUrl":"/content/dist/rhel/rhui/server/5Server/x86_64/rhui/1.2/os/" > > we take the URL from the Red Hat provider and combine that with the > contentUrl to produce the full path to Pulp to sync the content: > > "url":"https://some-redhat-provider.redhat.com/pulp/repos//content/dist/rhel/rhui/server/5Server/x86_64/rhui/1.2/os/" > > > by removing the URL from the Red Hat provider removed that linkage and > nothing could sync. > > If we want to remove the actual URL from the UI and not require it from > the CLI (which we can possibly do) we would need to include it as a > configurable value that is embedded with each provider but it definitely > still needs to exist in the model. > > commit 51ab9c610574564662face6c27d699c58f3fb1b3 > Author: Mike McCune > > Revert "fixing seeds file to not use a url for a redhat provider" > > commit 87d95fea34d3b553894b5711e4e6074c9069ec20 > Author: Mike McCune > > Revert "fixing unit tests for new provider url validation" > > commit 50631337d67312204d37468dbe13f40263a77c21 > Author: Mike McCune > > Revert "disabling url format check - not working for client shell" > > commit a5dfe25f2b7e75a47fd62a945733eb7e85d352d5 > Author: Mike McCune > > Revert "provider url is required for yum and prohibited for rhn in the CLI" > > commit a464193ea0e4108e06d16ee5e467df6a1ae79d3f > Author: Mike McCune > > Revert "provider url is required for yum and prohibited for rhn" > > > Mike From lzap at redhat.com Fri May 20 06:08:09 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 20 May 2011 08:08:09 +0200 Subject: [katello-devel] provider URL: reverted a few changes In-Reply-To: <4DD59DE8.9010201@redhat.com> References: <4DD555BC.1090503@redhat.com> <4DD59DE8.9010201@redhat.com> Message-ID: <4DD60549.8030400@redhat.com> On 05/20/2011 12:47 AM, Bryan Kearney wrote: > If this is just for RedHat providers, then I think that the manifest > should have it embedded or it should be coded in the app (config file). > > Now.. should we support using the same Provider type for upstream > candlepins? If so, that negates the idea of the config file.. but may be > that we add it into the maniest. Hey, sorry for that. I was really in doubt about this user story and did not test sync at the end of the day. This is an example when all unit tests are green (data looks good in Katello), but integration tests show substantional failure. I will add more simple integration tests into my script which I run before push. Unit tests are simply not enough. @Bryan - Putting these patches aside until we resolve how to proceed further. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From tsanders at redhat.com Fri May 20 11:30:14 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Fri, 20 May 2011 07:30:14 -0400 Subject: [katello-devel] provider URL: reverted a few changes In-Reply-To: <4DD59DE8.9010201@redhat.com> References: <4DD555BC.1090503@redhat.com> <4DD59DE8.9010201@redhat.com> Message-ID: <4DD650C6.5070401@redhat.com> On 05/19/2011 06:47 PM, Bryan Kearney wrote: > This one was my fault. Lemme explain my thinking: > > If this is just for RedHat providers, then I think that the manifest > should have it embedded or it should be coded in the app (config file). > > Now.. should we support using the same Provider type for upstream > candlepins? If so, that negates the idea of the config file.. but may > be that we add it into the maniest. If the katello-instance that you can sync from is equal to the same instance that created the manifest, then absolutely I would move to embedding this data in the manifest vs the UI or config file. -Todd > > -- bk > > > On 05/19/2011 01:39 PM, Mike McCune wrote: >> Lukas: >> >> I had to revert some of your changes that removed provider URL from the >> validations, the seeds and other parts of the code. I loath reverting >> code and apologize undoing some of your work but by removing the URL and >> the validations you broke the UI and any ability to: >> >> 1) import a manifest correctly >> 2) have the import setup repos correctly so they can sync >> 3) create a new red hat provider and import manifests >> >> The changes I reverted are below and again, I wouldn't have done this >> normally but it broke a pretty big piece of functionality in the UI such >> that I think we need to step back and refactor the URLs and Providers >> before we go forward with their removal. >> >> We have to have a URL associated with a Red Hat provider and *not* with >> Custom Providers. The URL in a Red Hat provider is the base URL that all >> the relative paths in the import manifest are based on. If you look at a >> manifest's JSON you will see: >> >> "contentUrl":"/content/dist/rhel/rhui/server/5Server/x86_64/rhui/1.2/os/" >> >> >> we take the URL from the Red Hat provider and combine that with the >> contentUrl to produce the full path to Pulp to sync the content: >> >> "url":"https://some-redhat-provider.redhat.com/pulp/repos//content/dist/rhel/rhui/server/5Server/x86_64/rhui/1.2/os/" >> >> >> >> by removing the URL from the Red Hat provider removed that linkage and >> nothing could sync. >> >> If we want to remove the actual URL from the UI and not require it from >> the CLI (which we can possibly do) we would need to include it as a >> configurable value that is embedded with each provider but it definitely >> still needs to exist in the model. >> >> commit 51ab9c610574564662face6c27d699c58f3fb1b3 >> Author: Mike McCune >> >> Revert "fixing seeds file to not use a url for a redhat provider" >> >> commit 87d95fea34d3b553894b5711e4e6074c9069ec20 >> Author: Mike McCune >> >> Revert "fixing unit tests for new provider url validation" >> >> commit 50631337d67312204d37468dbe13f40263a77c21 >> Author: Mike McCune >> >> Revert "disabling url format check - not working for client shell" >> >> commit a5dfe25f2b7e75a47fd62a945733eb7e85d352d5 >> Author: Mike McCune >> >> Revert "provider url is required for yum and prohibited for rhn in >> the CLI" >> >> commit a464193ea0e4108e06d16ee5e467df6a1ae79d3f >> Author: Mike McCune >> >> Revert "provider url is required for yum and prohibited for rhn" >> >> >> Mike > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Fri May 20 12:10:40 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 20 May 2011 14:10:40 +0200 Subject: [katello-devel] Translation strings with ruby code Message-ID: <4DD65A40.3030104@redhat.com> Hey, we often have strings with some ruby code, e.g. "bla bla #{some_variable}" I did not test this, but I guess these strings get extracted via gettext including the ruby code. If we use some online translation service in the future we might get into troubles. "bla bla #{User.create(name => 'cracker', is_admin => true)}" To improve security I'd suggest to use the pythonic string formatting: N_("bla bla %s" % [some_variable]) This could be also less cryptic for our translation teams and it could prevent typos introduced into the code with auto-translating tools. Comments? -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From bkearney at redhat.com Fri May 20 12:17:19 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 20 May 2011 08:17:19 -0400 Subject: [katello-devel] Translation strings with ruby code In-Reply-To: <4DD65A40.3030104@redhat.com> References: <4DD65A40.3030104@redhat.com> Message-ID: <4DD65BCF.2090000@redhat.com> On 05/20/2011 08:10 AM, Lukas Zapletal wrote: > Hey, > > we often have strings with some ruby code, e.g. > > "bla bla #{some_variable}" > > I did not test this, but I guess these strings get extracted via gettext > including the ruby code. If we use some online translation service in > the future we might get into troubles. > > "bla bla #{User.create(name => 'cracker', is_admin => true)}" > > To improve security I'd suggest to use the pythonic string formatting: > > N_("bla bla %s" % [some_variable]) > > This could be also less cryptic for our translation teams and it could > prevent typos introduced into the code with auto-translating tools. > > Comments? > Is there a form where we can use positional %0, %1, etc? That way the translaters can move around the string. -- bk From tsanders at redhat.com Fri May 20 12:13:49 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Fri, 20 May 2011 08:13:49 -0400 Subject: [katello-devel] Proposed change to meaning of an environment's "current changeset" In-Reply-To: <4DD3EB69.5080300@redhat.com> References: <4DD3E1E6.80401@redhat.com> <4DD3E711.50900@redhat.com> <4DD3EB69.5080300@redhat.com> Message-ID: <4DD65AFD.1070503@redhat.com> On 05/18/2011 11:53 AM, Justin Sherrill wrote: > On 05/18/2011 11:34 AM, Bryan Kearney wrote: >> On 05/18/2011 11:12 AM, Justin Sherrill wrote: >>> Hi, >>> >>> So currently an environment has a changeset (KPEnvironment#changeset) >>> and a changeset history (KPEnvironment#changeset_history). >>> >>> Say we have environments A->B->C >>> >>> Currently the meaning of B.changeset is the set of content that will be >>> promoted FROM B TO C. That is when you promote the changeset in B >>> everything is added to C. >>> >>> >>> I'm proposing a change to make it so that B.changeset is actually the >>> content that will be promoted FROM A to B. To me it makes more sense >>> logically as B.changeset is the changeset for B, not for C. >>> >>> This really comes into play with multiple paths, as currently the >>> Locker >>> only has 1 changeset for an environment. So it doesn't really work if >>> you can promote from locker to multiple places. That is: >>> >>> Locker -> A >>> Locker -> B >>> >>> Today, we only have Locker.changeset, so the same changeset used when >>> deciding what content should be promoted to A or to B doesn't really >>> make any sense. >>> >> >> Why does this not make sense? If my changeset is "Latest RHEL" I >> could see wanting to move it to both A and B. >> >> Is hte issue that we are getting too fancy looking into the next >> environemnt to see what to move? If so, I would be willing to hold >> back on that stuff. >> >> -- bk > > That could make sense, but the current promotion UI is not really > designed around that. We had discussed re-using changesets as well, > so you could 'copy' a changeset to allow you to re-use them when > promoting through a path. No reason you couldn't reuse them across > paths. > > To me it doesn't make sense to have Locker only have a single > changeset, because say Admin1 goes and prepares a changeset for > Environment A but waits to promote it, admin 1 (or any other user) > can't prepare another changeset for B until the first one is > promoted. For that one case where a user would want to promote a > changeset into 2 environments, he could copy as i mention above, or we > could incorporate the copy into the promotion process, so he'd still > be promoting to two environments, it would just be copying the > changeset and promoting for B as well in a single step (so this change > does not preclude your use case necessarily). > > We also don't allow you to select some content for a changeset if it > already exists in the 'next' environment. This would allow you to > select content for A that already exists in B and then promote it to > B. It seems more confusing to the user if the locker's working > changeset is shared across the next environments. > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Been thinking about this a bit.... 1. I think we need to support multiple working change-sets at any given point in time. It seems to me that especially in the lesser "locked-down" environments more folks will have the ability to promote products. With that, I think we will see a lot of promotion of products individually. Also, not all users users will have access to all products, thus, a user should only be able to see change-sets that include products that they can promote. A single working change-set between any two unique environments is going to be very limiting for our users. So, I think we need to have CRUD around change-sets. However, once they are applied/promoted, they are only available as history items. 2. We need to scope package and errata within the change-set. i.e. does the promotion apply to all products, or given a specific set. Currently, we assume all products in the environment, again, I think this is going to be limiting for our users. 3. Originally, I had suggested that we *only* support a single path of promotion through our set of environments; with only one unique "next" environment. One "branch" vs multiple "branches" so to speak. This was an effort to reduce scope and complexity in v1.0. Any reason why we shouldn't go back to this? Does it make sense to pull together a brief meeting to discuss? -Todd From bkearney at redhat.com Fri May 20 12:20:16 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 20 May 2011 08:20:16 -0400 Subject: [katello-devel] provider URL: reverted a few changes In-Reply-To: <4DD650C6.5070401@redhat.com> References: <4DD555BC.1090503@redhat.com> <4DD59DE8.9010201@redhat.com> <4DD650C6.5070401@redhat.com> Message-ID: <4DD65C80.7040907@redhat.com> On 05/20/2011 07:30 AM, Todd B Sanders wrote: > On 05/19/2011 06:47 PM, Bryan Kearney wrote: >> This one was my fault. Lemme explain my thinking: >> >> If this is just for RedHat providers, then I think that the manifest >> should have it embedded or it should be coded in the app (config file). >> >> Now.. should we support using the same Provider type for upstream >> candlepins? If so, that negates the idea of the config file.. but may >> be that we add it into the maniest. > > If the katello-instance that you can sync from is equal to the same > instance that created the manifest, then absolutely I would move to > embedding this data in the manifest vs the UI or config file. > > -Todd > OK... I will get this on the Candlepin backlog. As for the second question. Do we want to support the following: 1) a Tenant either gets Red Hat Subscriptions from an upstream candlepin, or Red Hat. This means there is only on Red Hat provider per tenant. -- bk From tsanders at redhat.com Fri May 20 12:25:57 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Fri, 20 May 2011 08:25:57 -0400 Subject: [katello-devel] provider URL: reverted a few changes In-Reply-To: <4DD65C80.7040907@redhat.com> References: <4DD555BC.1090503@redhat.com> <4DD59DE8.9010201@redhat.com> <4DD650C6.5070401@redhat.com> <4DD65C80.7040907@redhat.com> Message-ID: <4DD65DD5.3060100@redhat.com> On 05/20/2011 08:20 AM, Bryan Kearney wrote: > On 05/20/2011 07:30 AM, Todd B Sanders wrote: >> On 05/19/2011 06:47 PM, Bryan Kearney wrote: >>> This one was my fault. Lemme explain my thinking: >>> >>> If this is just for RedHat providers, then I think that the manifest >>> should have it embedded or it should be coded in the app (config file). >>> >>> Now.. should we support using the same Provider type for upstream >>> candlepins? If so, that negates the idea of the config file.. but may >>> be that we add it into the maniest. >> >> If the katello-instance that you can sync from is equal to the same >> instance that created the manifest, then absolutely I would move to >> embedding this data in the manifest vs the UI or config file. >> >> -Todd >> > > > OK... I will get this on the Candlepin backlog. As for the second > question. Do we want to support the following: > > 1) a Tenant either gets Red Hat Subscriptions from an upstream > candlepin, or Red Hat. This means there is only on Red Hat provider > per tenant. > > -- bk I think that's right. Tenants are limited to a single RH provider. I can't think of a case where a tenant would want to get RH content from multiple locations. We will need to specify the %env tag within the content set urls when creating a manifest on an upstream katello/candlepin, so that the downstream created RH provider will pull content from the correct environment (i.e. production). -Todd From lzap at redhat.com Fri May 20 12:28:21 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 20 May 2011 14:28:21 +0200 Subject: [katello-devel] CLI client and locale Message-ID: <4DD65E65.7060304@redhat.com> Hello, I am just curious what are the plans about CLI and locale. My intuition tells me the CLI should send user's current locale in the headers and our API controller should parse the header just like UI controller do. The locale should be set properly and gettext should then translate everything (e.g. error messages). So the result would be: LC_ALL=en katello some bad command Fatal error - cannot be done !!! LC_ALL=jp katello some bad command ???????? - ????????????? !!! Comments? PS - Well I was cheating. Cannot speak Japanese. I pasted this from a bugreport [*] without a clue what does it mean :-) [*] - https://bugzilla.redhat.com/show_bug.cgi?id=706318 -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From lzap at redhat.com Fri May 20 12:30:35 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 20 May 2011 14:30:35 +0200 Subject: [katello-devel] Translation strings with ruby code In-Reply-To: <4DD65BCF.2090000@redhat.com> References: <4DD65A40.3030104@redhat.com> <4DD65BCF.2090000@redhat.com> Message-ID: <4DD65EEB.2000909@redhat.com> On 05/20/2011 02:17 PM, Bryan Kearney wrote: > Is there a form where we can use positional %0, %1, etc? That way the > translaters can move around the string. I don't think so. :-( [*] More experienced rubyist - please confirm. We could implement something then. [*] - http://goo.gl/nKK9L -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From bkearney at redhat.com Fri May 20 12:36:37 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 20 May 2011 08:36:37 -0400 Subject: [katello-devel] provider URL: reverted a few changes In-Reply-To: <4DD65DD5.3060100@redhat.com> References: <4DD555BC.1090503@redhat.com> <4DD59DE8.9010201@redhat.com> <4DD650C6.5070401@redhat.com> <4DD65C80.7040907@redhat.com> <4DD65DD5.3060100@redhat.com> Message-ID: <4DD66055.3030204@redhat.com> On 05/20/2011 08:25 AM, Todd B Sanders wrote: > On 05/20/2011 08:20 AM, Bryan Kearney wrote: >> On 05/20/2011 07:30 AM, Todd B Sanders wrote: >>> On 05/19/2011 06:47 PM, Bryan Kearney wrote: >>>> This one was my fault. Lemme explain my thinking: >>>> >>>> If this is just for RedHat providers, then I think that the manifest >>>> should have it embedded or it should be coded in the app (config file). >>>> >>>> Now.. should we support using the same Provider type for upstream >>>> candlepins? If so, that negates the idea of the config file.. but may >>>> be that we add it into the maniest. >>> >>> If the katello-instance that you can sync from is equal to the same >>> instance that created the manifest, then absolutely I would move to >>> embedding this data in the manifest vs the UI or config file. >>> >>> -Todd >>> >> >> >> OK... I will get this on the Candlepin backlog. As for the second >> question. Do we want to support the following: >> >> 1) a Tenant either gets Red Hat Subscriptions from an upstream >> candlepin, or Red Hat. This means there is only on Red Hat provider >> per tenant. >> >> -- bk > > I think that's right. Tenants are limited to a single RH provider. I > can't think of a case where a tenant would want to get RH content from > multiple locations. ok.. but the red hat provider will be for Red Hat _or_ upstream candlepin? > > We will need to specify the %env tag within the content set urls when > creating a manifest on an upstream katello/candlepin, so that the > downstream created RH provider will pull content from the correct > environment (i.e. production). Currenlty conent out of katello should be prepended with /{OWNER_ID}/$env where OWNER_D is actually filled in. > > -Todd > From tsanders at redhat.com Fri May 20 12:44:37 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Fri, 20 May 2011 08:44:37 -0400 Subject: [katello-devel] provider URL: reverted a few changes In-Reply-To: <4DD66055.3030204@redhat.com> References: <4DD555BC.1090503@redhat.com> <4DD59DE8.9010201@redhat.com> <4DD650C6.5070401@redhat.com> <4DD65C80.7040907@redhat.com> <4DD65DD5.3060100@redhat.com> <4DD66055.3030204@redhat.com> Message-ID: <4DD66235.6020108@redhat.com> On 05/20/2011 08:36 AM, Bryan Kearney wrote: > On 05/20/2011 08:25 AM, Todd B Sanders wrote: >> On 05/20/2011 08:20 AM, Bryan Kearney wrote: >>> On 05/20/2011 07:30 AM, Todd B Sanders wrote: >>>> On 05/19/2011 06:47 PM, Bryan Kearney wrote: >>>>> This one was my fault. Lemme explain my thinking: >>>>> >>>>> If this is just for RedHat providers, then I think that the manifest >>>>> should have it embedded or it should be coded in the app (config >>>>> file). >>>>> >>>>> Now.. should we support using the same Provider type for upstream >>>>> candlepins? If so, that negates the idea of the config file.. but may >>>>> be that we add it into the maniest. >>>> >>>> If the katello-instance that you can sync from is equal to the same >>>> instance that created the manifest, then absolutely I would move to >>>> embedding this data in the manifest vs the UI or config file. >>>> >>>> -Todd >>>> >>> >>> >>> OK... I will get this on the Candlepin backlog. As for the second >>> question. Do we want to support the following: >>> >>> 1) a Tenant either gets Red Hat Subscriptions from an upstream >>> candlepin, or Red Hat. This means there is only on Red Hat provider >>> per tenant. >>> >>> -- bk >> >> I think that's right. Tenants are limited to a single RH provider. I >> can't think of a case where a tenant would want to get RH content from >> multiple locations. > > ok.. but the red hat provider will be for Red Hat _or_ upstream > candlepin? Both. That was my assumption; and that is determined by where the manifest was generated. > >> >> We will need to specify the %env tag within the content set urls when >> creating a manifest on an upstream katello/candlepin, so that the >> downstream created RH provider will pull content from the correct >> environment (i.e. production). > > Currenlty conent out of katello should be prepended with > /{OWNER_ID}/$env where OWNER_D is actually filled in. Right. My point is that $env will need to be filled in as well, otherwise a downstream katello won't be able to resolve a proper url to sync content from. Of course I suppose we could use .listing files in the repos themselves (as we do for $releasever and $basearch) if the desired behavior was to give them access to repos in *all* environments on the upstream. I'm not sure I would go that route though. -Todd > >> >> -Todd >> > From jesusr at redhat.com Fri May 20 12:51:36 2011 From: jesusr at redhat.com (jesus m. rodriguez) Date: Fri, 20 May 2011 08:51:36 -0400 Subject: [katello-devel] Translation strings with ruby code In-Reply-To: <4DD65A40.3030104@redhat.com> References: <4DD65A40.3030104@redhat.com> Message-ID: <4DD663D8.1010001@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/20/2011 08:10 AM, Lukas Zapletal wrote: > Hey, > > we often have strings with some ruby code, e.g. > > "bla bla #{some_variable}" > > I did not test this, but I guess these strings get extracted via gettext > including the ruby code. If we use some online translation service in > the future we might get into troubles. > > "bla bla #{User.create(name => 'cracker', is_admin => true)}" > > To improve security I'd suggest to use the pythonic string formatting: > > N_("bla bla %s" % [some_variable]) > > This could be also less cryptic for our translation teams and it could > prevent typos introduced into the code with auto-translating tools. > > Comments? > It this really a concern? Shouldn't we verify the strings when the come back before pushing out a release? Wouldn't this be verified in testing both functional and unit? I fear we'll be making a change to prevent a problem that may never occur or could be preventable in other ways than changing how we code. Just my 2 pesos. - -- 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 | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3WY9gACgkQvJZ57YntiYN0FACfSHGAcDjCEgSgmWmnfUUeVWVF 2ygAn0s32/SoIPfAfc55WTqIuKaUoI1q =nAca -----END PGP SIGNATURE----- From tstrachota at redhat.com Thu May 19 13:58:47 2011 From: tstrachota at redhat.com (Tomas Strachota) Date: Thu, 19 May 2011 15:58:47 +0200 Subject: [katello-devel] Katello client name In-Reply-To: <4DD5215F.80201@redhat.com> References: <4DD5202E.1080802@redhat.com> <4DD5215F.80201@redhat.com> Message-ID: <4DD52217.70005@redhat.com> On 19/05/11 15:55, jesus m. rodriguez wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/19/2011 09:50 AM, Lukas Zapletal wrote: >> Hello all >> >> We might need to change the client command kp-cmd in near future. I vote >> for something short and nice to type in. Usual patterns are >> "something-cmd", "somethingcmd" or "csomething". >> >> ckatello >> ckt >> ckl >> cko >> ctt >> cte >> >> Or maybe some shortcut made out of CloudForms System Engine: >> >> syseng-client >> syseng-cmd >> se-cmd >> sec >> seg >> cse >> ceg >> cseg >> cse >> >> I know CFSE is the product and Katello the project, but this is just a >> command name. >> >> Well I like "sec" the most. Advantages: >> >> - short >> - we are able to type in with only left hand (very cool for pasties!) >> - well I mean 10fingers typing - one can always use one hand :-) >> >> Cons: >> >> - there is already a sec command in Fedora (sec-2.5.3-0.fc13.noarch) >> >> The "seg" command is not in Fedora and is almost the same as well as "cseg". >> >> From the Katello based ones my favourites are "ctt" or "cte" >> > > How about: kat? > > - -- > 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 | > +---------------------------------------------+ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk3VIV8ACgkQvJZ57YntiYP+EgCfUhxva2drTrXfV4ZznAnYrJle > MasAnR7PgA9UVKz7whclusLosLLFkTb8 > =ssKC > -----END PGP SIGNATURE----- > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I vote for: ktcmd kat ckt Tomas From bkearney at redhat.com Fri May 20 13:38:25 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 20 May 2011 09:38:25 -0400 Subject: [katello-devel] Translation strings with ruby code In-Reply-To: <4DD663D8.1010001@redhat.com> References: <4DD65A40.3030104@redhat.com> <4DD663D8.1010001@redhat.com> Message-ID: <4DD66ED1.9040400@redhat.com> On 05/20/2011 08:51 AM, jesus m. rodriguez wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/20/2011 08:10 AM, Lukas Zapletal wrote: >> Hey, >> >> we often have strings with some ruby code, e.g. >> >> "bla bla #{some_variable}" >> >> I did not test this, but I guess these strings get extracted via gettext >> including the ruby code. If we use some online translation service in >> the future we might get into troubles. >> >> "bla bla #{User.create(name => 'cracker', is_admin => true)}" >> >> To improve security I'd suggest to use the pythonic string formatting: >> >> N_("bla bla %s" % [some_variable]) >> >> This could be also less cryptic for our translation teams and it could >> prevent typos introduced into the code with auto-translating tools. >> >> Comments? >> > > It this really a concern? Shouldn't we verify the strings when the > come back before pushing out a release? Wouldn't this be verified > in testing both functional and unit? > > I fear we'll be making a change to prevent a problem that may never > occur or could be preventable in other ways than changing how we > code. > > Just my 2 pesos. > Who really verifies 1000 strings? -- bk From bkearney at redhat.com Fri May 20 13:39:34 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 20 May 2011 09:39:34 -0400 Subject: [katello-devel] CLI client and locale In-Reply-To: <4DD65E65.7060304@redhat.com> References: <4DD65E65.7060304@redhat.com> Message-ID: <4DD66F16.90009@redhat.com> On 05/20/2011 08:28 AM, Lukas Zapletal wrote: > Hello, > > I am just curious what are the plans about CLI and locale. My intuition > tells me the CLI should send user's current locale in the headers and > our API controller should parse the header just like UI controller do. > The locale should be set properly and gettext should then translate > everything (e.g. error messages). > > So the result would be: > > LC_ALL=en katello some bad command > Fatal error - cannot be done !!! > > LC_ALL=jp katello some bad command > ???????? - ????????????? !!! > > Comments? > > PS - Well I was cheating. Cannot speak Japanese. I pasted this from a > bugreport [*] without a clue what does it mean :-) > > [*] - https://bugzilla.redhat.com/show_bug.cgi?id=706318 > Yes, I agree locale should be passed up. I will put this on the backlog. -- bk From jesusr at redhat.com Fri May 20 13:44:22 2011 From: jesusr at redhat.com (jesus m. rodriguez) Date: Fri, 20 May 2011 09:44:22 -0400 Subject: [katello-devel] Translation strings with ruby code In-Reply-To: <4DD66ED1.9040400@redhat.com> References: <4DD65A40.3030104@redhat.com> <4DD663D8.1010001@redhat.com> <4DD66ED1.9040400@redhat.com> Message-ID: <4DD67036.9040304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/20/2011 09:38 AM, Bryan Kearney wrote: > On 05/20/2011 08:51 AM, jesus m. rodriguez wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 05/20/2011 08:10 AM, Lukas Zapletal wrote: >>> Hey, >>> >>> we often have strings with some ruby code, e.g. >>> >>> "bla bla #{some_variable}" >>> >>> I did not test this, but I guess these strings get extracted via gettext >>> including the ruby code. If we use some online translation service in >>> the future we might get into troubles. >>> >>> "bla bla #{User.create(name => 'cracker', is_admin => true)}" >>> >>> To improve security I'd suggest to use the pythonic string formatting: >>> >>> N_("bla bla %s" % [some_variable]) >>> >>> This could be also less cryptic for our translation teams and it could >>> prevent typos introduced into the code with auto-translating tools. >>> >>> Comments? >>> >> >> It this really a concern? Shouldn't we verify the strings when the >> come back before pushing out a release? Wouldn't this be verified >> in testing both functional and unit? >> >> I fear we'll be making a change to prevent a problem that may never >> occur or could be preventable in other ways than changing how we >> code. >> >> Just my 2 pesos. >> > > Who really verifies 1000 strings? Write a script that pulls out the strings that contain 'ruby code', that looks for possible injections. If we want to change that's fine with me. I just think that if doing #{foo} is common in ruby strings that making folks change is more difficult than automating some sort of post processing script to detect possible security issues. If ruby folks don't care about keeping #{} in their strings, then change all you want. 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 | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3WcDYACgkQvJZ57YntiYPQtgCgmIADtAjD/Qp86StEyQ44tfV0 IA4AoMp5yWmjmGO14p+dyKYSOvJTga3R =8DTA -----END PGP SIGNATURE----- From bkearney at redhat.com Fri May 20 14:02:34 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 20 May 2011 10:02:34 -0400 Subject: [katello-devel] Proposed change to meaning of an environment's "current changeset" In-Reply-To: <4DD65AFD.1070503@redhat.com> References: <4DD3E1E6.80401@redhat.com> <4DD3E711.50900@redhat.com> <4DD3EB69.5080300@redhat.com> <4DD65AFD.1070503@redhat.com> Message-ID: <4DD6747A.3060504@redhat.com> On 05/20/2011 08:13 AM, Todd B Sanders wrote: > On 05/18/2011 11:53 AM, Justin Sherrill wrote: >> On 05/18/2011 11:34 AM, Bryan Kearney wrote: >>> On 05/18/2011 11:12 AM, Justin Sherrill wrote: >>>> Hi, >>>> >>>> So currently an environment has a changeset (KPEnvironment#changeset) >>>> and a changeset history (KPEnvironment#changeset_history). >>>> >>>> Say we have environments A->B->C >>>> >>>> Currently the meaning of B.changeset is the set of content that will be >>>> promoted FROM B TO C. That is when you promote the changeset in B >>>> everything is added to C. >>>> >>>> >>>> I'm proposing a change to make it so that B.changeset is actually the >>>> content that will be promoted FROM A to B. To me it makes more sense >>>> logically as B.changeset is the changeset for B, not for C. >>>> >>>> This really comes into play with multiple paths, as currently the >>>> Locker >>>> only has 1 changeset for an environment. So it doesn't really work if >>>> you can promote from locker to multiple places. That is: >>>> >>>> Locker -> A >>>> Locker -> B >>>> >>>> Today, we only have Locker.changeset, so the same changeset used when >>>> deciding what content should be promoted to A or to B doesn't really >>>> make any sense. >>>> >>> >>> Why does this not make sense? If my changeset is "Latest RHEL" I >>> could see wanting to move it to both A and B. >>> >>> Is hte issue that we are getting too fancy looking into the next >>> environemnt to see what to move? If so, I would be willing to hold >>> back on that stuff. >>> >>> -- bk >> >> That could make sense, but the current promotion UI is not really >> designed around that. We had discussed re-using changesets as well, so >> you could 'copy' a changeset to allow you to re-use them when >> promoting through a path. No reason you couldn't reuse them across paths. >> >> To me it doesn't make sense to have Locker only have a single >> changeset, because say Admin1 goes and prepares a changeset for >> Environment A but waits to promote it, admin 1 (or any other user) >> can't prepare another changeset for B until the first one is promoted. >> For that one case where a user would want to promote a changeset into >> 2 environments, he could copy as i mention above, or we could >> incorporate the copy into the promotion process, so he'd still be >> promoting to two environments, it would just be copying the changeset >> and promoting for B as well in a single step (so this change does not >> preclude your use case necessarily). >> >> We also don't allow you to select some content for a changeset if it >> already exists in the 'next' environment. This would allow you to >> select content for A that already exists in B and then promote it to >> B. It seems more confusing to the user if the locker's working >> changeset is shared across the next environments. >> >> -Justin >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > Been thinking about this a bit.... > > 1. I think we need to support multiple working change-sets at any given > point in time. It seems to me that especially in the lesser > "locked-down" environments more folks will have the ability to promote > products. With that, I think we will see a lot of promotion of products > individually. Also, not all users users will have access to all > products, thus, a user should only be able to see change-sets that > include products that they can promote. A single working change-set > between any two unique environments is going to be very limiting for our > users. So, I think we need to have CRUD around change-sets. However, > once they are applied/promoted, they are only available as history items. +1 > > 2. We need to scope package and errata within the change-set. i.e. does > the promotion apply to all products, or given a specific set. Currently, > we assume all products in the environment, again, I think this is going > to be limiting for our users. Is errata matata stored in the repomod files? If so, I agree that the user must pick the product(s) to apply the package/errata to or explicitly state "all products". I think the latter should be a unique permission. > > 3. Originally, I had suggested that we *only* support a single path of > promotion through our set of environments; with only one unique "next" > environment. One "branch" vs multiple "branches" so to speak. This was > an effort to reduce scope and complexity in v1.0. Any reason why we > shouldn't go back to this? I am fine for now, but I would prefer this to be a GUI thing. If we assume that you interrogate the next env to know what to put in change set... then we can never re-use. I would prefer a model where you construct a valid CS from your current env and then apply only what is needed to next. > > Does it make sense to pull together a brief meeting to discuss? Yes.. good idea. -- bk From tsanders at redhat.com Fri May 20 14:10:54 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Fri, 20 May 2011 10:10:54 -0400 Subject: [katello-devel] Proposed change to meaning of an environment's "current changeset" In-Reply-To: <4DD6747A.3060504@redhat.com> References: <4DD3E1E6.80401@redhat.com> <4DD3E711.50900@redhat.com> <4DD3EB69.5080300@redhat.com> <4DD65AFD.1070503@redhat.com> <4DD6747A.3060504@redhat.com> Message-ID: <4DD6766E.9080705@redhat.com> On 05/20/2011 10:02 AM, Bryan Kearney wrote: > On 05/20/2011 08:13 AM, Todd B Sanders wrote: >> On 05/18/2011 11:53 AM, Justin Sherrill wrote: >>> On 05/18/2011 11:34 AM, Bryan Kearney wrote: >>>> On 05/18/2011 11:12 AM, Justin Sherrill wrote: >>>>> Hi, >>>>> >>>>> So currently an environment has a changeset (KPEnvironment#changeset) >>>>> and a changeset history (KPEnvironment#changeset_history). >>>>> >>>>> Say we have environments A->B->C >>>>> >>>>> Currently the meaning of B.changeset is the set of content that >>>>> will be >>>>> promoted FROM B TO C. That is when you promote the changeset in B >>>>> everything is added to C. >>>>> >>>>> >>>>> I'm proposing a change to make it so that B.changeset is actually the >>>>> content that will be promoted FROM A to B. To me it makes more sense >>>>> logically as B.changeset is the changeset for B, not for C. >>>>> >>>>> This really comes into play with multiple paths, as currently the >>>>> Locker >>>>> only has 1 changeset for an environment. So it doesn't really work if >>>>> you can promote from locker to multiple places. That is: >>>>> >>>>> Locker -> A >>>>> Locker -> B >>>>> >>>>> Today, we only have Locker.changeset, so the same changeset used when >>>>> deciding what content should be promoted to A or to B doesn't really >>>>> make any sense. >>>>> >>>> >>>> Why does this not make sense? If my changeset is "Latest RHEL" I >>>> could see wanting to move it to both A and B. >>>> >>>> Is hte issue that we are getting too fancy looking into the next >>>> environemnt to see what to move? If so, I would be willing to hold >>>> back on that stuff. >>>> >>>> -- bk >>> >>> That could make sense, but the current promotion UI is not really >>> designed around that. We had discussed re-using changesets as well, so >>> you could 'copy' a changeset to allow you to re-use them when >>> promoting through a path. No reason you couldn't reuse them across >>> paths. >>> >>> To me it doesn't make sense to have Locker only have a single >>> changeset, because say Admin1 goes and prepares a changeset for >>> Environment A but waits to promote it, admin 1 (or any other user) >>> can't prepare another changeset for B until the first one is promoted. >>> For that one case where a user would want to promote a changeset into >>> 2 environments, he could copy as i mention above, or we could >>> incorporate the copy into the promotion process, so he'd still be >>> promoting to two environments, it would just be copying the changeset >>> and promoting for B as well in a single step (so this change does not >>> preclude your use case necessarily). >>> >>> We also don't allow you to select some content for a changeset if it >>> already exists in the 'next' environment. This would allow you to >>> select content for A that already exists in B and then promote it to >>> B. It seems more confusing to the user if the locker's working >>> changeset is shared across the next environments. >>> >>> -Justin >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> >> Been thinking about this a bit.... >> >> 1. I think we need to support multiple working change-sets at any given >> point in time. It seems to me that especially in the lesser >> "locked-down" environments more folks will have the ability to promote >> products. With that, I think we will see a lot of promotion of products >> individually. Also, not all users users will have access to all >> products, thus, a user should only be able to see change-sets that >> include products that they can promote. A single working change-set >> between any two unique environments is going to be very limiting for our >> users. So, I think we need to have CRUD around change-sets. However, >> once they are applied/promoted, they are only available as history >> items. > > +1 > >> >> 2. We need to scope package and errata within the change-set. i.e. does >> the promotion apply to all products, or given a specific set. Currently, >> we assume all products in the environment, again, I think this is going >> to be limiting for our users. > > Is errata matata stored in the repomod files? If so, I agree that the > user must pick the product(s) to apply the package/errata to or > explicitly state "all products". I think the latter should be a unique > permission. Yes, it is stored in the updateinfo.xml files as part of the repo metadata. +1 to unique permission for the "apply all" case. > >> >> 3. Originally, I had suggested that we *only* support a single path of >> promotion through our set of environments; with only one unique "next" >> environment. One "branch" vs multiple "branches" so to speak. This was >> an effort to reduce scope and complexity in v1.0. Any reason why we >> shouldn't go back to this? > > I am fine for now, but I would prefer this to be a GUI thing. If we > assume that you interrogate the next env to know what to put in change > set... then we can never re-use. I would prefer a model where you > construct a valid CS from your current env and then apply only what is > needed to next. Fair. > >> >> Does it make sense to pull together a brief meeting to discuss? > > Yes.. good idea. Scheduling for Monday. -Todd > > -- bk > From tsanders at redhat.com Fri May 20 14:16:22 2011 From: tsanders at redhat.com (Todd Sanders) Date: Fri, 20 May 2011 10:16:22 -0400 (EDT) Subject: [katello-devel] Katello Change-Set/Promotion Discussion Message-ID: <1071493747.142035.1305900982372.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> The following is a new meeting request: Subject: Katello Change-Set/Promotion Discussion Organizer: "Todd Sanders" Location: 1134679258 Time: Monday, May 23, 2011, 1:00:00 PM - 2:00:00 PM GMT -05:00 US/Canada Eastern Invitees: katello-devel at redhat.com *~*~*~*~*~*~*~*~*~* Let's discuss the desired behaviors around change-sets and promotions between environments. -Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 2382 bytes Desc: not available URL: From ohadlevy at redhat.com Sun May 22 06:37:20 2011 From: ohadlevy at redhat.com (Ohad Levy) Date: Sun, 22 May 2011 09:37:20 +0300 Subject: [katello-devel] Admin user? In-Reply-To: <4DD4BC9E.6080108@redhat.com> References: <4DD41759.3050908@redhat.com> <4DD4BC9E.6080108@redhat.com> Message-ID: <1306046240.3691.1.camel@super.tlv.redhat.com> On Thu, 2011-05-19 at 08:45 +0200, Lukas Zapletal wrote: > On 05/18/2011 09:00 PM, Bryan Kearney wrote: > > 1) Have an admin user which is backed by a config file even if the > > candlepin is set up to LDAP? > > 2) Trust the user to not be an idiot and delete the admin user. If they > > do, use DB tools to fix it. > > Or maybe 3) Add "locked" column to the user table which could prevent > from deleting. We wont allow the user to change it. > > in foreman we have both a rake task to reset admins permissions(i.e. removed admin properties or changed password), and we recreate the the admin account if it got removed automatically (if working without authentication enabled, you are always running as the admin user). Ohad From tstrachota at redhat.com Sun May 22 22:00:28 2011 From: tstrachota at redhat.com (Tomas Strachota) Date: Mon, 23 May 2011 00:00:28 +0200 Subject: [katello-devel] CLI is now katello Message-ID: <4DD9877C.6030705@redhat.com> Hello all based on the yesterday's discussion I renamed kp-cmd to katello today. Following changes has been made so be aware you have to change couple of things after you pull from master. - cli command is now called katello - config /etc/kalpana/client.conf moved to /etc/katello/client.conf - ~/.kalpana/ moved to ~/.katello/ Also commands were cleaned up: - all commands are now full names, there are only two abbreviations: org and repo. List of changed commands: dist -> distribution env -> environment pack -> package prod -> product prov -> provider - parameters are now full words too (except from org & repo). In fact, only one was changed: --env -> --environment - "provider add_product" was moved to "product create" - "provider list" now requires organization I'll write simple guidelines for naming commands and parameters and put it to wiki soon. Tomas From lzap at redhat.com Mon May 23 07:15:59 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 23 May 2011 09:15:59 +0200 Subject: [katello-devel] CLI client and locale In-Reply-To: <4DD66F16.90009@redhat.com> References: <4DD65E65.7060304@redhat.com> <4DD66F16.90009@redhat.com> Message-ID: <4DDA09AF.5040206@redhat.com> On 05/20/2011 03:39 PM, Bryan Kearney wrote: > Yes, I agree locale should be passed up. I will put this on the backlog. Can I take it right away? Because I have a subtask "ensure error messages are translated" and I will have to add it anyway to properly test it under the CLI. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From lzap at redhat.com Mon May 23 07:46:28 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 23 May 2011 09:46:28 +0200 Subject: [katello-devel] Admin user? In-Reply-To: <1306046240.3691.1.camel@super.tlv.redhat.com> References: <4DD41759.3050908@redhat.com> <4DD4BC9E.6080108@redhat.com> <1306046240.3691.1.camel@super.tlv.redhat.com> Message-ID: <4DDA10D4.6080007@redhat.com> On 05/22/2011 08:37 AM, Ohad Levy wrote: > in foreman we have both a rake task to reset admins permissions(i.e. > removed admin properties or changed password), and we recreate the the > admin account if it got removed automatically (if working without > authentication enabled, you are always running as the admin user). we could break up our seed script for that. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From lzap at redhat.com Mon May 23 08:25:06 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 23 May 2011 10:25:06 +0200 Subject: [katello-devel] Translation strings with ruby code In-Reply-To: <4DD67036.9040304@redhat.com> References: <4DD65A40.3030104@redhat.com> <4DD663D8.1010001@redhat.com> <4DD66ED1.9040400@redhat.com> <4DD67036.9040304@redhat.com> Message-ID: <4DDA19E2.6070606@redhat.com> On 05/20/2011 03:44 PM, jesus m. rodriguez wrote: > Write a script that pulls out the strings that contain 'ruby code', > that looks for possible injections. If we want to change that's fine > with me. I just think that if doing #{foo} is common in ruby strings > that making folks change is more difficult than automating some > sort of post processing script to detect possible security > issues. > > If ruby folks don't care about keeping #{} in their strings, then > change all you want. It's usually better to deal with cause than consequence. I totally agree the #{} style is very comfortable for us, but we are discussing translation strings, not all strings. It's more about translators confusion than security, I would say. But I like the idea of the check script. I think the good approach could be combination of both. I just found the ruby gettext gem supports named parameters: print _("Hello World\n") print _("Hello %{world}\n" % {:world => 'World'}) Therefore we could enforce (with using a grep in po files) to use the "ruby" style in simple cases (just a variable) and the "percent" style fore more complex statements. E.g.: _( "blah blah #{blah}" ) - correct (safe, easy to understand) _( "blah blah #{function xy, yz}" ) - incorrect (unsafe, unclear) For the latter one we should be enforced to use: _( "blah blah %{b}" % { :b => function xy, yz } ) Translators will see only two position-independent variants: #{variable} or %{variable} both obviously easy to understand. I think we should be able to catch these with a simple grep. The only issue is to keep using the script regularly (maybe through Jerkins). -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From lzap at redhat.com Mon May 23 08:55:30 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 23 May 2011 10:55:30 +0200 Subject: [katello-devel] Watch out when translating in class context Message-ID: <4DDA2102.6040607@redhat.com> Hello, I have found we are using gettext translating incorrectly in quite a lot places. The very basic util function is the underscore one. It is easy to understand - it translates the string immediately. Like a function call. _("Hello World") The little issue is in the class context. It gets evaluated before our I18n code gets initialized. Thus the gettext layer has no clue how to translate (which language to use for the current user?) and the string never gets translated. Typical example is in our model classes: class Post < ActiveRecord::Base validates_presence_of :text, :message => _('Hey it's missing!') end Since we use gettext_i18n_rails gem it automatically try to translate one more time while rendering this string into the session. The key is to use dynamic util function in this case: N_('Hey it's missing!') Dynamic util function just "marks" the strings for extraction (rake gettext:find in our case) so it is available in our po/mo files. It doesn't do the actual translation. The rails gettext plugin does it for us in this case. If you git-grep our code you will see we are using it. Great. But we use it in places where we should not do that. And that's the issue. Since it doesn't do the actual translation our strings are never translated. It's just all English for these cases. Looks like a copy&paste thing. The simple rule is: 1) Always use _() or its variants (plurals etc.) 2) For class context model messages use N_() [*] 3) For other class context use N_() as well (but you must translate the string later on otherwise it wont be translated) I am not currently aware of other class context in our app. If you find one the workaround is to use the dynamic variant first and then translate the string later on: before initialization: ... fruit = N_("Apple") # same as fruit = "Apple" ... after initialization: ... _(fruit) # does a normal translation ... [*] Please keep in mind not all model error messages are in the class context! In this example you must use _() since the following block is executed after I18n has already been initialized: ... validate :only_one_rhn_provider ... def only_one_rhn_provider # this is not in class context anymore if new_record? and provider_type == REDHAT and xyz errors.add(:base, _("Only one Red Hat provider permitted")) end end ... I will fix all the places and put this remark to our I18N wiki page. More reading: https://github.com/grosser/fast_gettext/wiki/activerecord https://github.com/grosser/gettext_i18n_rails https://github.com/mutoh/gettext -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From bkearney at redhat.com Mon May 23 12:26:00 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 23 May 2011 08:26:00 -0400 Subject: [katello-devel] CLI client and locale In-Reply-To: <4DDA09AF.5040206@redhat.com> References: <4DD65E65.7060304@redhat.com> <4DD66F16.90009@redhat.com> <4DDA09AF.5040206@redhat.com> Message-ID: <4DDA5258.1020505@redhat.com> On 05/23/2011 03:15 AM, Lukas Zapletal wrote: > On 05/20/2011 03:39 PM, Bryan Kearney wrote: >> Yes, I agree locale should be passed up. I will put this on the backlog. > > Can I take it right away? Because I have a subtask "ensure error > messages are translated" and I will have to add it anyway to properly > test it under the CLI. > kk -- bk From jrist at redhat.com Mon May 23 13:24:14 2011 From: jrist at redhat.com (Jason Rist) Date: Mon, 23 May 2011 07:24:14 -0600 Subject: [katello-devel] Watch out when translating in class context In-Reply-To: <4DDA2102.6040607@redhat.com> References: <4DDA2102.6040607@redhat.com> Message-ID: <4DDA5FFE.4040907@redhat.com> On 05/23/2011 02:55 AM, Lukas Zapletal wrote: > Hello, > > I have found we are using gettext translating incorrectly in quite a lot > places. > > The very basic util function is the underscore one. It is easy to > understand - it translates the string immediately. Like a function call. > > _("Hello World") > > The little issue is in the class context. It gets evaluated before our > I18n code gets initialized. Thus the gettext layer has no clue how to > translate (which language to use for the current user?) and the string > never gets translated. Typical example is in our model classes: > > class Post < ActiveRecord::Base > validates_presence_of :text, :message => _('Hey it's missing!') > end > > Since we use gettext_i18n_rails gem it automatically try to translate > one more time while rendering this string into the session. The key is > to use dynamic util function in this case: > > N_('Hey it's missing!') > > Dynamic util function just "marks" the strings for extraction (rake > gettext:find in our case) so it is available in our po/mo files. It > doesn't do the actual translation. The rails gettext plugin does it for > us in this case. > > If you git-grep our code you will see we are using it. Great. But we use > it in places where we should not do that. And that's the issue. Since it > doesn't do the actual translation our strings are never translated. It's > just all English for these cases. > > Looks like a copy&paste thing. The simple rule is: > > 1) Always use _() or its variants (plurals etc.) > 2) For class context model messages use N_() [*] > 3) For other class context use N_() as well (but you must translate the > string later on otherwise it wont be translated) > > I am not currently aware of other class context in our app. If you find > one the workaround is to use the dynamic variant first and then > translate the string later on: > > before initialization: > > ... > fruit = N_("Apple") # same as fruit = "Apple" > ... > > after initialization: > > ... > _(fruit) # does a normal translation > ... > > > [*] Please keep in mind not all model error messages are in the class > context! In this example you must use _() since the following block is > executed after I18n has already been initialized: > > ... > validate :only_one_rhn_provider > ... > def only_one_rhn_provider > # this is not in class context anymore > if new_record? and provider_type == REDHAT and xyz > errors.add(:base, _("Only one Red Hat provider permitted")) > end > end > ... > > I will fix all the places and put this remark to our I18N wiki page. > More reading: > > https://github.com/grosser/fast_gettext/wiki/activerecord > https://github.com/grosser/gettext_i18n_rails > https://github.com/mutoh/gettext > Good find, Lukas. I didn't know the distinction between _( and N_( -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jason.dobies at redhat.com Mon May 23 17:55:13 2011 From: jason.dobies at redhat.com (Jay Dobies) Date: Mon, 23 May 2011 13:55:13 -0400 Subject: [katello-devel] The Future of RHN Satellite Message-ID: <4DDA9F81.30707@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For those of you who just skim over/filter announce list e-mails, Todd & Todd's "The Future of RHN Satellite" won one of the Top Presenter awards at this year's Summit. Keep in mind that those awards are voted on by attendees, which should help reinforce just how interested people were in what we're doing. So those of you who have just been phoning it in until we found out if people liked the product, ya know, get to work (*glares at Jason Rist*) Congrats to the Todds for their presentation and the Katello team for the massive push to get the demo out. And even to the Pulp team since, let's be honest, that syncing functionality was the coolest part of the demo. - -- Jay Dobies RHCE# 805008743336126 Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN2p+BAAoJEOMmcTqOSQHCllQIAKY90FV8IC2Tq/vkyq6muIet WC6xxbcTN4cEL6fLkPd7peE62BU4ARUUh4+vBUlS9vUI8zSJTvB6NFSFkQofaSfi YK3ggxNHCHxFDSek8AQyf9QvQznzkAqIyl9cxJWwmY8hzZfQrHRtUpb8eSppDGrI rLLX8/GHmSVciR5HQrWgsnju77m5XdtNgoBmXfojGyamLt0/6JXsgF6awsu+2aGl vyTxKSHOCmIDzHW+94LjpCN9Z6CzkwGriXPSUDlqwc+ieS6zgVOaSb8rC99txcIK CxXyhW3UC6vd5V8mlvKXWFkwWF1ItugCVnrSIIo89GzTNWUGPsWa7OxU/075Crc= =s3Jz -----END PGP SIGNATURE----- From bkearney at redhat.com Mon May 23 18:02:47 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 23 May 2011 14:02:47 -0400 Subject: [katello-devel] The Future of RHN Satellite In-Reply-To: <4DDA9F81.30707@redhat.com> References: <4DDA9F81.30707@redhat.com> Message-ID: <4DDAA147.70904@redhat.com> On 05/23/2011 01:55 PM, Jay Dobies wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > For those of you who just skim over/filter announce list e-mails, Todd& > Todd's "The Future of RHN Satellite" won one of the Top Presenter awards > at this year's Summit. > > Keep in mind that those awards are voted on by attendees, which should > help reinforce just how interested people were in what we're doing. So > those of you who have just been phoning it in until we found out if > people liked the product, ya know, get to work (*glares at Jason Rist*) > > Congrats to the Todds for their presentation and the Katello team for > the massive push to get the demo out. And even to the Pulp team since, > let's be honest, that syncing functionality was the coolest part of the > demo. Who says :) -- bk From bbuckingham at redhat.com Mon May 23 19:08:46 2011 From: bbuckingham at redhat.com (Brad Buckingham) Date: Mon, 23 May 2011 15:08:46 -0400 Subject: [katello-devel] Search branch merged to master -> impacts... Message-ID: <4DDAB0BE.7030803@redhat.com> Team, I have just merged the search branch to master. In order to use search, you will need to do the following: - update (or install) the katello rpm in your configuration. This will bring in the following rpm: rubygem-scoped_search-2.3.0-2.fc13.noarch - run rake db:seed With this change, search (for AR data) is available for the following: - providers - systems - organizations - users - roles - notices Note: - The search bar is currently on the Changeset History page; however, we have not yet defined search details for this capability. This will be available in a future commit... :) Thanks, Brad From bkearney at redhat.com Mon May 23 20:35:58 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 23 May 2011 16:35:58 -0400 Subject: [katello-devel] Fwd: [kalpana-devel] Build failed in Jenkins: kalpana-unit #783 Message-ID: <4DDAC52E.8000400@redhat.com> Please to fix the bujild ;) -- bk -------- Original Message -------- Subject: [kalpana-devel] Build failed in Jenkins: kalpana-unit #783 Date: Mon, 23 May 2011 16:06:13 -0400 (EDT) From: LeeroyJenkins at redhat.com Reply-To: Kalpana Development Discussions To: kalpana-devel at redhat.com See Changes: [Amos Benari] added search to organization page. [Amos Benari] updated scoped_search plugin [Amos Benari] added auto complete search rout to all the pages [Amos Benari] updated the search terms. [Amos Benari] added search syntax error notification [Amos Benari] updated the error handling of the syntax auto completer. [Jason E. Rist] Fix for search box width. [Brad Buckingham] Search - add Search to notices [Brad Buckingham] Search - update routes to support environments, users, roles and promotions pages [Brad Buckingham] Search - update seeds.rb for the core pages that we'll be updating to use search [Brad Buckingham] Search - removing search box from kalpana.html.haml and adding to notices [Jason E. Rist] Change to search l&f for non-tupane pages. [Jason E. Rist] Notification row colors. [Jason E. Rist] Change of notices list bg. [Jason E. Rist] Additional search box fixes. [Brad Buckingham] Search - User - initial logic for search [Brad Buckingham] Search - Roles - initial commit [Brad Buckingham] Search - Systems - initial commit [Amos Benari] added search role by tag. [Amos Benari] added search by resource type [Amos Benari] added search role by verb [Brad Buckingham] Search - Provider - updates for search [Brad Buckingham] Search - Notices - align search properties with column names user sees [Brad Buckingham] Search - User/Role - minor cleanups [Brad Buckingham] Search - Provider/Role - renaming some of the search attributes [Jason E. Rist] Added search to tupane. Fixed the L&F for search in tupane. Fixed Role delete. [Brad Buckingham] Search - remove search widget from provider/org/systems index pages [Brad Buckingham] Search - organization - tweaks to search [Jason E. Rist] A bunch of fixes for search and panel chronicled below: [Brad Buckingham] Notices - remove gray background during hover for details [Jason E. Rist] Initial push of fancyQueries integration. Needs more work but getting there. [Brad Buckingham] Search - minor fixes after merge [Justin Sherrill] 704210 - fixing issue where user could be created without a password ------------------------------------------ Started by an SCM change Building remotely on kt-f14-unit.usersys.redhat.com Checkout:kalpana-unit / - hudson.remoting.Channel at 738b19ed:kt-f14-unit.usersys.redhat.com Using strategy: Default Last Built Revision: Revision 1b39f12d28bff578168462d462b8fdc0effaf28b (origin/master) Checkout:kalpana-unit / - hudson.remoting.LocalChannel at 66202088 Fetching changes from the remote Git repository Fetching upstream changes from git://axiom.rdu.redhat.com/scm/git/kalpana Commencing build of Revision 214a48694bdb090a21a3f7c09cc660d8ac380846 (origin/master) Checking out Revision 214a48694bdb090a21a3f7c09cc660d8ac380846 (origin/master) Cleaning workspace [kalpana-unit] $ /bin/sh -xe /tmp/hudson3526993097582346995.sh + ./run-tests.sh Could not find scoped_search-2.3.0 in any of the sources Try running `bundle install`. Could not find scoped_search-2.3.0 in any of the sources Try running `bundle install`. + true Recording test results No test report files were found. Configuration error? From paji at redhat.com Mon May 23 21:40:31 2011 From: paji at redhat.com (Partha Aji) Date: Mon, 23 May 2011 17:40:31 -0400 (EDT) Subject: [katello-devel] Length limits for common things In-Reply-To: <1622834462.230853.1306186185830.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <372136960.231057.1306186831370.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> I am working on a bug dealing with length limits for environment names. Thought this would be a good opportunity to standardize lengths across board. By default rails migration scripts sets the column length for strings to 255 characters. Going by spacewalk experience the standard seems to be 1) Name/Label/Other strings- 128 Varchar 2) Description - 255 Varchar We might have to fix the UI to provide the ability to show 128 characters but that is still better than having a DB exception raised for crossing the column limit. I am planning to add the length validation to KatelloNameValidator since its already used for most of the model names. I might also add a KatelloDescriptionValidator and have it do length checks for descriptions.. If any one has any issues with the suggested lengths please respond. Partha From paji at redhat.com Mon May 23 22:39:36 2011 From: paji at redhat.com (Partha Aji) Date: Mon, 23 May 2011 18:39:36 -0400 (EDT) Subject: [katello-devel] find_or_create_by_#{attr} not a good idea In-Reply-To: <2084295589.231786.1306189277310.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <647090922.232075.1306190376485.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> In the seeds.rb and many other places in the code we have code that looks like user_admin = User.find_or_create_by_username(:username => 'admin', :password => 'admin') Problem here is that the error is not immediately reported even if the validations in the model failed. >From here http://blog.grayproductions.net/articles/five_activerecord_tips the preferred way seems to be separately doing a find and then doing a create! with the exclamation, to fail in the case of validation failures. Wonder if there is way to alias find_or_create_by_#{..} and have it automatically yell if validations fail.. Partha From mmccune at redhat.com Mon May 23 23:52:23 2011 From: mmccune at redhat.com (Mike McCune) Date: Mon, 23 May 2011 16:52:23 -0700 Subject: [katello-devel] Big re-license push Message-ID: <4DDAF337.3000407@redhat.com> Going to push a big diff tomorrow that licenses Katello to GPLv2. This touches every Ruby file with a new license header, eg: --- a/src/lib/ldap.rb +++ b/src/lib/ldap.rb @@ -1,3 +1,17 @@ +# +# Copyright ? 2011 Red Hat, Inc. +# +# This software is licensed to you under the GNU General Public License, +# version 2 (GPLv2). There is NO WARRANTY for this software, express or +# implied, including the implied warranties of MERCHANTABILITY or FITNESS +# FOR A PARTICULAR PURPOSE. You should have received a copy of GPLv2 +# along with this software; if not, see +# http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt. +# +# Red Hat trademarks are not licensed under GPLv2. No permission is +# granted to use or replicate Red Hat trademarks that are incorporated +# in this software or its documentation. + require 'net/ldap' Hopefully this won't cause any merge headaches. Will wait till mid-day tomorrow to make this push. Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From bkearney at redhat.com Tue May 24 01:26:39 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 23 May 2011 21:26:39 -0400 Subject: [katello-devel] Length limits for common things In-Reply-To: <372136960.231057.1306186831370.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <372136960.231057.1306186831370.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4DDB094F.8050604@redhat.com> On 05/23/2011 05:40 PM, Partha Aji wrote: > > > I am working on a bug dealing with length limits for environment names. Thought this would be a good opportunity to standardize lengths across board. By default rails migration scripts sets the column length for strings to 255 characters. Going by spacewalk experience the standard seems to be > > 1) Name/Label/Other strings- 128 Varchar > 2) Description - 255 Varchar > > We might have to fix the UI to provide the ability to show 128 characters but that is still better than having a DB exception raised for crossing the column limit. > > I am planning to add the length validation to KatelloNameValidator since its already used for most of the model names. I might also add a KatelloDescriptionValidator and have it do length checks for descriptions.. > If any one has any issues with the suggested lengths please respond. > > Just to verify. .the ./app/models/katello_name_format_validator.rb is invoked at the glue layer, so both UI and API will get the validation? -- bk From jrist at redhat.com Tue May 24 04:09:15 2011 From: jrist at redhat.com (Jason Rist) Date: Tue, 24 May 2011 00:09:15 -0400 (EDT) Subject: [katello-devel] Big re-license push In-Reply-To: <4DDAF337.3000407@redhat.com> References: <4DDAF337.3000407@redhat.com> Message-ID: Should we do something similar for JS and other files? -J On May 23, 2011, at 5:52 PM, Mike McCune wrote: > Going to push a big diff tomorrow that licenses Katello to GPLv2. > > This touches every Ruby file with a new license header, eg: > > --- a/src/lib/ldap.rb > +++ b/src/lib/ldap.rb > @@ -1,3 +1,17 @@ > +# > +# Copyright ? 2011 Red Hat, Inc. > +# > +# This software is licensed to you under the GNU General Public License, > +# version 2 (GPLv2). There is NO WARRANTY for this software, express or > +# implied, including the implied warranties of MERCHANTABILITY or FITNESS > +# FOR A PARTICULAR PURPOSE. You should have received a copy of GPLv2 > +# along with this software; if not, see > +# http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt. > +# > +# Red Hat trademarks are not licensed under GPLv2. No permission is > +# granted to use or replicate Red Hat trademarks that are incorporated > +# in this software or its documentation. > + > require 'net/ldap' > > Hopefully this won't cause any merge headaches. Will wait till mid-day tomorrow to make this push. > > Mike > -- > 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 lzap at redhat.com Tue May 24 09:23:41 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 24 May 2011 11:23:41 +0200 Subject: [katello-devel] find_or_create_by_#{attr} not a good idea In-Reply-To: <647090922.232075.1306190376485.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <647090922.232075.1306190376485.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4DDB791D.50501@redhat.com> On 05/24/2011 12:39 AM, Partha Aji wrote: > Problem here is that the error is not immediately reported even if the validations in the model failed. The race condition is not a problem for us. The code is safe since we do have unique index on the username column. If there is a race condition (cannot be in our seeds.rb script) an error will be reported through errors array because of index constraint. And the returned object will be nil. But I understand your motivation - no explicit check for nil. But even when we change to find and create! errors wont be reported because of different thing in glue. Some validation errors are rescued, but only put in the errors array (not rethrown) even when exclamation mark method is used. I guess Dmitri should be working on it this sprint. At the end of the day glue layer should raise error when method with exclamation mark is used. Thus we should fix the latter prior to refactoring this. The find_by_xy methods do have exclamation mark versions. It would be nice to have it also for find_or_create, that's for sure. I don't know if it worths to hack it. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From bbuckingham at redhat.com Tue May 24 15:16:47 2011 From: bbuckingham at redhat.com (Brad Buckingham) Date: Tue, 24 May 2011 11:16:47 -0400 Subject: [katello-devel] commit reverted for 'cli - new command repo create' Message-ID: <4DDBCBDF.3040803@redhat.com> Tomas, I apologize for the inconvenience; however, I reverted the commit with subject 'cli - new command repo create'. Unfortunately, the commit appeared to over-write routes.rb (and possibly other files). As a result, any page that included the search capability was non-functional. Since there could have been other files impacted, we decided that it would be best to revert the commit. The original commit was: http://axiom.rdu.redhat.com/git/gitweb.cgi?p=kalpana;a=commit;h=ee49e366da58eecc5581d663346bb37177c63eb6 The revert commit is: http://axiom.rdu.redhat.com/git/gitweb.cgi?p=kalpana;a=commit;h=0dd2f3b8155fdbd03ccd4c831123706a4d9cde2a Please re-merge, verify and push your changes. Thanks, Brad From lzap at redhat.com Tue May 24 15:25:38 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 24 May 2011 17:25:38 +0200 Subject: [katello-devel] commit reverted for 'cli - new command repo create' In-Reply-To: <4DDBCBDF.3040803@redhat.com> References: <4DDBCBDF.3040803@redhat.com> Message-ID: <4DDBCDF2.9020608@redhat.com> On 05/24/2011 05:16 PM, Brad Buckingham wrote: > Please re-merge, verify and push your changes. Hey, let's run unit tests locally prior pushing the changes. The rule is not to rely on Jerkins. He could be sleeping as we can see. And when he is screaming on you it is too late. ;-) -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From jrist at redhat.com Tue May 24 15:39:00 2011 From: jrist at redhat.com (Jason Rist) Date: Tue, 24 May 2011 09:39:00 -0600 Subject: [katello-devel] commit reverted for 'cli - new command repo create' In-Reply-To: <4DDBCDF2.9020608@redhat.com> References: <4DDBCBDF.3040803@redhat.com> <4DDBCDF2.9020608@redhat.com> Message-ID: <4DDBD114.2080102@redhat.com> On 05/24/2011 09:25 AM, Lukas Zapletal wrote: > On 05/24/2011 05:16 PM, Brad Buckingham wrote: >> Please re-merge, verify and push your changes. > > Hey, > > let's run unit tests locally prior pushing the changes. > > The rule is not to rely on Jerkins. He could be sleeping as we can see. > And when he is screaming on you it is too late. ;-) > And at the very least, please run a bit of a sanity check (fire up the server, try to navigate around) if you're messing in areas that might effect other areas. -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 Tue May 24 15:51:11 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 24 May 2011 11:51:11 -0400 Subject: [katello-devel] commit reverted for 'cli - new command repo create' In-Reply-To: <4DDBD114.2080102@redhat.com> References: <4DDBCBDF.3040803@redhat.com> <4DDBCDF2.9020608@redhat.com> <4DDBD114.2080102@redhat.com> Message-ID: <4DDBD3EF.5010507@redhat.com> On 05/24/2011 11:39 AM, Jason Rist wrote: > On 05/24/2011 09:25 AM, Lukas Zapletal wrote: >> On 05/24/2011 05:16 PM, Brad Buckingham wrote: >>> Please re-merge, verify and push your changes. >> >> Hey, >> >> let's run unit tests locally prior pushing the changes. >> >> The rule is not to rely on Jerkins. He could be sleeping as we can see. >> And when he is screaming on you it is too late. ;-) >> > And at the very least, please run a bit of a sanity check (fire up the > server, try to navigate around) if you're messing in areas that might > effect other areas. > > -J > are there any front end tests to automate this? -- bk From mmccune at redhat.com Tue May 24 15:54:37 2011 From: mmccune at redhat.com (Mike McCune) Date: Tue, 24 May 2011 08:54:37 -0700 Subject: [katello-devel] commit reverted for 'cli - new command repo create' In-Reply-To: <4DDBD114.2080102@redhat.com> References: <4DDBCBDF.3040803@redhat.com> <4DDBCDF2.9020608@redhat.com> <4DDBD114.2080102@redhat.com> Message-ID: <4DDBD4BD.3030700@redhat.com> On 05/24/2011 08:39 AM, Jason Rist wrote: > On 05/24/2011 09:25 AM, Lukas Zapletal wrote: >> On 05/24/2011 05:16 PM, Brad Buckingham wrote: >>> Please re-merge, verify and push your changes. >> >> Hey, >> >> let's run unit tests locally prior pushing the changes. >> >> The rule is not to rely on Jerkins. He could be sleeping as we can see. >> And when he is screaming on you it is too late. ;-) >> > And at the very least, please run a bit of a sanity check (fire up the > server, try to navigate around) if you're messing in areas that might > effect other areas. > Here is a simple checklist to refer to if you are asking yourself: "Should I push this change to master?" : https://fedorahosted.org/katello/wiki/DevProcess#BeforeyouCommitCodeToMaster we can add a few things to that table as we see fit. Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From mmccune at redhat.com Tue May 24 15:58:24 2011 From: mmccune at redhat.com (Mike McCune) Date: Tue, 24 May 2011 08:58:24 -0700 Subject: [katello-devel] commit reverted for 'cli - new command repo create' In-Reply-To: <4DDBD3EF.5010507@redhat.com> References: <4DDBCBDF.3040803@redhat.com> <4DDBCDF2.9020608@redhat.com> <4DDBD114.2080102@redhat.com> <4DDBD3EF.5010507@redhat.com> Message-ID: <4DDBD5A0.7060209@redhat.com> On 05/24/2011 08:51 AM, Bryan Kearney wrote: > On 05/24/2011 11:39 AM, Jason Rist wrote: >> On 05/24/2011 09:25 AM, Lukas Zapletal wrote: >>> On 05/24/2011 05:16 PM, Brad Buckingham wrote: >>>> Please re-merge, verify and push your changes. >>> >>> Hey, >>> >>> let's run unit tests locally prior pushing the changes. >>> >>> The rule is not to rely on Jerkins. He could be sleeping as we can see. >>> And when he is screaming on you it is too late. ;-) >>> >> And at the very least, please run a bit of a sanity check (fire up the >> server, try to navigate around) if you're messing in areas that might >> effect other areas. >> >> -J >> > > are there any front end tests to automate this? > no, but we need them. I'll add it to the backlog. Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From shughes at redhat.com Tue May 24 16:39:04 2011 From: shughes at redhat.com (Shannon Hughes) Date: Tue, 24 May 2011 12:39:04 -0400 Subject: [katello-devel] custom JEditable types Message-ID: <4DDBDF28.6090100@redhat.com> Just a fyi that I have created a couple custom input types for JEditable for the sync plans that support JQuery UI calendar dates and time selectors. They are currently in the remote sync-sch branch but will be merging to master when we get the dust settled. If you find yourself needing to create a custom type for JEditable they might help you get started quicker using the plugin feature of JEditable and also feel free to ping me with any questions. Regards, Shannon From mmccune at redhat.com Wed May 25 01:02:27 2011 From: mmccune at redhat.com (Mike McCune) Date: Tue, 24 May 2011 18:02:27 -0700 Subject: [katello-devel] No more commits to master! Message-ID: <4DDC5523.3090605@redhat.com> I spent some time this afternoon looking at the failed unit tests in master and fixed the one in OrganizationsController but there are still 3 remaining that are broken: Failures: 1) ResourcePermissions ResourcePermissions for Candlepin should create set of permissions for new owner and delete after destroy Failure/Error: Candlepin::CandlepinResourcePermissions::after_post_callback('/candlepin/owners/', nil, nil, to_response) ArgumentError: user has no own role # ./app/models/user.rb:100:in `allow' # ./lib/resources/candlepin.rb:55 # ./lib/resource_permissions.rb:79:in `call' # ./lib/resource_permissions.rb:79:in `call_actions' # ./lib/resource_permissions.rb:72:in `each' # ./lib/resource_permissions.rb:72:in `call_actions' # ./lib/resource_permissions.rb:106:in `after_post_callback' # ./spec/models/resource_perm_spec.rb:38 2) Api::RepositoriesController create a repository should call pulp and candlepin layer Failure/Error: post 'create', :name => 'repo_1', :url => 'http://www.repo.org', :product_id => 'product_1' ActionController::RoutingError: No route matches {:action=>"create", :product_id=>"product_1", :name=>"repo_1", :url=>"http://www.repo.org", :controller=>"api/repositories"} # ./spec/controllers/api/repositories_controller_spec.rb:17 3) EnvironmentsController GET edit assigns the requested environment as @environment Failure/Error: get :edit, :id => @env.id, :organization_id => @org.cp_key Mock KPEnvironment(id: integer, name: string, description: string, locker: boolean, organization_id: integer, changeset_id: integer, changeset_history_id: integer, created_at: datetime, updated_at: datetime) received unexpected message :path with (no args) # ./app/controllers/environments_controller.rb:46:in `edit' # ./lib/util/threadsession.rb:79:in `thread_locals' # ./spec/controllers/environments_controller_spec.rb:70 I tried to fix (1) but wasn't quite sure what was going on there. Can we get some volunteers to fix the above issues before *anything* else goes into master? I propose a simple rule: *** No commits to master until unit tests are green *** Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From tsanders at redhat.com Wed May 25 02:03:14 2011 From: tsanders at redhat.com (Todd Sanders) Date: Tue, 24 May 2011 22:03:14 -0400 (EDT) Subject: [katello-devel] No more commits to master! In-Reply-To: <4DDC5523.3090605@redhat.com> References: <4DDC5523.3090605@redhat.com> Message-ID: > > I propose a simple rule: > > *** No commits to master until unit tests are green *** +1. Let's get the unit tests fixed. This is a priority. -Todd > > Mike > -- > 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 lzap at redhat.com Wed May 25 08:50:52 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 May 2011 10:50:52 +0200 Subject: [katello-devel] No more commits to master! In-Reply-To: <4DDC5523.3090605@redhat.com> References: <4DDC5523.3090605@redhat.com> Message-ID: <4DDCC2EC.9080308@redhat.com> On 05/25/2011 03:02 AM, Mike McCune wrote: > 1) ResourcePermissions I fixed the first one. LZ -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From tstrachota at redhat.com Wed May 25 09:13:05 2011 From: tstrachota at redhat.com (Tomas Strachota) Date: Wed, 25 May 2011 11:13:05 +0200 Subject: [katello-devel] No more commits to master! In-Reply-To: <4DDCC2EC.9080308@redhat.com> References: <4DDC5523.3090605@redhat.com> <4DDCC2EC.9080308@redhat.com> Message-ID: <4DDCC821.6030800@redhat.com> On 25/05/11 10:50, Lukas Zapletal wrote: > On 05/25/2011 03:02 AM, Mike McCune wrote: >> 1) ResourcePermissions > > I fixed the first one. > > LZ > And I fixed the second one - creating a repository. Tomas From tstrachota at redhat.com Wed May 25 09:15:38 2011 From: tstrachota at redhat.com (Tomas Strachota) Date: Wed, 25 May 2011 11:15:38 +0200 Subject: [katello-devel] commit reverted for 'cli - new command repo create' In-Reply-To: <4DDBCBDF.3040803@redhat.com> References: <4DDBCBDF.3040803@redhat.com> Message-ID: <4DDCC8BA.6070702@redhat.com> On 24/05/11 17:16, Brad Buckingham wrote: > Tomas, > > I apologize for the inconvenience; however, I reverted the commit with > subject 'cli - new command repo create'. Unfortunately, the commit > appeared to over-write routes.rb (and possibly other files). As a > result, any page that included the search capability was non-functional. > Since there could have been other files impacted, we decided that it > would be best to revert the commit. > > The original commit was: > http://axiom.rdu.redhat.com/git/gitweb.cgi?p=kalpana;a=commit;h=ee49e366da58eecc5581d663346bb37177c63eb6 > > > The revert commit is: > http://axiom.rdu.redhat.com/git/gitweb.cgi?p=kalpana;a=commit;h=0dd2f3b8155fdbd03ccd4c831123706a4d9cde2a > > > Please re-merge, verify and push your changes. > > Thanks, > Brad > My apologies for the problems. My routes.rb merged incorrectly and spec tests (already broken by that time) didn't show me that I introduced new errors. I'll do proper diff check next time and merge to master only when it's not broken. I'll merge the changes again when we have it all back green. Tomas From tstrachota at redhat.com Wed May 25 10:59:35 2011 From: tstrachota at redhat.com (Tomas Strachota) Date: Wed, 25 May 2011 12:59:35 +0200 Subject: [katello-devel] Listing environments Message-ID: <4DDCE117.2080108@redhat.com> Hi, at the moment the api for listing environments omits the locker. I guess it's because of the special role the locker plays. Currently you can access it via /organizations//environments/locker/ because everybody knows its name. But when we switch to use integer IDs for environments, you have no chance to find out what the locker's ID is. Therefore I think we should include it to the list of environments. Opinions? Tomas From bkearney at redhat.com Wed May 25 11:35:58 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 25 May 2011 07:35:58 -0400 Subject: [katello-devel] Listing environments In-Reply-To: <4DDCE117.2080108@redhat.com> References: <4DDCE117.2080108@redhat.com> Message-ID: <4DDCE99E.6010106@redhat.com> On 05/25/2011 06:59 AM, Tomas Strachota wrote: > Hi, > > at the moment the api for listing environments omits the locker. I guess > it's because of the special role the locker plays. > > Currently you can access it via > /organizations//environments/locker/ > because everybody knows its name. But when we switch to use integer IDs > for environments, you have no chance to find out what the locker's ID > is. Therefore I think we should include it to the list of environments. > > Opinions? > I would agree.. as long as we throw errors around deleting the locker.. since that will not be allowed. -- bk From tsanders at redhat.com Wed May 25 12:32:16 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Wed, 25 May 2011 08:32:16 -0400 Subject: [katello-devel] Listing environments In-Reply-To: <4DDCE99E.6010106@redhat.com> References: <4DDCE117.2080108@redhat.com> <4DDCE99E.6010106@redhat.com> Message-ID: <4DDCF6D0.7060903@redhat.com> On 05/25/2011 07:35 AM, Bryan Kearney wrote: > On 05/25/2011 06:59 AM, Tomas Strachota wrote: >> Hi, >> >> at the moment the api for listing environments omits the locker. I guess >> it's because of the special role the locker plays. >> >> Currently you can access it via >> /organizations//environments/locker/ >> because everybody knows its name. But when we switch to use integer IDs >> for environments, you have no chance to find out what the locker's ID >> is. Therefore I think we should include it to the list of environments. >> >> Opinions? >> > > I would agree.. as long as we throw errors around deleting the > locker.. since that will not be allowed. > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel As well as disallow system registration to the locker. Will RHSM use this api to populate an environment selector, if so...the locker would need to be filtered out. -Todd From bkearney at redhat.com Wed May 25 12:47:10 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 25 May 2011 08:47:10 -0400 Subject: [katello-devel] Listing environments In-Reply-To: <4DDCF6D0.7060903@redhat.com> References: <4DDCE117.2080108@redhat.com> <4DDCE99E.6010106@redhat.com> <4DDCF6D0.7060903@redhat.com> Message-ID: <4DDCFA4E.6000505@redhat.com> On 05/25/2011 08:32 AM, Todd B Sanders wrote: > On 05/25/2011 07:35 AM, Bryan Kearney wrote: >> On 05/25/2011 06:59 AM, Tomas Strachota wrote: >>> Hi, >>> >>> at the moment the api for listing environments omits the locker. I guess >>> it's because of the special role the locker plays. >>> >>> Currently you can access it via >>> /organizations//environments/locker/ >>> because everybody knows its name. But when we switch to use integer IDs >>> for environments, you have no chance to find out what the locker's ID >>> is. Therefore I think we should include it to the list of environments. >>> >>> Opinions? >>> >> >> I would agree.. as long as we throw errors around deleting the >> locker.. since that will not be allowed. >> >> -- bk >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > As well as disallow system registration to the locker. Will RHSM use > this api to populate an environment selector, if so...the locker would > need to be filtered out. > > -Todd > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel agreed. -- bk From shughes at redhat.com Wed May 25 14:01:19 2011 From: shughes at redhat.com (Shannon Hughes) Date: Wed, 25 May 2011 10:01:19 -0400 Subject: [katello-devel] No more commits to master! In-Reply-To: <4DDC5523.3090605@redhat.com> References: <4DDC5523.3090605@redhat.com> Message-ID: <4DDD0BAF.6070902@redhat.com> fwiw, here are a couple bash functions I find handy when testing individual rspecs, # spec tests function rsc() { rake spec "SPEC=spec/controllers/${1}_controller_spec.rb";} function rsm() { rake spec "SPEC=spec/models/${1}_spec.rb"; } stick them in your .bashrc regards, shannon On 05/24/2011 09:02 PM, Mike McCune wrote: > I spent some time this afternoon looking at the failed unit tests in > master and fixed the one in OrganizationsController but there are > still 3 remaining that are broken: > > Failures: > > 1) ResourcePermissions ResourcePermissions for Candlepin should > create set of permissions for new owner and delete after destroy > Failure/Error: > Candlepin::CandlepinResourcePermissions::after_post_callback('/candlepin/owners/', > nil, nil, to_response) > ArgumentError: > user has no own role > # ./app/models/user.rb:100:in `allow' > # ./lib/resources/candlepin.rb:55 > # ./lib/resource_permissions.rb:79:in `call' > # ./lib/resource_permissions.rb:79:in `call_actions' > # ./lib/resource_permissions.rb:72:in `each' > # ./lib/resource_permissions.rb:72:in `call_actions' > # ./lib/resource_permissions.rb:106:in `after_post_callback' > # ./spec/models/resource_perm_spec.rb:38 > > 2) Api::RepositoriesController create a repository should call pulp > and candlepin layer > Failure/Error: post 'create', :name => 'repo_1', :url => > 'http://www.repo.org', :product_id => 'product_1' > ActionController::RoutingError: > No route matches {:action=>"create", :product_id=>"product_1", > :name=>"repo_1", :url=>"http://www.repo.org", > :controller=>"api/repositories"} > # ./spec/controllers/api/repositories_controller_spec.rb:17 > > 3) EnvironmentsController GET edit assigns the requested environment > as @environment > Failure/Error: get :edit, :id => @env.id, :organization_id => > @org.cp_key > Mock KPEnvironment(id: integer, name: string, description: > string, locker: boolean, organization_id: integer, changeset_id: > integer, changeset_history_id: integer, created_at: datetime, > updated_at: datetime) received unexpected message :path with (no args) > # ./app/controllers/environments_controller.rb:46:in `edit' > # ./lib/util/threadsession.rb:79:in `thread_locals' > # ./spec/controllers/environments_controller_spec.rb:70 > > > I tried to fix (1) but wasn't quite sure what was going on there. Can > we get some volunteers to fix the above issues before *anything* else > goes into master? > > I propose a simple rule: > > *** No commits to master until unit tests are green *** > > Mike From lzap at redhat.com Wed May 25 15:24:25 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 May 2011 17:24:25 +0200 Subject: [katello-devel] No more commits to master! In-Reply-To: <4DDC5523.3090605@redhat.com> References: <4DDC5523.3090605@redhat.com> Message-ID: <4DDD1F29.2070308@redhat.com> On 05/25/2011 03:02 AM, Mike McCune wrote: > *** No commits to master until unit tests are green *** I did two more commits. One is fix of a bug our QEs found and number two is small change in past-playpen script. Hope it wont get you in troubles. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From paji at redhat.com Wed May 25 17:26:40 2011 From: paji at redhat.com (Partha Aji) Date: Wed, 25 May 2011 13:26:40 -0400 (EDT) Subject: [katello-devel] No more commits to master! In-Reply-To: <4DDD0BAF.6070902@redhat.com> Message-ID: <962325261.282835.1306344400890.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> You can also cd $KATELLO_GIT/src script/run_spec user* to run spec/model/user_spec.rb (searches for user*_spec.rb) Partha ----- Original Message ----- > From: "Shannon Hughes" > To: katello-devel at redhat.com > Sent: Wednesday, May 25, 2011 10:01:19 AM > Subject: Re: [katello-devel] No more commits to master! > fwiw, here are a couple bash functions I find handy when testing > individual rspecs, > > # spec tests > function rsc() { rake spec > "SPEC=spec/controllers/${1}_controller_spec.rb";} > function rsm() { rake spec "SPEC=spec/models/${1}_spec.rb"; } > > stick them in your .bashrc > > regards, > > shannon > > On 05/24/2011 09:02 PM, Mike McCune wrote: > > I spent some time this afternoon looking at the failed unit tests in > > master and fixed the one in OrganizationsController but there are > > still 3 remaining that are broken: > > > > Failures: > > > > 1) ResourcePermissions ResourcePermissions for Candlepin should > > create set of permissions for new owner and delete after destroy > > Failure/Error: > > Candlepin::CandlepinResourcePermissions::after_post_callback('/candlepin/owners/', > > nil, nil, to_response) > > ArgumentError: > > user has no own role > > # ./app/models/user.rb:100:in `allow' > > # ./lib/resources/candlepin.rb:55 > > # ./lib/resource_permissions.rb:79:in `call' > > # ./lib/resource_permissions.rb:79:in `call_actions' > > # ./lib/resource_permissions.rb:72:in `each' > > # ./lib/resource_permissions.rb:72:in `call_actions' > > # ./lib/resource_permissions.rb:106:in `after_post_callback' > > # ./spec/models/resource_perm_spec.rb:38 > > > > 2) Api::RepositoriesController create a repository should call > > pulp > > and candlepin layer > > Failure/Error: post 'create', :name => 'repo_1', :url => > > 'http://www.repo.org', :product_id => 'product_1' > > ActionController::RoutingError: > > No route matches {:action=>"create", > > :product_id=>"product_1", > > :name=>"repo_1", :url=>"http://www.repo.org", > > :controller=>"api/repositories"} > > # ./spec/controllers/api/repositories_controller_spec.rb:17 > > > > 3) EnvironmentsController GET edit assigns the requested > > environment > > as @environment > > Failure/Error: get :edit, :id => @env.id, :organization_id => > > @org.cp_key > > Mock KPEnvironment(id: integer, name: string, description: > > string, locker: boolean, organization_id: integer, changeset_id: > > integer, changeset_history_id: integer, created_at: datetime, > > updated_at: datetime) received unexpected message :path with (no > > args) > > # ./app/controllers/environments_controller.rb:46:in `edit' > > # ./lib/util/threadsession.rb:79:in `thread_locals' > > # ./spec/controllers/environments_controller_spec.rb:70 > > > > > > I tried to fix (1) but wasn't quite sure what was going on there. > > Can > > we get some volunteers to fix the above issues before *anything* > > else > > goes into master? > > > > I propose a simple rule: > > > > *** No commits to master until unit tests are green *** > > > > Mike > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From pkilambi at redhat.com Wed May 25 17:40:26 2011 From: pkilambi at redhat.com (Pradeep Kilambi) Date: Wed, 25 May 2011 13:40:26 -0400 Subject: [katello-devel] Package Profile Capture Design Doc Message-ID: <4DDD3F0A.9070503@redhat.com> Here is the design/spec document for package profile capture story. This will impact both Pulp and Katello. https://fedorahosted.org/pulp/wiki/PackageProfileUpdate Please lemme know if you guys have further thoughts. Thanks, ~ Prad From shughes at redhat.com Wed May 25 17:45:27 2011 From: shughes at redhat.com (Shannon Hughes) Date: Wed, 25 May 2011 13:45:27 -0400 Subject: [katello-devel] No more commits to master! In-Reply-To: <962325261.282835.1306344400890.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <962325261.282835.1306344400890.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4DDD4037.6000208@redhat.com> what would be nice is a way to attach to a existing rails instance to bypass the rails server startup costs that rake performs. did a few google searches this morning and came across spork. On 05/25/2011 01:26 PM, Partha Aji wrote: > You can also > > cd $KATELLO_GIT/src > script/run_spec user* > to run spec/model/user_spec.rb (searches for user*_spec.rb) > > > Partha > > ----- Original Message ----- >> From: "Shannon Hughes" >> To: katello-devel at redhat.com >> Sent: Wednesday, May 25, 2011 10:01:19 AM >> Subject: Re: [katello-devel] No more commits to master! >> fwiw, here are a couple bash functions I find handy when testing >> individual rspecs, >> >> # spec tests >> function rsc() { rake spec >> "SPEC=spec/controllers/${1}_controller_spec.rb";} >> function rsm() { rake spec "SPEC=spec/models/${1}_spec.rb"; } >> >> stick them in your .bashrc >> >> regards, >> >> shannon >> >> On 05/24/2011 09:02 PM, Mike McCune wrote: >>> I spent some time this afternoon looking at the failed unit tests in >>> master and fixed the one in OrganizationsController but there are >>> still 3 remaining that are broken: >>> >>> Failures: >>> >>> 1) ResourcePermissions ResourcePermissions for Candlepin should >>> create set of permissions for new owner and delete after destroy >>> Failure/Error: >>> Candlepin::CandlepinResourcePermissions::after_post_callback('/candlepin/owners/', >>> nil, nil, to_response) >>> ArgumentError: >>> user has no own role >>> # ./app/models/user.rb:100:in `allow' >>> # ./lib/resources/candlepin.rb:55 >>> # ./lib/resource_permissions.rb:79:in `call' >>> # ./lib/resource_permissions.rb:79:in `call_actions' >>> # ./lib/resource_permissions.rb:72:in `each' >>> # ./lib/resource_permissions.rb:72:in `call_actions' >>> # ./lib/resource_permissions.rb:106:in `after_post_callback' >>> # ./spec/models/resource_perm_spec.rb:38 >>> >>> 2) Api::RepositoriesController create a repository should call >>> pulp >>> and candlepin layer >>> Failure/Error: post 'create', :name => 'repo_1', :url => >>> 'http://www.repo.org', :product_id => 'product_1' >>> ActionController::RoutingError: >>> No route matches {:action=>"create", >>> :product_id=>"product_1", >>> :name=>"repo_1", :url=>"http://www.repo.org", >>> :controller=>"api/repositories"} >>> # ./spec/controllers/api/repositories_controller_spec.rb:17 >>> >>> 3) EnvironmentsController GET edit assigns the requested >>> environment >>> as @environment >>> Failure/Error: get :edit, :id => @env.id, :organization_id => >>> @org.cp_key >>> Mock KPEnvironment(id: integer, name: string, description: >>> string, locker: boolean, organization_id: integer, changeset_id: >>> integer, changeset_history_id: integer, created_at: datetime, >>> updated_at: datetime) received unexpected message :path with (no >>> args) >>> # ./app/controllers/environments_controller.rb:46:in `edit' >>> # ./lib/util/threadsession.rb:79:in `thread_locals' >>> # ./spec/controllers/environments_controller_spec.rb:70 >>> >>> >>> I tried to fix (1) but wasn't quite sure what was going on there. >>> Can >>> we get some volunteers to fix the above issues before *anything* >>> else >>> goes into master? >>> >>> I propose a simple rule: >>> >>> *** No commits to master until unit tests are green *** >>> >>> Mike >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Wed May 25 17:56:29 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 May 2011 19:56:29 +0200 Subject: [katello-devel] Superadmin user Message-ID: <4DDD42CD.7030806@redhat.com> Hello, while working on some RBAC changes I am thinking if we can introduce new column for the users table called "admin" or "superadmin". If this flag is set the user is bypassed any authorization code. Advantages: Less static permissions for the first "admin" user. Faster seed script. We could also identify "superusers" in an easy way forbidding deletion of the last superuser. Opinions? -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From jrist at redhat.com Wed May 25 18:12:07 2011 From: jrist at redhat.com (Jason Rist) Date: Wed, 25 May 2011 12:12:07 -0600 Subject: [katello-devel] Superadmin user In-Reply-To: <4DDD42CD.7030806@redhat.com> References: <4DDD42CD.7030806@redhat.com> Message-ID: <4DDD4677.606@redhat.com> On 05/25/2011 11:56 AM, Lukas Zapletal wrote: > Hello, > > while working on some RBAC changes I am thinking if we can introduce new > column for the users table called "admin" or "superadmin". If this flag > is set the user is bypassed any authorization code. > > Advantages: > > Less static permissions for the first "admin" user. > > Faster seed script. > > We could also identify "superusers" in an easy way forbidding deletion > of the last superuser. > > Opinions? > I like it. Seems simple enough. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jharris at redhat.com Wed May 25 18:22:29 2011 From: jharris at redhat.com (Justin Harris) Date: Wed, 25 May 2011 14:22:29 -0400 (EDT) Subject: [katello-devel] Superadmin user In-Reply-To: <4DDD42CD.7030806@redhat.com> References: <4DDD42CD.7030806@redhat.com> Message-ID: FWIW we are doing something similar in Candlepin. On Wed, 25 May 2011, Lukas Zapletal wrote: > Hello, > > while working on some RBAC changes I am thinking if we can introduce new > column for the users table called "admin" or "superadmin". If this flag is > set the user is bypassed any authorization code. > > Advantages: > > Less static permissions for the first "admin" user. > > Faster seed script. > > We could also identify "superusers" in an easy way forbidding deletion of the > last superuser. > > Opinions? > > -- > Later, > > Lukas Zapletal | E32E400A > RHN Satellite Engineering > Red Hat Czech s.r.o. Brno > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Wed May 25 18:23:21 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 25 May 2011 20:23:21 +0200 Subject: [katello-devel] Superadmin user In-Reply-To: References: <4DDD42CD.7030806@redhat.com> Message-ID: <4DDD4919.7080702@redhat.com> On 05/25/2011 08:22 PM, Justin Harris wrote: > FWIW we are doing something similar in Candlepin. To be honest I just saw the same in the Foreman :-) -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From jweiss at redhat.com Wed May 25 19:42:40 2011 From: jweiss at redhat.com (Jeff Weiss) Date: Wed, 25 May 2011 15:42:40 -0400 Subject: [katello-devel] No more commits to master! In-Reply-To: <4DDC5523.3090605@redhat.com> References: <4DDC5523.3090605@redhat.com> Message-ID: <1306352560.4768.6.camel@blinky> On Tue, 2011-05-24 at 18:02 -0700, Mike McCune wrote: > I spent some time this afternoon looking at the failed unit tests in > master and fixed the one in OrganizationsController but there are still > 3 remaining that are broken: > > Failures: > > 1) ResourcePermissions ResourcePermissions for Candlepin should > create set of permissions for new owner and delete after destroy > Failure/Error: > Candlepin::CandlepinResourcePermissions::after_post_callback('/candlepin/owners/', > nil, nil, to_response) > ArgumentError: > user has no own role > # ./app/models/user.rb:100:in `allow' > # ./lib/resources/candlepin.rb:55 > # ./lib/resource_permissions.rb:79:in `call' > # ./lib/resource_permissions.rb:79:in `call_actions' > # ./lib/resource_permissions.rb:72:in `each' > # ./lib/resource_permissions.rb:72:in `call_actions' > # ./lib/resource_permissions.rb:106:in `after_post_callback' > # ./spec/models/resource_perm_spec.rb:38 > > 2) Api::RepositoriesController create a repository should call pulp > and candlepin layer > Failure/Error: post 'create', :name => 'repo_1', :url => > 'http://www.repo.org', :product_id => 'product_1' > ActionController::RoutingError: > No route matches {:action=>"create", :product_id=>"product_1", > :name=>"repo_1", :url=>"http://www.repo.org", > :controller=>"api/repositories"} > # ./spec/controllers/api/repositories_controller_spec.rb:17 > > 3) EnvironmentsController GET edit assigns the requested environment > as @environment > Failure/Error: get :edit, :id => @env.id, :organization_id => > @org.cp_key > Mock KPEnvironment(id: integer, name: string, description: > string, locker: boolean, organization_id: integer, changeset_id: > integer, changeset_history_id: integer, created_at: datetime, > updated_at: datetime) received unexpected message :path with (no args) > # ./app/controllers/environments_controller.rb:46:in `edit' > # ./lib/util/threadsession.rb:79:in `thread_locals' > # ./spec/controllers/environments_controller_spec.rb:70 > > > I tried to fix (1) but wasn't quite sure what was going on there. Can > we get some volunteers to fix the above issues before *anything* else > goes into master? > > I propose a simple rule: > > *** No commits to master until unit tests are green *** > > Mike I propose that we at least redefine master to mean all unit tests are green (meaning no commits pushed to master until the unit tests all pass on that commit). How that's accomplished is up to dev, but I should point out that hudson is capable of polling ALL branches for commits and kicking off unit tests on them. So you could just commit on your branch, wait a few minutes for hudson to test it, and if it passes, merge to master. Jeff From paji at redhat.com Wed May 25 23:34:50 2011 From: paji at redhat.com (Partha Aji) Date: Wed, 25 May 2011 19:34:50 -0400 (EDT) Subject: [katello-devel] Minor tweak on Organization.create! Message-ID: <810689748.291108.1306366490261.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Based of this bug https://bugzilla.redhat.com/show_bug.cgi?id=692643, I made Organization.create! require an :initial_environment_name field. I have updated the seed scripts and the unit tests, but if you had scripts creating orgs you might need to update them to include :initial_environment_name Partha From bkearney at redhat.com Thu May 26 00:46:12 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 25 May 2011 20:46:12 -0400 Subject: [katello-devel] Minor tweak on Organization.create! In-Reply-To: <810689748.291108.1306366490261.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <810689748.291108.1306366490261.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4DDDA2D4.6040207@redhat.com> On 05/25/2011 07:34 PM, Partha Aji wrote: > > Based of this bug https://bugzilla.redhat.com/show_bug.cgi?id=692643, I made Organization.create! require an :initial_environment_name field. I have updated the seed scripts and the unit tests, but if you had scripts creating orgs you might need to update them to include :initial_environment_name > > > Partha > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Should the API force this? I am fine with the UI doing 2 calls.. but it seems odd to force this via the API. -- bk From bkearney at redhat.com Thu May 26 01:13:05 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 25 May 2011 21:13:05 -0400 Subject: [katello-devel] Superadmin user In-Reply-To: References: <4DDD42CD.7030806@redhat.com> Message-ID: <4DDDA921.30607@redhat.com> On 05/25/2011 02:22 PM, Justin Harris wrote: > > > FWIW we are doing something similar in Candlepin. > I thouhgt the role was a superadmin? -- bk From bkearney at redhat.com Thu May 26 01:13:32 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 25 May 2011 21:13:32 -0400 Subject: [katello-devel] Superadmin user In-Reply-To: <4DDD4919.7080702@redhat.com> References: <4DDD42CD.7030806@redhat.com> <4DDD4919.7080702@redhat.com> Message-ID: <4DDDA93C.6010206@redhat.com> On 05/25/2011 02:23 PM, Lukas Zapletal wrote: > On 05/25/2011 08:22 PM, Justin Harris wrote: >> FWIW we are doing something similar in Candlepin. > > To be honest I just saw the same in the Foreman :-) > And this overrides what is in LDAP? -- bk From ohadlevy at redhat.com Thu May 26 06:16:36 2011 From: ohadlevy at redhat.com (Ohad Levy) Date: Thu, 26 May 2011 09:16:36 +0300 Subject: [katello-devel] Superadmin user In-Reply-To: <4DDDA93C.6010206@redhat.com> References: <4DDD42CD.7030806@redhat.com> <4DDD4919.7080702@redhat.com> <4DDDA93C.6010206@redhat.com> Message-ID: <1306390596.11559.1.camel@super.tlv.redhat.com> On Wed, 2011-05-25 at 21:13 -0400, Bryan Kearney wrote: > On 05/25/2011 02:23 PM, Lukas Zapletal wrote: > > On 05/25/2011 08:22 PM, Justin Harris wrote: > >> FWIW we are doing something similar in Candlepin. > > > > To be honest I just saw the same in the Foreman :-) > > > And this overrides what is in LDAP? foreman supports both internal auth and ldap auth, so in this case, the admin is an internal account. additionally, all accounts are local (e.g in the db) but authentication can happen with any external source. Probably need to add a way to remove accounts once the ldap account is removed. (it wont work as it cant auth but thats another story). Ohad From lzap at redhat.com Thu May 26 08:54:38 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 26 May 2011 10:54:38 +0200 Subject: [katello-devel] Table names check-up Message-ID: <4DDE154E.4080806@redhat.com> Hello, if I take a look at our table names it looks good: >> ActiveRecord::Base.connection.tables.each { |t| puts t } schema_migrations (*) organizations environments environment_priors products kp_environments_products (**) providers changesets changeset_histories users roles verbs resource_types tags permissions permissions_verbs permissions_tags roles_users changesets_products help_tips notices user_notices systems changeset_packages changeset_errata (*) this one is Rails' one (**) we might like to remove the prefix for this one (like for environments) If you see any issues let others know. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From tsanders at redhat.com Thu May 26 11:05:56 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Thu, 26 May 2011 07:05:56 -0400 Subject: [katello-devel] Superadmin user In-Reply-To: <1306390596.11559.1.camel@super.tlv.redhat.com> References: <4DDD42CD.7030806@redhat.com> <4DDD4919.7080702@redhat.com> <4DDDA93C.6010206@redhat.com> <1306390596.11559.1.camel@super.tlv.redhat.com> Message-ID: <4DDE3414.1060507@redhat.com> On 05/26/2011 02:16 AM, Ohad Levy wrote: > On Wed, 2011-05-25 at 21:13 -0400, Bryan Kearney wrote: >> On 05/25/2011 02:23 PM, Lukas Zapletal wrote: >>> On 05/25/2011 08:22 PM, Justin Harris wrote: >>>> FWIW we are doing something similar in Candlepin. >>> To be honest I just saw the same in the Foreman :-) >>> >> And this overrides what is in LDAP? > foreman supports both internal auth and ldap auth, so in this case, the > admin is an internal account. > > additionally, all accounts are local (e.g in the db) but authentication > can happen with any external source. This approach is similar to what's in current satellite, using PAM for external authentication. But honestly, we get push back from customers having to manage users in multiple places. I'd prefer an approach where accounts are either internal or external, not both. -Todd > Probably need to add a way to remove accounts once the ldap account is > removed. (it wont work as it cant auth but thats another story). > > Ohad > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Thu May 26 11:20:35 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 26 May 2011 13:20:35 +0200 Subject: [katello-devel] Installing Katello under RVM Message-ID: <4DDE3783.8080902@redhat.com> Hello, after Fedora 15 upgrade I have decided to try installing Katello in RVM. This tool lets you install Ruby and all the gems in a separate directories. Here is a short tutorial. It installs everything into the $HOME/.rvm directory and does not need root privileges: # bash < <(curl -s https://rvm.beginrescueend.com/install/rvm) Follow on-screen instructions and add the rvm script to your .bashrc. # rvm install 1.8.7 # rvm use 1.8.7 # rvm gemset create katello # rvm use 1.8.7 at katello # gem install bundler # bundle install # rails server Katello is running. After you logout you wont be able to run the Rails server and you need to select the gemset again: # rails server rails: command not found # rvm use 1.8.7 at katello # rails server You can also create gemsets for separate Ruby projects and keep your global rubygems directory clean. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From ohadlevy at redhat.com Thu May 26 11:31:18 2011 From: ohadlevy at redhat.com (Ohad Levy) Date: Thu, 26 May 2011 14:31:18 +0300 Subject: [katello-devel] Superadmin user In-Reply-To: <4DDE3414.1060507@redhat.com> References: <4DDD42CD.7030806@redhat.com> <4DDD4919.7080702@redhat.com> <4DDDA93C.6010206@redhat.com> <1306390596.11559.1.camel@super.tlv.redhat.com> <4DDE3414.1060507@redhat.com> Message-ID: <1306409478.3242.4.camel@super.tlv.redhat.com> On Thu, 2011-05-26 at 07:05 -0400, Todd B Sanders wrote: > > This approach is similar to what's in current satellite, using PAM > for > external authentication. But honestly, we get push back from > customers > having to manage users in multiple places. I'd prefer an approach > where > accounts are either internal or external, not both. > The main reasons I've added internal user data were: 1. additional properties (timezone, permissions etc) 2. nested usergroup (something that ldap cant do at the moment) 3. community asked for a simple built in account management (not always ldap/AD). to ensure synchronization between accounts, every time a user logs in, we take the values from ldap/AD and refresh the local db (i.e. if the email address was changed). when deleting an account, who owns the machines then? in foreman, you can't delete an account who owns hosts (direct ownership)... but in any case, the account can't be used if the user can't authenticate. Ohad From gkhachik at redhat.com Thu May 26 12:00:15 2011 From: gkhachik at redhat.com (Garik Khachikyan) Date: Thu, 26 May 2011 14:00:15 +0200 Subject: [katello-devel] Minor tweak on Organization.create! In-Reply-To: <810689748.291108.1306366490261.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <810689748.291108.1306366490261.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4DDE40CF.8000903@redhat.com> On 05/26/2011 01:34 AM, Partha Aji wrote: > Based of this bug https://bugzilla.redhat.com/show_bug.cgi?id=692643, I made Organization.create! require an :initial_environment_name field. I have updated the seed scripts and the unit tests, but if you had scripts creating orgs you might need to update them to include :initial_environment_name > > > Partha > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Partha, May I ask why the initial_environment_name is made mandatory (and not optional, let's say) - as right after org creation it's possible (/me tried UI) to remove the prepared initial environment and make the org to be without any env at all. I supposed the need of mandatory initial env. will force having at least one (default) env associated to it? thanks, Garik. From tsanders at redhat.com Thu May 26 12:01:25 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Thu, 26 May 2011 08:01:25 -0400 Subject: [katello-devel] Superadmin user In-Reply-To: <1306409478.3242.4.camel@super.tlv.redhat.com> References: <4DDD42CD.7030806@redhat.com> <4DDD4919.7080702@redhat.com> <4DDDA93C.6010206@redhat.com> <1306390596.11559.1.camel@super.tlv.redhat.com> <4DDE3414.1060507@redhat.com> <1306409478.3242.4.camel@super.tlv.redhat.com> Message-ID: <4DDE4115.4020908@redhat.com> On 05/26/2011 07:31 AM, Ohad Levy wrote: > On Thu, 2011-05-26 at 07:05 -0400, Todd B Sanders wrote: >> This approach is similar to what's in current satellite, using PAM >> for >> external authentication. But honestly, we get push back from >> customers >> having to manage users in multiple places. I'd prefer an approach >> where >> accounts are either internal or external, not both. >> > The main reasons I've added internal user data were: > > 1. additional properties (timezone, permissions etc) > 2. nested usergroup (something that ldap cant do at the moment) > 3. community asked for a simple built in account management (not always > ldap/AD). > > to ensure synchronization between accounts, every time a user logs in, > we take the values from ldap/AD and refresh the local db (i.e. if the > email address was changed). > > when deleting an account, who owns the machines then? in foreman, you > can't delete an account who owns hosts (direct ownership)... > but in any case, the account can't be used if the user can't > authenticate. > > Ohad > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Makes sense. I didn't catch the sync process in the original thread. As long as we are handling the the burden of having to maintain similar information, and allowing management in one place.....this will alleviate my concerns. -Todd From lzap at redhat.com Thu May 26 13:21:24 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 26 May 2011 15:21:24 +0200 Subject: [katello-devel] Installing Katello under RVM In-Reply-To: <4DDE3783.8080902@redhat.com> References: <4DDE3783.8080902@redhat.com> Message-ID: <4DDE53D4.7050100@redhat.com> On 05/26/2011 01:20 PM, Lukas Zapletal wrote: > after Fedora 15 upgrade I have decided to try installing Katello in RVM. > This tool lets you install Ruby and all the gems in a separate directories. I have put this on the wiki https://engineering.redhat.com/trac/kalpana/wiki/KatelloRVM -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From jharris at redhat.com Thu May 26 13:21:34 2011 From: jharris at redhat.com (Justin Harris) Date: Thu, 26 May 2011 09:21:34 -0400 (EDT) Subject: [katello-devel] Superadmin user In-Reply-To: <4DDDA921.30607@redhat.com> Message-ID: <1129643077.214224.1306416094764.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 05/25/2011 02:22 PM, Justin Harris wrote: > > > > > > FWIW we are doing something similar in Candlepin. > > > > I thouhgt the role was a superadmin? > -- bk Without going into it too much, roles are only applicable to user principals, where many principal types (system, etc.) can be allowed full access. So only users have various roles, but the "admin" flag is on the principal itself. - Justin From jesusr at redhat.com Thu May 26 13:55:03 2011 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 26 May 2011 09:55:03 -0400 Subject: [katello-devel] Package Profile Capture Design Doc In-Reply-To: <4DDD3F0A.9070503@redhat.com> References: <4DDD3F0A.9070503@redhat.com> Message-ID: <4DDE5BB7.90201@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/25/2011 01:40 PM, Pradeep Kilambi wrote: > > Here is the design/spec document for package profile capture story. This > will impact both Pulp and Katello. > > https://fedorahosted.org/pulp/wiki/PackageProfileUpdate > > Please lemme know if you guys have further thoughts. > > Thanks, > ~ Prad > > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Instead of pulp-client-utils how about calling it Mache. As in Paper Mache which is made from wood pulp. And you can build things with paper mache. http://en.wikipedia.org/wiki/Papier-m%C3%A2ch%C3%A9 Just my 2 pesos. 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 | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3eW7cACgkQvJZ57YntiYPcbwCfdJL4dD4B4xhzEwXl5IzAJkFL uT0AmgM0Hhw/uI1i1GfBfvWGPYTVeHKi =/UEs -----END PGP SIGNATURE----- From pkilambi at redhat.com Thu May 26 14:00:36 2011 From: pkilambi at redhat.com (Pradeep Kilambi) Date: Thu, 26 May 2011 10:00:36 -0400 Subject: [katello-devel] Package Profile Capture Design Doc In-Reply-To: <4DDE5BB7.90201@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> Message-ID: <4DDE5D04.4080509@redhat.com> On 05/26/2011 09:55 AM, jesus m. rodriguez wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/25/2011 01:40 PM, Pradeep Kilambi wrote: >> Here is the design/spec document for package profile capture story. This >> will impact both Pulp and Katello. >> >> https://fedorahosted.org/pulp/wiki/PackageProfileUpdate >> >> Please lemme know if you guys have further thoughts. >> >> Thanks, >> ~ Prad >> >> >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Instead of pulp-client-utils how about calling it Mache. > As in Paper Mache which is made from wood pulp. > And you can build things with paper mache. > > http://en.wikipedia.org/wiki/Papier-m%C3%A2ch%C3%A9 > > Just my 2 pesos. > > jesus Hehe cool name. Todd what do you think? I'll be filing for a project hosting request today. If we can agree on the name, I'll go ahead with filing the ticket. ~ Prad From tsanders at redhat.com Thu May 26 14:05:40 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Thu, 26 May 2011 10:05:40 -0400 Subject: [katello-devel] Package Profile Capture Design Doc In-Reply-To: <4DDE5D04.4080509@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> <4DDE5D04.4080509@redhat.com> Message-ID: <4DDE5E34.6020700@redhat.com> On 05/26/2011 10:00 AM, Pradeep Kilambi wrote: > On 05/26/2011 09:55 AM, jesus m. rodriguez wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 05/25/2011 01:40 PM, Pradeep Kilambi wrote: >>> Here is the design/spec document for package profile capture story. >>> This >>> will impact both Pulp and Katello. >>> >>> https://fedorahosted.org/pulp/wiki/PackageProfileUpdate >>> >>> Please lemme know if you guys have further thoughts. >>> >>> Thanks, >>> ~ Prad >>> >>> >>> >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> Instead of pulp-client-utils how about calling it Mache. >> As in Paper Mache which is made from wood pulp. >> And you can build things with paper mache. >> >> http://en.wikipedia.org/wiki/Papier-m%C3%A2ch%C3%A9 >> >> Just my 2 pesos. >> >> jesus > > Hehe cool name. Todd what do you think? I'll be filing for a project > hosting request today. If we can agree on the name, I'll go ahead with > filing the ticket. > > ~ Prad > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel What am I missing? Why a separate project for this? .....as this is just part of the pulp client-side tooling. The reason we are pulling into a separate rpm is so that is can more easily be leveraged by additional clients (i.e. RHSM). -Todd -Todd From jason.dobies at redhat.com Thu May 26 14:14:41 2011 From: jason.dobies at redhat.com (Jay Dobies) Date: Thu, 26 May 2011 10:14:41 -0400 Subject: [katello-devel] [pulp-internal] Package Profile Capture Design Doc In-Reply-To: <4DDD3F0A.9070503@redhat.com> References: <4DDD3F0A.9070503@redhat.com> Message-ID: <4DDE6051.3060703@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/25/2011 01:40 PM, Pradeep Kilambi wrote: > > Here is the design/spec document for package profile capture story. This > will impact both Pulp and Katello. > > https://fedorahosted.org/pulp/wiki/PackageProfileUpdate > > Please lemme know if you guys have further thoughts. Under things in pulp-client-utils, what does "Package profile Module (for rpms, jars etc) " mean? How does the certificate bundle relate to package profile updating? Is it just for reading the consumer certificate to extract what's needed to update Pulp/Katello? The plugin will "# initialize pulp/katello server connection " - what sort of security is in place for that connection? Will the yum plugin require anything extra from the user make sure someone couldn't come along and use the APIs to blank out all of the consumer's package profiles? You probably want to add something about timing out if Pulp/Katello can't be contacted. We don't want yum hanging just because the profile update is taking a while. Even if it's not implemented in this sprint, it should be in the design document. "Not Registered; cannot update consumer profile." That should be a bit more useful, at least telling the user what it is they aren't registered to. "* The above flow is for pulp-profile-update plugin. Ketello plugin will do something similar talking to katello api " Just to make sure I'm clear, this isn't a new plugin model per se, just a library that retrieves/formats the profile information, right? Pulp and Katello each then maintain separate yum plugins that take the necessary steps to communicate that information to their respective projects? For what it's worth, you might want to restructure the page to show that distinction better. It's really two concepts here: the common library for extracting the profile information and then the Pulp-specific yum plugin and gofer hooks. It's a bit hard to figure out which pieces go where the way it's laid out. - -- Jay Dobies RHCE# 805008743336126 Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN3mBRAAoJEOMmcTqOSQHChwkH/0fl7H4+1qe3/2dPFZBg1Kvm I6ZNl1euG/NSyAiRv0oXRennYirjzmyf0cgaDpjzNDE0s9+74rpsy0DK8+dzzlf3 Vqy8Y3rrjJkLCY6mKeuMYyCdBHw/HSSuPcpIL8Rcn2yoxrgghSsf4igwestlxBiv Q9hdJPM5t+Vjdx4s0hy3DAXh1BPhGpxGWXU/ZkQGT7H6iz7UZF/DoRG0gHsUaGjc XlqUfLFYdViWEAuWo/eoKjmL5MuvIIjnlTZpMSikjFmkN3j2YXIzB+FOlHouxYEU DKXOEvwZJqllzWFKGuELAM9UbHhXeDt+iPvn0aBA5mQbC0c+BO8s9W/yVmG/g8E= =yV8W -----END PGP SIGNATURE----- From pkilambi at redhat.com Thu May 26 14:22:52 2011 From: pkilambi at redhat.com (Pradeep Kilambi) Date: Thu, 26 May 2011 10:22:52 -0400 Subject: [katello-devel] Package Profile Capture Design Doc In-Reply-To: <4DDE5E34.6020700@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> <4DDE5D04.4080509@redhat.com> <4DDE5E34.6020700@redhat.com> Message-ID: <4DDE623C.3000100@redhat.com> On 05/26/2011 10:05 AM, Todd B Sanders wrote: > On 05/26/2011 10:00 AM, Pradeep Kilambi wrote: >> On 05/26/2011 09:55 AM, jesus m. rodriguez wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 05/25/2011 01:40 PM, Pradeep Kilambi wrote: >>>> Here is the design/spec document for package profile capture story. >>>> This >>>> will impact both Pulp and Katello. >>>> >>>> https://fedorahosted.org/pulp/wiki/PackageProfileUpdate >>>> >>>> Please lemme know if you guys have further thoughts. >>>> >>>> Thanks, >>>> ~ Prad >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> Instead of pulp-client-utils how about calling it Mache. >>> As in Paper Mache which is made from wood pulp. >>> And you can build things with paper mache. >>> >>> http://en.wikipedia.org/wiki/Papier-m%C3%A2ch%C3%A9 >>> >>> Just my 2 pesos. >>> >>> jesus >> >> Hehe cool name. Todd what do you think? I'll be filing for a project >> hosting request today. If we can agree on the name, I'll go ahead >> with filing the ticket. >> >> ~ Prad >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > What am I missing? Why a separate project for this? .....as this is > just part of the pulp client-side tooling. The reason we are pulling > into a separate rpm is so that is can more easily be leveraged by > additional clients (i.e. RHSM). > > -Todd > > -Todd We can use it under same pulp project. Since this is a separate tool shared between katello, pulp and RHSM and need to get into brew at some point for RHEL, I was thinking it would be easier if its not tied up with pulp itself. This is a package pulp, ketello/rhsm will require. So might have a case where we want newer builds for this package outside of pulp itself ? ~ Prad From jesusr at redhat.com Thu May 26 14:27:18 2011 From: jesusr at redhat.com (jesus m. rodriguez) Date: Thu, 26 May 2011 10:27:18 -0400 Subject: [katello-devel] Package Profile Capture Design Doc In-Reply-To: <4DDE623C.3000100@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> <4DDE5D04.4080509@redhat.com> <4DDE5E34.6020700@redhat.com> <4DDE623C.3000100@redhat.com> Message-ID: <4DDE6346.3060901@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2011 10:22 AM, Pradeep Kilambi wrote: > On 05/26/2011 10:05 AM, Todd B Sanders wrote: >> On 05/26/2011 10:00 AM, Pradeep Kilambi wrote: >>> On 05/26/2011 09:55 AM, jesus m. rodriguez wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 05/25/2011 01:40 PM, Pradeep Kilambi wrote: >>>>> Here is the design/spec document for package profile capture story. >>>>> This >>>>> will impact both Pulp and Katello. >>>>> >>>>> https://fedorahosted.org/pulp/wiki/PackageProfileUpdate >>>>> >>>>> Please lemme know if you guys have further thoughts. >>>>> >>>>> Thanks, >>>>> ~ Prad >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> katello-devel mailing list >>>>> katello-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> Instead of pulp-client-utils how about calling it Mache. >>>> As in Paper Mache which is made from wood pulp. >>>> And you can build things with paper mache. >>>> >>>> http://en.wikipedia.org/wiki/Papier-m%C3%A2ch%C3%A9 >>>> >>>> Just my 2 pesos. >>>> >>>> jesus >>> >>> Hehe cool name. Todd what do you think? I'll be filing for a project >>> hosting request today. If we can agree on the name, I'll go ahead >>> with filing the ticket. >>> >>> ~ Prad >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> What am I missing? Why a separate project for this? .....as this is >> just part of the pulp client-side tooling. The reason we are pulling >> into a separate rpm is so that is can more easily be leveraged by >> additional clients (i.e. RHSM). >> >> -Todd >> >> -Todd > > We can use it under same pulp project. Since this is a separate tool > shared between katello, pulp and RHSM and need to get into brew at some > point for RHEL, I was thinking it would be easier if its not tied up > with pulp itself. This is a package pulp, ketello/rhsm will require. So > might have a case where we want newer builds for this package outside of > pulp itself ? > > ~ Prad You have a couple options: 1) keep it in the same tree as pulp following the pulp release cycle 2) put it as separate git repo on fedora but link to it from the pulp wiki and mailing list. That's what we did with Thumbslug and Headpin. They are their own repos but linked from the Candelpin wiki. This way you get to have a clean repo people can contribute to and maintain it on a separate release schedule if needed. 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 | +---------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3eY0YACgkQvJZ57YntiYOe4wCgw14/kT1bAZJA3SES5nqv6Lrd QlMAoIQQ0Q3+3VZE0Qeq+CwDkLFBZrgw =AWbH -----END PGP SIGNATURE----- From pkilambi at redhat.com Thu May 26 14:34:31 2011 From: pkilambi at redhat.com (Pradeep Kilambi) Date: Thu, 26 May 2011 10:34:31 -0400 Subject: [katello-devel] Package Profile Capture Design Doc In-Reply-To: <4DDE6346.3060901@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> <4DDE5D04.4080509@redhat.com> <4DDE5E34.6020700@redhat.com> <4DDE623C.3000100@redhat.com> <4DDE6346.3060901@redhat.com> Message-ID: <4DDE64F7.2000803@redhat.com> On 05/26/2011 10:27 AM, jesus m. rodriguez wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/26/2011 10:22 AM, Pradeep Kilambi wrote: >> On 05/26/2011 10:05 AM, Todd B Sanders wrote: >>> On 05/26/2011 10:00 AM, Pradeep Kilambi wrote: >>>> On 05/26/2011 09:55 AM, jesus m. rodriguez wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> On 05/25/2011 01:40 PM, Pradeep Kilambi wrote: >>>>>> Here is the design/spec document for package profile capture story. >>>>>> This >>>>>> will impact both Pulp and Katello. >>>>>> >>>>>> https://fedorahosted.org/pulp/wiki/PackageProfileUpdate >>>>>> >>>>>> Please lemme know if you guys have further thoughts. >>>>>> >>>>>> Thanks, >>>>>> ~ Prad >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> katello-devel mailing list >>>>>> katello-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>> Instead of pulp-client-utils how about calling it Mache. >>>>> As in Paper Mache which is made from wood pulp. >>>>> And you can build things with paper mache. >>>>> >>>>> http://en.wikipedia.org/wiki/Papier-m%C3%A2ch%C3%A9 >>>>> >>>>> Just my 2 pesos. >>>>> >>>>> jesus >>>> Hehe cool name. Todd what do you think? I'll be filing for a project >>>> hosting request today. If we can agree on the name, I'll go ahead >>>> with filing the ticket. >>>> >>>> ~ Prad >>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>> What am I missing? Why a separate project for this? .....as this is >>> just part of the pulp client-side tooling. The reason we are pulling >>> into a separate rpm is so that is can more easily be leveraged by >>> additional clients (i.e. RHSM). >>> >>> -Todd >>> >>> -Todd >> We can use it under same pulp project. Since this is a separate tool >> shared between katello, pulp and RHSM and need to get into brew at some >> point for RHEL, I was thinking it would be easier if its not tied up >> with pulp itself. This is a package pulp, ketello/rhsm will require. So >> might have a case where we want newer builds for this package outside of >> pulp itself ? >> >> ~ Prad > You have a couple options: > > 1) keep it in the same tree as pulp following the pulp release cycle > > 2) put it as separate git repo on fedora but link to it from the > pulp wiki and mailing list. That's what we did with Thumbslug and > Headpin. They are their own repos but linked from the Candelpin wiki. > > This way you get to have a clean repo people can contribute to and > maintain it on a separate release schedule if needed. > > jesus Option-2 makes sense to me. I dont think we should bind the release cycle of a shared library package with pulp itself. ~ Prad > - -- > 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 | > +---------------------------------------------+ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk3eY0YACgkQvJZ57YntiYOe4wCgw14/kT1bAZJA3SES5nqv6Lrd > QlMAoIQQ0Q3+3VZE0Qeq+CwDkLFBZrgw > =AWbH > -----END PGP SIGNATURE----- From tsanders at redhat.com Thu May 26 14:39:01 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Thu, 26 May 2011 10:39:01 -0400 Subject: [katello-devel] Package Profile Capture Design Doc In-Reply-To: <4DDE64F7.2000803@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> <4DDE5D04.4080509@redhat.com> <4DDE5E34.6020700@redhat.com> <4DDE623C.3000100@redhat.com> <4DDE6346.3060901@redhat.com> <4DDE64F7.2000803@redhat.com> Message-ID: <4DDE6605.8080407@redhat.com> On 05/26/2011 10:34 AM, Pradeep Kilambi wrote: > On 05/26/2011 10:27 AM, jesus m. rodriguez wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 05/26/2011 10:22 AM, Pradeep Kilambi wrote: >>> On 05/26/2011 10:05 AM, Todd B Sanders wrote: >>>> On 05/26/2011 10:00 AM, Pradeep Kilambi wrote: >>>>> On 05/26/2011 09:55 AM, jesus m. rodriguez wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> On 05/25/2011 01:40 PM, Pradeep Kilambi wrote: >>>>>>> Here is the design/spec document for package profile capture story. >>>>>>> This >>>>>>> will impact both Pulp and Katello. >>>>>>> >>>>>>> https://fedorahosted.org/pulp/wiki/PackageProfileUpdate >>>>>>> >>>>>>> Please lemme know if you guys have further thoughts. >>>>>>> >>>>>>> Thanks, >>>>>>> ~ Prad >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> katello-devel mailing list >>>>>>> katello-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>> Instead of pulp-client-utils how about calling it Mache. >>>>>> As in Paper Mache which is made from wood pulp. >>>>>> And you can build things with paper mache. >>>>>> >>>>>> http://en.wikipedia.org/wiki/Papier-m%C3%A2ch%C3%A9 >>>>>> >>>>>> Just my 2 pesos. >>>>>> >>>>>> jesus >>>>> Hehe cool name. Todd what do you think? I'll be filing for a project >>>>> hosting request today. If we can agree on the name, I'll go ahead >>>>> with filing the ticket. >>>>> >>>>> ~ Prad >>>>> >>>>> _______________________________________________ >>>>> katello-devel mailing list >>>>> katello-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> What am I missing? Why a separate project for this? .....as this is >>>> just part of the pulp client-side tooling. The reason we are pulling >>>> into a separate rpm is so that is can more easily be leveraged by >>>> additional clients (i.e. RHSM). >>>> >>>> -Todd >>>> >>>> -Todd >>> We can use it under same pulp project. Since this is a separate tool >>> shared between katello, pulp and RHSM and need to get into brew at some >>> point for RHEL, I was thinking it would be easier if its not tied up >>> with pulp itself. This is a package pulp, ketello/rhsm will require. So >>> might have a case where we want newer builds for this package >>> outside of >>> pulp itself ? >>> >>> ~ Prad >> You have a couple options: >> >> 1) keep it in the same tree as pulp following the pulp release cycle >> >> 2) put it as separate git repo on fedora but link to it from the >> pulp wiki and mailing list. That's what we did with Thumbslug and >> Headpin. They are their own repos but linked from the Candelpin >> wiki. >> >> This way you get to have a clean repo people can contribute to and >> maintain it on a separate release schedule if needed. >> >> jesus > > Option-2 makes sense to me. I dont think we should bind the release > cycle of a shared library package with pulp itself. Ah. I read the original email as separate "Project", which I am *not* in favor of. Using a separate repo (i.e. grinder), linked to the existing Pulp project makes sense. -Todd > > ~ Prad > >> - -- 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 | >> +---------------------------------------------+ >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk3eY0YACgkQvJZ57YntiYOe4wCgw14/kT1bAZJA3SES5nqv6Lrd >> QlMAoIQQ0Q3+3VZE0Qeq+CwDkLFBZrgw >> =AWbH >> -----END PGP SIGNATURE----- > From bkearney at redhat.com Thu May 26 16:14:03 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 26 May 2011 12:14:03 -0400 Subject: [katello-devel] [pulp-internal] Package Profile Capture Design Doc In-Reply-To: <4DDE6605.8080407@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> <4DDE5D04.4080509@redhat.com> <4DDE5E34.6020700@redhat.com> <4DDE623C.3000100@redhat.com> <4DDE6346.3060901@redhat.com> <4DDE64F7.2000803@redhat.com> <4DDE6605.8080407@redhat.com> Message-ID: <4DDE7C4B.7050008@redhat.com> Lemme throw out a couple of things: 1) The interaction is really between rhsm and pulp, katello is a bit of a side effect. 2) You mention these 2 featues: # Package profile Module (for rpms, jars etc) # Certificate Bundle (to read/write certificates from /etc/pki/consumer) but later talk about gofer. Let me suggest this. 1) Since this is rhsm/pulp interaction.. can we merge this into python-rhsm? That package is already in fedora and RHEL, so it will ease the transition. 2) If we augment the low level API, candlepin may need to handle a "No-op" method of receiving the package set of discarding it. If we make it an extension point, then IT or SAM could leverage this later. 3) I think the package should be limited to yum plugins and a daemon not tied to gofer. This will make it easy to get into RHEL. The gofer stuff can be more command and control, and can use the same library code. Thoughts? -- bk On 05/26/2011 10:39 AM, Todd B Sanders wrote: > On 05/26/2011 10:34 AM, Pradeep Kilambi wrote: >> On 05/26/2011 10:27 AM, jesus m. rodriguez wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 05/26/2011 10:22 AM, Pradeep Kilambi wrote: >>>> On 05/26/2011 10:05 AM, Todd B Sanders wrote: >>>>> On 05/26/2011 10:00 AM, Pradeep Kilambi wrote: >>>>>> On 05/26/2011 09:55 AM, jesus m. rodriguez wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> On 05/25/2011 01:40 PM, Pradeep Kilambi wrote: >>>>>>>> Here is the design/spec document for package profile capture story. >>>>>>>> This >>>>>>>> will impact both Pulp and Katello. >>>>>>>> >>>>>>>> https://fedorahosted.org/pulp/wiki/PackageProfileUpdate >>>>>>>> >>>>>>>> Please lemme know if you guys have further thoughts. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> ~ Prad >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> katello-devel mailing list >>>>>>>> katello-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>>> Instead of pulp-client-utils how about calling it Mache. >>>>>>> As in Paper Mache which is made from wood pulp. >>>>>>> And you can build things with paper mache. >>>>>>> >>>>>>> http://en.wikipedia.org/wiki/Papier-m%C3%A2ch%C3%A9 >>>>>>> >>>>>>> Just my 2 pesos. >>>>>>> >>>>>>> jesus >>>>>> Hehe cool name. Todd what do you think? I'll be filing for a project >>>>>> hosting request today. If we can agree on the name, I'll go ahead >>>>>> with filing the ticket. >>>>>> >>>>>> ~ Prad >>>>>> >>>>>> _______________________________________________ >>>>>> katello-devel mailing list >>>>>> katello-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>> What am I missing? Why a separate project for this? .....as this is >>>>> just part of the pulp client-side tooling. The reason we are pulling >>>>> into a separate rpm is so that is can more easily be leveraged by >>>>> additional clients (i.e. RHSM). >>>>> >>>>> -Todd >>>>> >>>>> -Todd >>>> We can use it under same pulp project. Since this is a separate tool >>>> shared between katello, pulp and RHSM and need to get into brew at some >>>> point for RHEL, I was thinking it would be easier if its not tied up >>>> with pulp itself. This is a package pulp, ketello/rhsm will require. So >>>> might have a case where we want newer builds for this package >>>> outside of >>>> pulp itself ? >>>> >>>> ~ Prad >>> You have a couple options: >>> >>> 1) keep it in the same tree as pulp following the pulp release cycle >>> >>> 2) put it as separate git repo on fedora but link to it from the >>> pulp wiki and mailing list. That's what we did with Thumbslug and >>> Headpin. They are their own repos but linked from the Candelpin wiki. >>> >>> This way you get to have a clean repo people can contribute to and >>> maintain it on a separate release schedule if needed. >>> >>> jesus >> >> Option-2 makes sense to me. I dont think we should bind the release >> cycle of a shared library package with pulp itself. > > Ah. I read the original email as separate "Project", which I am *not* in > favor of. Using a separate repo (i.e. grinder), linked to the existing > Pulp project makes sense. > > -Todd >> >> ~ Prad >> >>> - -- 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 | >>> +---------------------------------------------+ >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (GNU/Linux) >>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAk3eY0YACgkQvJZ57YntiYOe4wCgw14/kT1bAZJA3SES5nqv6Lrd >>> QlMAoIQQ0Q3+3VZE0Qeq+CwDkLFBZrgw >>> =AWbH >>> -----END PGP SIGNATURE----- >> > From tsanders at redhat.com Thu May 26 16:27:48 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Thu, 26 May 2011 12:27:48 -0400 Subject: [katello-devel] [pulp-internal] Package Profile Capture Design Doc In-Reply-To: <4DDE7C4B.7050008@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> <4DDE5D04.4080509@redhat.com> <4DDE5E34.6020700@redhat.com> <4DDE623C.3000100@redhat.com> <4DDE6346.3060901@redhat.com> <4DDE64F7.2000803@redhat.com> <4DDE6605.8080407@redhat.com> <4DDE7C4B.7050008@redhat.com> Message-ID: <4DDE7F84.6060407@redhat.com> On 05/26/2011 12:14 PM, Bryan Kearney wrote: > Lemme throw out a couple of things: > > 1) The interaction is really between rhsm and pulp, katello is a bit > of a side effect. > > 2) You mention these 2 featues: > > # Package profile Module (for rpms, jars etc) > # Certificate Bundle (to read/write certificates from /etc/pki/consumer) > > but later talk about gofer. > > Let me suggest this. > > 1) Since this is rhsm/pulp interaction.. can we merge this into > python-rhsm? That package is already in fedora and RHEL, so it will > ease the transition. Are you suggesting we maintain this code in two places? As we need this functionality for pulp-client/pulp as well. > > 2) If we augment the low level API, candlepin may need to handle a > "No-op" method of receiving the package set of discarding it. If we > make it an extension point, then IT or SAM could leverage this later. ok. > > 3) I think the package should be limited to yum plugins and a daemon > not tied to gofer. This will make it easy to get into RHEL. The gofer > stuff can be more command and control, and can use the same library code. Fair. Jeff/Prad - Thoughts? -Todd > > Thoughts? > > -- bk > > > > > > On 05/26/2011 10:39 AM, Todd B Sanders wrote: >> On 05/26/2011 10:34 AM, Pradeep Kilambi wrote: >>> On 05/26/2011 10:27 AM, jesus m. rodriguez wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 05/26/2011 10:22 AM, Pradeep Kilambi wrote: >>>>> On 05/26/2011 10:05 AM, Todd B Sanders wrote: >>>>>> On 05/26/2011 10:00 AM, Pradeep Kilambi wrote: >>>>>>> On 05/26/2011 09:55 AM, jesus m. rodriguez wrote: >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>>> Hash: SHA1 >>>>>>>> >>>>>>>> On 05/25/2011 01:40 PM, Pradeep Kilambi wrote: >>>>>>>>> Here is the design/spec document for package profile capture >>>>>>>>> story. >>>>>>>>> This >>>>>>>>> will impact both Pulp and Katello. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/pulp/wiki/PackageProfileUpdate >>>>>>>>> >>>>>>>>> Please lemme know if you guys have further thoughts. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> ~ Prad >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> katello-devel mailing list >>>>>>>>> katello-devel at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>>>> Instead of pulp-client-utils how about calling it Mache. >>>>>>>> As in Paper Mache which is made from wood pulp. >>>>>>>> And you can build things with paper mache. >>>>>>>> >>>>>>>> http://en.wikipedia.org/wiki/Papier-m%C3%A2ch%C3%A9 >>>>>>>> >>>>>>>> Just my 2 pesos. >>>>>>>> >>>>>>>> jesus >>>>>>> Hehe cool name. Todd what do you think? I'll be filing for a >>>>>>> project >>>>>>> hosting request today. If we can agree on the name, I'll go ahead >>>>>>> with filing the ticket. >>>>>>> >>>>>>> ~ Prad >>>>>>> >>>>>>> _______________________________________________ >>>>>>> katello-devel mailing list >>>>>>> katello-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>>> What am I missing? Why a separate project for this? .....as this is >>>>>> just part of the pulp client-side tooling. The reason we are pulling >>>>>> into a separate rpm is so that is can more easily be leveraged by >>>>>> additional clients (i.e. RHSM). >>>>>> >>>>>> -Todd >>>>>> >>>>>> -Todd >>>>> We can use it under same pulp project. Since this is a separate tool >>>>> shared between katello, pulp and RHSM and need to get into brew at >>>>> some >>>>> point for RHEL, I was thinking it would be easier if its not tied up >>>>> with pulp itself. This is a package pulp, ketello/rhsm will >>>>> require. So >>>>> might have a case where we want newer builds for this package >>>>> outside of >>>>> pulp itself ? >>>>> >>>>> ~ Prad >>>> You have a couple options: >>>> >>>> 1) keep it in the same tree as pulp following the pulp release cycle >>>> >>>> 2) put it as separate git repo on fedora but link to it from the >>>> pulp wiki and mailing list. That's what we did with Thumbslug and >>>> Headpin. They are their own repos but linked from the Candelpin wiki. >>>> >>>> This way you get to have a clean repo people can contribute to and >>>> maintain it on a separate release schedule if needed. >>>> >>>> jesus >>> >>> Option-2 makes sense to me. I dont think we should bind the release >>> cycle of a shared library package with pulp itself. >> >> Ah. I read the original email as separate "Project", which I am *not* in >> favor of. Using a separate repo (i.e. grinder), linked to the existing >> Pulp project makes sense. >> >> -Todd >>> >>> ~ Prad >>> >>>> - -- 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 | >>>> +---------------------------------------------+ >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.11 (GNU/Linux) >>>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >>>> >>>> iEYEARECAAYFAk3eY0YACgkQvJZ57YntiYOe4wCgw14/kT1bAZJA3SES5nqv6Lrd >>>> QlMAoIQQ0Q3+3VZE0Qeq+CwDkLFBZrgw >>>> =AWbH >>>> -----END PGP SIGNATURE----- >>> >> > From bkearney at redhat.com Thu May 26 16:35:43 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 26 May 2011 12:35:43 -0400 Subject: [katello-devel] [pulp-internal] Package Profile Capture Design Doc In-Reply-To: <4DDE7F84.6060407@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> <4DDE5D04.4080509@redhat.com> <4DDE5E34.6020700@redhat.com> <4DDE623C.3000100@redhat.com> <4DDE6346.3060901@redhat.com> <4DDE64F7.2000803@redhat.com> <4DDE6605.8080407@redhat.com> <4DDE7C4B.7050008@redhat.com> <4DDE7F84.6060407@redhat.com> Message-ID: <4DDE815F.8050902@redhat.com> On 05/26/2011 12:27 PM, Todd B Sanders wrote: > On 05/26/2011 12:14 PM, Bryan Kearney wrote: >> Lemme throw out a couple of things: >> >> 1) The interaction is really between rhsm and pulp, katello is a bit >> of a side effect. >> >> 2) You mention these 2 featues: >> >> # Package profile Module (for rpms, jars etc) >> # Certificate Bundle (to read/write certificates from /etc/pki/consumer) >> >> but later talk about gofer. >> >> Let me suggest this. >> >> 1) Since this is rhsm/pulp interaction.. can we merge this into >> python-rhsm? That package is already in fedora and RHEL, so it will >> ease the transition. > > Are you suggesting we maintain this code in two places? As we need this > functionality for pulp-client/pulp as well. I am saying make pulp dependent on python-rhsm. -- bk From bkearney at redhat.com Thu May 26 16:37:34 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 26 May 2011 12:37:34 -0400 Subject: [katello-devel] [pulp-internal] Package Profile Capture Design Doc In-Reply-To: <4DDE815F.8050902@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> <4DDE5D04.4080509@redhat.com> <4DDE5E34.6020700@redhat.com> <4DDE623C.3000100@redhat.com> <4DDE6346.3060901@redhat.com> <4DDE64F7.2000803@redhat.com> <4DDE6605.8080407@redhat.com> <4DDE7C4B.7050008@redhat.com> <4DDE7F84.6060407@redhat.com> <4DDE815F.8050902@redhat.com> Message-ID: <4DDE81CE.4010207@redhat.com> On 05/26/2011 12:35 PM, Bryan Kearney wrote: > On 05/26/2011 12:27 PM, Todd B Sanders wrote: >> On 05/26/2011 12:14 PM, Bryan Kearney wrote: >>> Lemme throw out a couple of things: >>> >>> 1) The interaction is really between rhsm and pulp, katello is a bit >>> of a side effect. >>> >>> 2) You mention these 2 featues: >>> >>> # Package profile Module (for rpms, jars etc) >>> # Certificate Bundle (to read/write certificates from /etc/pki/consumer) >>> >>> but later talk about gofer. >>> >>> Let me suggest this. >>> >>> 1) Since this is rhsm/pulp interaction.. can we merge this into >>> python-rhsm? That package is already in fedora and RHEL, so it will >>> ease the transition. >> >> Are you suggesting we maintain this code in two places? As we need this >> functionality for pulp-client/pulp as well. > > I am saying make pulp dependent on python-rhsm. > Which.. if you look.. https://fedorahosted.org/python-rhsm/browser is already a small package which has only the cert reading code, and the consumer apis. -- bk From tsanders at redhat.com Thu May 26 16:33:57 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Thu, 26 May 2011 12:33:57 -0400 Subject: [katello-devel] [pulp-internal] Package Profile Capture Design Doc In-Reply-To: <4DDE81CE.4010207@redhat.com> References: <4DDD3F0A.9070503@redhat.com> <4DDE5BB7.90201@redhat.com> <4DDE5D04.4080509@redhat.com> <4DDE5E34.6020700@redhat.com> <4DDE623C.3000100@redhat.com> <4DDE6346.3060901@redhat.com> <4DDE64F7.2000803@redhat.com> <4DDE6605.8080407@redhat.com> <4DDE7C4B.7050008@redhat.com> <4DDE7F84.6060407@redhat.com> <4DDE815F.8050902@redhat.com> <4DDE81CE.4010207@redhat.com> Message-ID: <4DDE80F5.8010403@redhat.com> On 05/26/2011 12:37 PM, Bryan Kearney wrote: > On 05/26/2011 12:35 PM, Bryan Kearney wrote: >> On 05/26/2011 12:27 PM, Todd B Sanders wrote: >>> On 05/26/2011 12:14 PM, Bryan Kearney wrote: >>>> Lemme throw out a couple of things: >>>> >>>> 1) The interaction is really between rhsm and pulp, katello is a bit >>>> of a side effect. >>>> >>>> 2) You mention these 2 featues: >>>> >>>> # Package profile Module (for rpms, jars etc) >>>> # Certificate Bundle (to read/write certificates from >>>> /etc/pki/consumer) >>>> >>>> but later talk about gofer. >>>> >>>> Let me suggest this. >>>> >>>> 1) Since this is rhsm/pulp interaction.. can we merge this into >>>> python-rhsm? That package is already in fedora and RHEL, so it will >>>> ease the transition. >>> >>> Are you suggesting we maintain this code in two places? As we need this >>> functionality for pulp-client/pulp as well. >> >> I am saying make pulp dependent on python-rhsm. >> > > Which.. if you look.. > > https://fedorahosted.org/python-rhsm/browser > > is already a small package which has only the cert reading code, and > the consumer apis. > > -- bk ah, ok. Makes sense. Prad/Jeff? -Todd From lzap at redhat.com Fri May 27 12:44:28 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 27 May 2011 14:44:28 +0200 Subject: [katello-devel] Lazy attribute redefinition Message-ID: <4DDF9CAC.30905@redhat.com> Hey Dmitri, I have redefined one argument error you are throwing: http://pastie.org/private/wp8lusn1zbusflypvajeg to only warning message. Is that a problem for you? The problem is I have a code that do this: # explicitly load all available model classes Dir.foreach("#{Rails.root}/app/models") { |f| require f if f =~ /.*\.[rR][bB]/ } For the AR RBAC I need to translate table names to model class names and I need to load all model classes. In production mode I do this only once. It was throwing me exception Remote attribute "productContent" already defined so I turned this into a warning message. I believe the Ruby "require" statement loads the class only once. I dont know why it is trying to load product.rb when the file has been already loaded. Maybe this is Rails 3 behavior for the development mode. If this turns out to be a problem we can always create such a hash "by hand". LZ -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From tsanders at redhat.com Fri May 27 14:57:40 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Fri, 27 May 2011 10:57:40 -0400 Subject: [katello-devel] Fwd: [kalpana-devel] Main Role Use Cases Message-ID: <4DDFBBE4.7080208@redhat.com> Moving over to katello-devel. -------- Original Message -------- Subject: [kalpana-devel] Main Role Use Cases Date: Fri, 27 May 2011 10:24:07 -0400 From: Bryan Kearney Reply-To: Kalpana Development Discussions To: Kalpana Development Discussions Per a conversation on IRC, here is a first cut of what I think are the main use cases we want to support with Roles. Lets discuss here, and when finalized I will move to the wiki. 1) Users should be granted access to an one Tenant (top level org) but not another. Some users will be read only on the org, others would be able to do stuff. 2) Around Packages, we want to enable/disable: A) Creating Providers, Syncing Content. B) Seeing products C) Promoting should be controlled by the environment. 3) Around Environment, we want to protect: A) Access to the environment. B) Promoting into the environment. 4) Around Templates: A) Creating / Editing Them. B) Promoting should be controlled by the environment. 5) Around Systems, we want to protect: A) CRUD basd on the environment they are in. B) Remote Command and Control Other UI Specific toggles. All within an org - Seeing / Executing Reports - Each Major tab / Minor Tab should be tied to one "business" permission (Systms tab may equal System.View for the current org) Other toggles outside of an org - User CRUD - Permission CRUD - Org Create -- bk -------------- next part -------------- An HTML attachment was scrubbed... URL: From lzap at redhat.com Fri May 27 15:00:33 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 27 May 2011 17:00:33 +0200 Subject: [katello-devel] Merging ActiveRecord RBAC into the master Message-ID: <4DDFBC91.6020003@redhat.com> Hello, I am going to merge my AR RBAC work into the master. You will need to do # rake setup again. Or you can run this in the rails console if you want: ActiveRecord::Base.connection.tables.each do |t| Role.allow 'admin_role', [:create, :edit, :destroy], t end The approach is "everybody can do everything". I did my best to test everything, unit tests are green, CLI works, UI works. Well product creation and system registration do not work (but in master too). This change affects lots of things and can cause issues. If you will run into permission-related issue you can turn AR RBAC by returning "false" in the Authorization#enforce? method. But it should be fine. I will be adding permission rules now. Since its Friday I am keeping online - please test ASAP :-) ps - I have created scripts/tests/katello-cli-simple-test.sh that runs some very basic commands (adds provider, product, sync product, register system). Feel free to add your own commands here but keep it idempotent. We should be able to run it multiple times without clearing the database. Which means - clean what you did or create things with "random" names. I use the script prior pushing to the master. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From tsanders at redhat.com Fri May 27 15:05:43 2011 From: tsanders at redhat.com (Todd B Sanders) Date: Fri, 27 May 2011 11:05:43 -0400 Subject: [katello-devel] Fwd: [kalpana-devel] Main Role Use Cases In-Reply-To: <4DDFBBE4.7080208@redhat.com> References: <4DDFBBE4.7080208@redhat.com> Message-ID: <4DDFBDC7.8090707@redhat.com> On 05/27/2011 10:57 AM, Todd B Sanders wrote: > Moving over to katello-devel. > > -------- Original Message -------- > Subject: [kalpana-devel] Main Role Use Cases > Date: Fri, 27 May 2011 10:24:07 -0400 > From: Bryan Kearney > Reply-To: Kalpana Development Discussions > To: Kalpana Development Discussions > > > > Per a conversation on IRC, here is a first cut of what I think are the > main use cases we want to support with Roles. Lets discuss here, and > when finalized I will move to the wiki. > > 1) Users should be granted access to an one Tenant (top level org) but > not another. Some users will be read only on the org, others would be > able to do stuff. Help me understand again about the super-admins that have access across all tenants? How is this defined? > 2) Around Packages, we want to enable/disable: > A) Creating Providers, Syncing Content. and uploading custom content. > B) Seeing products > C) Promoting should be controlled by the environment. > 3) Around Environment, we want to protect: What about CRUD on Environments within an Org, or changing the promotion flow? > A) Access to the environment. > B) Promoting into the environment. > 4) Around Templates: > A) Creating / Editing Them. > B) Promoting should be controlled by the environment. > 5) Around Systems, we want to protect: > A) CRUD basd on the environment they are in. > B) Remote Command and Control System Groups? -Todd > Other UI Specific toggles. All within an org > - Seeing / Executing Reports > - Each Major tab / Minor Tab should be tied to one "business" permission > (Systms tab may equal System.View for the current org) > > Other toggles outside of an org > - User CRUD > - Permission CRUD > - Org Create > > > -- 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 paji at redhat.com Fri May 27 15:50:04 2011 From: paji at redhat.com (Partha Aji) Date: Fri, 27 May 2011 11:50:04 -0400 (EDT) Subject: [katello-devel] Minor tweak on Organization.create! In-Reply-To: <4DDDA2D4.6040207@redhat.com> Message-ID: <1989003714.330928.1306511404070.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Based on discussions on #katello yesterday.. We decided on the following changes 1) Newly created Org no longer has any non-locker environments created. The user has perform another action to create one. 2) The user will not be able to register systems to an org unless they have an environment. 3) On the UI side there will be notification stating this and recommending user to do a Add Environment. Partha ----- Original Message ----- > From: "Bryan Kearney" > To: "Partha Aji" > Cc: katello-devel at redhat.com > Sent: Wednesday, May 25, 2011 8:46:12 PM > Subject: Re: [katello-devel] Minor tweak on Organization.create! > On 05/25/2011 07:34 PM, Partha Aji wrote: > > > > Based of this bug > > https://bugzilla.redhat.com/show_bug.cgi?id=692643, I made > > Organization.create! require an :initial_environment_name field. I > > have updated the seed scripts and the unit tests, but if you had > > scripts creating orgs you might need to update them to include > > :initial_environment_name > > > > > > Partha > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > Should the API force this? I am fine with the UI doing 2 calls.. but > it > seems odd to force this via the API. > > -- bk From bkearney at redhat.com Fri May 27 17:34:35 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 27 May 2011 13:34:35 -0400 Subject: [katello-devel] Minor tweak on Organization.create! In-Reply-To: <1989003714.330928.1306511404070.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1989003714.330928.1306511404070.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4DDFE0AB.1050107@redhat.com> On 05/27/2011 11:50 AM, Partha Aji wrote: > > Based on discussions on #katello yesterday.. We decided on the following changes > > 1) Newly created Org no longer has any non-locker environments created. The user has perform another action to create one. > 2) The user will not be able to register systems to an org unless they have an environment. > 3) On the UI side there will be notification stating this and recommending user to do a Add Environment. > > thank you. -- bk From taw at redhat.com Fri May 27 18:54:45 2011 From: taw at redhat.com (Todd Warner) Date: Fri, 27 May 2011 14:54:45 -0400 Subject: [katello-devel] Fwd: [kalpana-devel] Main Role Use Cases In-Reply-To: <4DDFBDC7.8090707@redhat.com> References: <4DDFBBE4.7080208@redhat.com> <4DDFBDC7.8090707@redhat.com> Message-ID: <4DDFF375.5080703@redhat.com> On 05/27/2011 11:05 AM, Todd B Sanders wrote: > On 05/27/2011 10:57 AM, Todd B Sanders wrote: >> Moving over to katello-devel. >> >> -------- Original Message -------- >> Subject: [kalpana-devel] Main Role Use Cases >> Date: Fri, 27 May 2011 10:24:07 -0400 >> From: Bryan Kearney >> Reply-To: Kalpana Development Discussions >> To: Kalpana Development Discussions >> >> >> >> Per a conversation on IRC, here is a first cut of what I think are the >> main use cases we want to support with Roles. Lets discuss here, and >> when finalized I will move to the wiki. >> >> 1) Users should be granted access to an one Tenant (top level org) but >> not another. Some users will be read only on the org, others would be >> able to do stuff. > > Help me understand again about the super-admins that have access > across all tenants? How is this defined? Super-admins purpose is just structural, right? I.e., they can create other tenants and admins for those tenants? -todd -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmccune at redhat.com Fri May 27 19:02:46 2011 From: mmccune at redhat.com (Mike McCune) Date: Fri, 27 May 2011 12:02:46 -0700 Subject: [katello-devel] Merging ActiveRecord RBAC into the master In-Reply-To: <4DDFBC91.6020003@redhat.com> References: <4DDFBC91.6020003@redhat.com> Message-ID: <4DDFF556.6040002@redhat.com> On 05/27/2011 08:00 AM, Lukas Zapletal wrote: > Hello, > > I am going to merge my AR RBAC work into the master. You will need to do > > # rake setup > > again. Or you can run this in the rails console if you want: > > ActiveRecord::Base.connection.tables.each do |t| > Role.allow 'admin_role', [:create, :edit, :destroy], t > end > > The approach is "everybody can do everything". I did my best to test > everything, unit tests are green, CLI works, UI works. Well product > creation and system registration do not work (but in master too). > > This change affects lots of things and can cause issues. If you will run > into permission-related issue you can turn AR RBAC by returning "false" > in the Authorization#enforce? method. But it should be fine. > I pushed the below fix because I was running into a timing or order-of-execution issue where we are trying to issue a: notice _("Login Successful") from the user_sessions_controller.rb when we are logging in but User.current isn't set yet so it blows up on a nil class with: NoMethodError (undefined method `username' for nil:NilClass): app/models/authorization.rb:67:in `access_denied' app/models/authorization.rb:61:in `enforce_db_permissions' app/models/authorization.rb:51:in `enforce_permissions' app/models/authorization.rb:37:in `enforce_create_permissions' app/controllers/application_controller.rb:85:in `notice' app/controllers/user_sessions_controller.rb:41:in `create' lib/util/threadsession.rb:79:in `thread_locals' I spent a bit of time trying to find a proper fix but people were blocked and not able to login. commit 7a8adc27f9e9662195c13855b5d1cfc334fa2418 Author: Mike McCune Date: Fri May 27 11:54:16 2011 -0700 temporary fix so people can login to the webui again diff --git a/src/app/models/authorization.rb b/src/app/models/authorization.rb index be9af63..89e4028 100644 --- a/src/app/models/authorization.rb +++ b/src/app/models/authorization.rb @@ -64,7 +64,13 @@ module Authorization def access_denied(operation) strid = self.id ? "(id = #{self.id})" : '' - msg = "User #{User.current.username} doesn't have permission to #{operation} this #{self.class.table_name} #{strid}" + msg = nil + if User.current.nil? + msg = "UNKNOWN USER doesn't have permission to #{operation} this #{self.class.table_name} #{strid}" + else + msg = "User #{User.current.username} doesn't have permission to #{operation} this #{self.class.table_name} #{strid}" + end + Rails.logger.warn msg raise Errors::SecurityViolation, msg end Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From bkearney at redhat.com Fri May 27 19:34:04 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 27 May 2011 15:34:04 -0400 Subject: [katello-devel] Product Name Patch Message-ID: <4DDFFCAC.3070608@redhat.com> Jrist: Would you be willing to do this to put the product name in the title? This would allow SAM to pull over the layout file with no edits. -- bk -------------- next part -------------- A non-text attachment was scrubbed... Name: product_name.patch Type: text/x-patch Size: 932 bytes Desc: not available URL: From jrist at redhat.com Fri May 27 19:32:09 2011 From: jrist at redhat.com (Jason Rist) Date: Fri, 27 May 2011 13:32:09 -0600 Subject: [katello-devel] Product Name Patch In-Reply-To: <4DDFFCAC.3070608@redhat.com> References: <4DDFFCAC.3070608@redhat.com> Message-ID: <4DDFFC39.5080603@redhat.com> On 05/27/2011 01:34 PM, Bryan Kearney wrote: > Jrist: > > Would you be willing to do this to put the product name in the title? > This would allow SAM to pull over the layout file with no edits. > > -- bk > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Absolutely - side question - is SAM still Content and Systems Management? Why not put both of those in the project name? Also, why is "Katello", our product name set to go into a PO? :) -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 May 27 19:42:14 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 27 May 2011 15:42:14 -0400 Subject: [katello-devel] Product Name Patch In-Reply-To: <4DDFFC39.5080603@redhat.com> References: <4DDFFCAC.3070608@redhat.com> <4DDFFC39.5080603@redhat.com> Message-ID: <4DDFFE96.8090608@redhat.com> On 05/27/2011 03:32 PM, Jason Rist wrote: > On 05/27/2011 01:34 PM, Bryan Kearney wrote: >> Jrist: >> >> Would you be willing to do this to put the product name in the title? >> This would allow SAM to pull over the layout file with no edits. >> >> -- bk >> >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Absolutely - side question - is SAM still Content and Systems > Management? No.. would be better to do both. Good catch. Why not put both of those in the project name? Also, why > is "Katello", our product name set to go into a PO? Because I want to see what Katello is in Gujarti. I think it will be: ?????????? ??? ?????? -- bk From mmccune at redhat.com Fri May 27 20:21:50 2011 From: mmccune at redhat.com (Mike McCune) Date: Fri, 27 May 2011 13:21:50 -0700 Subject: [katello-devel] Merging ActiveRecord RBAC into the master In-Reply-To: <4DDFF556.6040002@redhat.com> References: <4DDFBC91.6020003@redhat.com> <4DDFF556.6040002@redhat.com> Message-ID: <4DE007DE.1000803@redhat.com> On 05/27/2011 12:02 PM, Mike McCune wrote: > On 05/27/2011 08:00 AM, Lukas Zapletal wrote: >> Hello, >> >> I am going to merge my AR RBAC work into the master. You will need to do >> >> # rake setup >> >> again. Or you can run this in the rails console if you want: >> >> ActiveRecord::Base.connection.tables.each do |t| >> Role.allow 'admin_role', [:create, :edit, :destroy], t >> end >> >> The approach is "everybody can do everything". I did my best to test >> everything, unit tests are green, CLI works, UI works. Well product >> creation and system registration do not work (but in master too). >> >> This change affects lots of things and can cause issues. If you will run >> into permission-related issue you can turn AR RBAC by returning "false" >> in the Authorization#enforce? method. But it should be fine. >> > > I pushed the below fix because I was running into a timing or > order-of-execution issue where we are trying to issue a: > > notice _("Login Successful") > > from the user_sessions_controller.rb when we are logging in but > User.current isn't set yet so it blows up on a nil class with: > > NoMethodError (undefined method `username' for nil:NilClass): > app/models/authorization.rb:67:in `access_denied' > app/models/authorization.rb:61:in `enforce_db_permissions' > app/models/authorization.rb:51:in `enforce_permissions' > app/models/authorization.rb:37:in `enforce_create_permissions' > app/controllers/application_controller.rb:85:in `notice' > app/controllers/user_sessions_controller.rb:41:in `create' > lib/util/threadsession.rb:79:in `thread_locals' > > I spent a bit of time trying to find a proper fix but people were > blocked and not able to login. > > commit 7a8adc27f9e9662195c13855b5d1cfc334fa2418 > Author: Mike McCune > Date: Fri May 27 11:54:16 2011 -0700 > > temporary fix so people can login to the webui again > > diff --git a/src/app/models/authorization.rb > b/src/app/models/authorization.rb > index be9af63..89e4028 100644 > --- a/src/app/models/authorization.rb > +++ b/src/app/models/authorization.rb > @@ -64,7 +64,13 @@ module Authorization > > def access_denied(operation) > strid = self.id ? "(id = #{self.id})" : '' > - msg = "User #{User.current.username} doesn't have permission to > #{operation} this #{self.class.table_name} #{strid}" > + msg = nil > + if User.current.nil? > + msg = "UNKNOWN USER doesn't have permission to #{operation} this > #{self.class.table_name} #{strid}" > + else > + msg = "User #{User.current.username} doesn't have permission to > #{operation} this #{self.class.table_name} #{strid}" > + end > + > Rails.logger.warn msg > raise Errors::SecurityViolation, msg > end > > Mike Also seeing this error: https://bugzilla.redhat.com/show_bug.cgi?id=708494#c1 Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From abenari at redhat.com Sun May 29 09:25:14 2011 From: abenari at redhat.com (Amos Benari) Date: Sun, 29 May 2011 05:25:14 -0400 (EDT) Subject: [katello-devel] Merging access_permission into the master, please run "rake setup". In-Reply-To: <4DE007DE.1000803@redhat.com> Message-ID: <1852526906.347678.1306661114488.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Please run rake setup after update. The commit changes verbs table content and roles needs to be re-seeded. 1. Basic controller permissions are now translated as follows: new, create => create. index, show, auto_complete_search => read. edit, update => update. destroy => delete. 2. Controller specific actions can also be mapped to CRUD verbs, for example :notices => {:destroy_all => 'delete'} See: https://engineering.redhat.com/trac/kalpana/wiki/Authorization for details. Amos. From lzap at redhat.com Mon May 30 09:46:27 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 30 May 2011 11:46:27 +0200 Subject: [katello-devel] Merging ActiveRecord RBAC into the master In-Reply-To: <4DDFF556.6040002@redhat.com> References: <4DDFBC91.6020003@redhat.com> <4DDFF556.6040002@redhat.com> Message-ID: <4DE36773.20902@redhat.com> On 05/27/2011 09:02 PM, Mike McCune wrote: > I pushed the below fix because I was running into a timing or > order-of-execution Sorry for that, investigating and fixing. The workaround is to return "false" in the authorization.rb file method enforce?. That will stop checking AR permissions. LZ -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From tstrachota at redhat.com Mon May 30 12:11:00 2011 From: tstrachota at redhat.com (Tomas Strachota) Date: Mon, 30 May 2011 14:11:00 +0200 Subject: [katello-devel] integer ids in api merged Message-ID: <4DE38954.6070809@redhat.com> Hi all, I've merged the changed api resource identification. All katello resources apart from organizations are now identified by its integer ids. CLI remains mostly the same and still uses string names. Tomas From lzap at redhat.com Mon May 30 17:32:09 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 30 May 2011 19:32:09 +0200 Subject: [katello-devel] Notice ownership Message-ID: <4DE3D499.2080802@redhat.com> Hello, question to folks involved in notifications. Is there any record of author if the notice? I am implementing permission checks for notices and I assume we use them as self-notices only right now. That means users sends notices themselves only. But we are going to use this for messages among users, are we? We should track author of the notice (message) then. Can I add such a column for that? Thanks -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From lzap at redhat.com Tue May 31 08:29:08 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 31 May 2011 10:29:08 +0200 Subject: [katello-devel] One more change in the AR RBAC Message-ID: <4DE4A6D4.50803@redhat.com> Hello all, I did one more change that needs the world-famous # rake setup Please do it. I have prefixed all the AR resource types with "ar_" for better debugging purposes. Once we define all permissions and roles I will remove this. For me this is great improvement because it was tricky to track RBAC-related errors until now. As you can see in the roles UI screen one can define permissions per model objects now. E.g. if you click on Add permission and select ar_providers permission type you will see providers being loaded from the database now. I have created new "anonymous" user that has permission to do "nothing". Its a typical "nobody" user/role. Until now when user was not logged in we was using a "nil" value for that. If the permission stack now see "nil" value it tries to consult the database against "anonymous" user before it denies access. We can now assign some permissions to anonymous users if we want to. More info on the demo. Don't hesitate to ask. -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From dmitri at redhat.com Tue May 31 10:02:05 2011 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 31 May 2011 07:02:05 -0300 Subject: [katello-devel] changes in orchestration Message-ID: <4DE4BC9D.1080509@redhat.com> Hey all, I introduced a minor change in how orchestration operates in 5b257f499567080cf4a2adcbc7f24e207eb84895. You can now find out for what type of operation the orchestration is being performed for by calling orchestration_for method. It will contain :create, :update, :destroy, or a custom operation (:promote on Product, for example). Example below shows how orchestration_for is used in Glue::Candlepin::Product case orchestration_for when :create queue.create(:name => "candlepin product: #{self.name}", :priority => 3, :action => [self, :set_product]) queue.create(:name => "candlepin content: #{self.name}", :priority => 4, :action => [self, :set_content]) queue.create(:name => "add content to product in candlepin: #{self.name}", :priority => 5, :action => [self, :add_content]) # we create unlimited subscriptions for generic yum providers if self.provider and self.provider.yum_repo? queue.create(:name => "create unlimited subscription for product in candlepin: #{self.name}", :priority => 7, :action => [self, :create_unlimited_subscription]) end when :update, :promote queue.create(:name => "update candlepin product: #{self.name}", :priority => 3, :action => [self, :update_content]) end The standard :create, :update, :destroy are being set for you, but if you need to run orchestration for a different operation, you can set it via @orchestration_for instance variable, for example in Glue::Pulp::Repos.promote: def promote from_env, to_env @orchestration_for = :promote ... Please let me know if you any questions. Cheers, -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkearney at redhat.com Tue May 31 13:44:39 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 31 May 2011 09:44:39 -0400 Subject: [katello-devel] Fwd: [kalpana-devel] Main Role Use Cases In-Reply-To: <4DDFBDC7.8090707@redhat.com> References: <4DDFBBE4.7080208@redhat.com> <4DDFBDC7.8090707@redhat.com> Message-ID: <4DE4F0C7.4070707@redhat.com> On 05/27/2011 11:05 AM, Todd B Sanders wrote: > On 05/27/2011 10:57 AM, Todd B Sanders wrote: >> Moving over to katello-devel. >> >> -------- Original Message -------- >> Subject: [kalpana-devel] Main Role Use Cases >> Date: Fri, 27 May 2011 10:24:07 -0400 >> From: Bryan Kearney >> Reply-To: Kalpana Development Discussions >> To: Kalpana Development Discussions >> >> >> >> Per a conversation on IRC, here is a first cut of what I think are the >> main use cases we want to support with Roles. Lets discuss here, and >> when finalized I will move to the wiki. >> >> 1) Users should be granted access to an one Tenant (top level org) but >> not another. Some users will be read only on the org, others would be >> able to do stuff. > > Help me understand again about the super-admins that have access across > all tenants? How is this defined? I would say a super admin has roles on all orgs. > >> 2) Around Packages, we want to enable/disable: >> A) Creating Providers, Syncing Content. > > and uploading custom content. added > >> B) Seeing products >> C) Promoting should be controlled by the environment. >> 3) Around Environment, we want to protect: > > What about CRUD on Environments within an Org, or changing the promotion > flow? added. > >> A) Access to the environment. >> B) Promoting into the environment. >> 4) Around Templates: >> A) Creating / Editing Them. >> B) Promoting should be controlled by the environment. >> 5) Around Systems, we want to protect: >> A) CRUD basd on the environment they are in. >> B) Remote Command and Control > > System Groups? > Added. -- bk From bkearney at redhat.com Tue May 31 13:57:58 2011 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 31 May 2011 09:57:58 -0400 Subject: [katello-devel] Table names check-up In-Reply-To: <4DDE154E.4080806@redhat.com> References: <4DDE154E.4080806@redhat.com> Message-ID: <4DE4F3E6.5080106@redhat.com> On 05/26/2011 04:54 AM, Lukas Zapletal wrote: > Hello, > > if I take a look at our table names it looks good: > > >> ActiveRecord::Base.connection.tables.each { |t| puts t } > > schema_migrations (*) > organizations > environments > environment_priors > products > kp_environments_products (**) > providers > changesets > changeset_histories > users > roles > verbs > resource_types > tags > permissions > permissions_verbs > permissions_tags > roles_users > changesets_products > help_tips > notices > user_notices > systems > changeset_packages > changeset_errata > > (*) this one is Rails' one > (**) we might like to remove the prefix for this one (like for > environments) > > If you see any issues let others know. > Any need to prefix these with a kt or similar? -- bk From lzap at redhat.com Tue May 31 14:37:17 2011 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 31 May 2011 16:37:17 +0200 Subject: [katello-devel] Table names check-up In-Reply-To: <4DE4F3E6.5080106@redhat.com> References: <4DDE154E.4080806@redhat.com> <4DE4F3E6.5080106@redhat.com> Message-ID: <4DE4FD1D.5000801@redhat.com> On 05/31/2011 03:57 PM, Bryan Kearney wrote: > Any need to prefix these with a kt or similar? Nope, actually we just need to remove kp_ prefix from environments. LZ -- Later, Lukas Zapletal | E32E400A RHN Satellite Engineering Red Hat Czech s.r.o. Brno From tstrachota at redhat.com Tue May 31 15:15:58 2011 From: tstrachota at redhat.com (Tomas Strachota) Date: Tue, 31 May 2011 17:15:58 +0200 Subject: [katello-devel] Katello CLI simple test Message-ID: <4DE5062E.30200@redhat.com> Hi all, our cli check script (scripts/test/katello-cli-simple-test.sh) turned out to be very useful today and helped to discover bugs for me and Lukas. Therefore I extended it a little bit more. It now prints what it tests, status OK/FAILED and error message returned from CLI (in case of fail). This enables testing list commands without actually printing the lists that only made the output chaotic. The old behaviour is still there when you use parameter -v. There are tests for most of our tricky commands. I recommend to run the script before pushing changes to master to everybody who changes api/cli. Tomas From bbuckingham at redhat.com Tue May 31 15:56:34 2011 From: bbuckingham at redhat.com (Brad Buckingham) Date: Tue, 31 May 2011 11:56:34 -0400 Subject: [katello-devel] Notice ownership In-Reply-To: <4DE3D499.2080802@redhat.com> References: <4DE3D499.2080802@redhat.com> Message-ID: <4DE50FB2.7060208@redhat.com> On 05/30/2011 01:32 PM, Lukas Zapletal wrote: > Hello, > > question to folks involved in notifications. > > Is there any record of author if the notice? I am implementing > permission checks for notices and I assume we use them as self-notices > only right now. That means users sends notices themselves only. > > But we are going to use this for messages among users, are we? We > should track author of the notice (message) then. Can I add such a > column for that? > > Thanks > Hi Lukas, Currently, there is no record of the author of a notice. We could certainly store the author; however, do we really need to? For reference, the original write-up for notifications can be found on the wiki under "SystemNotifications". The key use cases for sending notifications were: - send notifications to one user - send notifications to all users at once In either case, the notification system will allow any user to create a notice (internally w/in the app); however, it will only send the notice to the user it is targeted for. thanks, Brad From dmitri at redhat.com Tue May 31 19:32:04 2011 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 31 May 2011 16:32:04 -0300 Subject: [katello-devel] error handling in orchestration Message-ID: <4DE54234.4020306@redhat.com> Yet another change in orchestration engine insides. Now when an exception is thrown during orchestration, and after the rollback is performed, the original exception that started it all will be re-thrown (and thus will show up in controllers). If you are writing orchestration code, instead of using old and busted Glue.falure method, simply log the error, and then re-raise the exception! Cheers, -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbuckingham at redhat.com Tue May 31 21:15:04 2011 From: bbuckingham at redhat.com (Brad Buckingham) Date: Tue, 31 May 2011 17:15:04 -0400 Subject: [katello-devel] Resources: should they include 'organizations/:id'? Message-ID: <4DE55A58.7050409@redhat.com> Team, While working on search enhancements, I noticed that we are inconsistent in how we have resources defined, with respect to including organization as part of the resource. For example, - the following resources include organization: /organizations/:organization_id/environments /organizations/:organization_id/providers - however, the following do not: /changesets /dashboard /notices /roles /sync_plans /sync_schedules /sync_management /systems /users Note: the above is not all possible resources, just an example... :) While it may not be necessary to include organization in every resource, should we be consistent in including it for each resource that can be defined per organization? Do we need to include it? Note: The resolution to this thread should probably apply to both UI and API. (In general, given the primary keys that RAILs includes in the model definitions, we may not necessarily require the organization within the resource to ensure uniqueness; however, if a user were a super-user, they might want to be able to provide it to narrow the information returned to them.) Thoughts? thanks, Brad From paji at redhat.com Tue May 31 21:25:06 2011 From: paji at redhat.com (Partha Aji) Date: Tue, 31 May 2011 17:25:06 -0400 (EDT) Subject: [katello-devel] Approaches on Changeset Manipulation by multiple users In-Reply-To: <443938085.387804.1306869747823.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <482530592.391043.1306877106668.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Justin and I have been looking for a method for enabling multiple users manipulate/update the same changeset simultaneously before promoting it to the next environment. Main issue here is that the updates made to the changeset should be transparent to both users. Before promotion they should exactly know what is getting promoted. Problem here is that when 2 users are updating the changeset at the same time or the same user has the same page opened in 2 browser windows and clicks promote, the last change wins. So to remedy this 2 approaches were suggested 1) Polling based approach. Here, every 2 or 3 seconds a check will be made to the server asking if the changeset changed at the server (similar to how notifications behave) and the changset UI will auto refresh if it changed. I guess the User will be given some notice saying "the changeset has been changed, refreshing your promotion tree and changset contents..." 2) Locking based approach. Only one user can change the changeset at a time. So user kinda acquires a lock on changeset and modifies it and unlocks it or unlocks on time out so that some other user can work on it. Before deciding to promote. Pros of approach 1 Multiple users can update a changeset and be aware of changes happening actively. Cons It can be an annoying experience with contents you just changed automatically getting refreshed/overwritten with the updated stuff. The hard part from the coding perspective will be reconciling the changes you made with the changes in the updated changeset. Pros of approach 2 No reconciling business as simultaneous updates on a changeset are forbidden. Cons When will the changeset lock get released. What happens if a user stays on the same changeset forever and wont allow others to update or promote. Locking/Unlocking has to be worked out from the coding perspective. We'd have to be cognizant of the fact that the same user may be updating the changeset from 2 different browsers (should we allow that or not ...). I prefer 1 for the simple reason it makes best use of the model based changes justin has made so that changeset can be updated by multiple users and also that we have methods to do polling :)... It also allows for User with permission to product A and user with permissions product B simultaneously update the changeset.. Thoughts ?? Partha From mmccune at redhat.com Tue May 31 21:36:38 2011 From: mmccune at redhat.com (Mike McCune) Date: Tue, 31 May 2011 14:36:38 -0700 Subject: [katello-devel] error handling in orchestration In-Reply-To: <4DE54234.4020306@redhat.com> References: <4DE54234.4020306@redhat.com> Message-ID: <4DE55F66.6090804@redhat.com> On 05/31/2011 12:32 PM, Dmitri Dolguikh wrote: > Yet another change in orchestration engine insides. Now when an > exception is thrown during orchestration, and after the rollback is > performed, the original exception that started it all will be re-thrown > (and thus will show up in controllers). thank you thank you thank you! > > If you are writing orchestration code, instead of using old and busted > Glue.falure method, simply log the error, and then re-raise the exception! +1 Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From mmccune at redhat.com Tue May 31 22:54:02 2011 From: mmccune at redhat.com (Mike McCune) Date: Tue, 31 May 2011 15:54:02 -0700 Subject: [katello-devel] Approaches on Changeset Manipulation by multiple users In-Reply-To: <482530592.391043.1306877106668.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <482530592.391043.1306877106668.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4DE5718A.5080509@redhat.com> On 05/31/2011 02:25 PM, Partha Aji wrote: > Justin and I have been looking for a method for enabling multiple users manipulate/update the same changeset simultaneously before promoting it to the next environment. Main issue here is that the updates made to the changeset should be transparent to both users. Before promotion they should exactly know what is getting promoted. Problem here is that when 2 users are updating the changeset at the same time or the same user has the same page opened in 2 browser windows and clicks promote, the last change wins. So to remedy this 2 approaches were suggested > > 1) Polling based approach. Here, every 2 or 3 seconds a check will be made to the server asking if the changeset changed at the server (similar to how notifications behave) and the changset UI will auto refresh if it changed. I guess the User will be given some notice saying "the changeset has been changed, refreshing your promotion tree and changset contents..." > > 2) Locking based approach. Only one user can change the changeset at a time. So user kinda acquires a lock on changeset and modifies it and unlocks it or unlocks on time out so that some other user can work on it. Before deciding to promote. > > > Pros of approach 1 > Multiple users can update a changeset and be aware of changes happening actively. > > Cons > It can be an annoying experience with contents you just changed automatically getting refreshed/overwritten with the updated stuff. The hard part from the coding perspective will be reconciling the changes you made with the changes in the updated changeset. > > Pros of approach 2 > No reconciling business as simultaneous updates on a changeset are forbidden. > > Cons > When will the changeset lock get released. What happens if a user stays on the same changeset forever and wont allow others to update or promote. Locking/Unlocking has to be worked out from the coding perspective. We'd have to be cognizant of the fact that the same user may be updating the changeset from 2 different browsers (should we allow that or not ...). > > I prefer 1 for the simple reason it makes best use of the model based changes justin has made so that changeset can be updated by multiple users and also that we have methods to do polling :)... It also allows for User with permission to product A and user with permissions product B simultaneously update the changeset.. > > > Thoughts ?? I think locking it down to single user access would be prohibitively annoying for an end user. We should implement a polling mechanism but I wouldn't do it as often as 2-3 seconds, I'd increase it to something like 60-120 seconds to reduce the load on the Katello server. 2-3 second polling is a bit much even if the API call is very minimal. That could scale to be something pretty bad if you have hundreds or thousands of users on the site. Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From tsanders at redhat.com Tue May 31 22:59:39 2011 From: tsanders at redhat.com (Todd Sanders) Date: Tue, 31 May 2011 18:59:39 -0400 (EDT) Subject: [katello-devel] Approaches on Changeset Manipulation by multiple users In-Reply-To: <4DE5718A.5080509@redhat.com> References: <482530592.391043.1306877106668.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <4DE5718A.5080509@redhat.com> Message-ID: Sent from my iPhone On May 31, 2011, at 6:54 PM, Mike McCune wrote: > On 05/31/2011 02:25 PM, Partha Aji wrote: >> Justin and I have been looking for a method for enabling multiple users manipulate/update the same changeset simultaneously before promoting it to the next environment. Main issue here is that the updates made to the changeset should be transparent to both users. Before promotion they should exactly know what is getting promoted. Problem here is that when 2 users are updating the changeset at the same time or the same user has the same page opened in 2 browser windows and clicks promote, the last change wins. So to remedy this 2 approaches were suggested >> >> 1) Polling based approach. Here, every 2 or 3 seconds a check will be made to the server asking if the changeset changed at the server (similar to how notifications behave) and the changset UI will auto refresh if it changed. I guess the User will be given some notice saying "the changeset has been changed, refreshing your promotion tree and changset contents..." >> >> 2) Locking based approach. Only one user can change the changeset at a time. So user kinda acquires a lock on changeset and modifies it and unlocks it or unlocks on time out so that some other user can work on it. Before deciding to promote. >> >> >> Pros of approach 1 >> Multiple users can update a changeset and be aware of changes happening actively. >> >> Cons >> It can be an annoying experience with contents you just changed automatically getting refreshed/overwritten with the updated stuff. The hard part from the coding perspective will be reconciling the changes you made with the changes in the updated changeset. >> >> Pros of approach 2 >> No reconciling business as simultaneous updates on a changeset are forbidden. >> >> Cons >> When will the changeset lock get released. What happens if a user stays on the same changeset forever and wont allow others to update or promote. Locking/Unlocking has to be worked out from the coding perspective. We'd have to be cognizant of the fact that the same user may be updating the changeset from 2 different browsers (should we allow that or not ...). >> >> I prefer 1 for the simple reason it makes best use of the model based changes justin has made so that changeset can be updated by multiple users and also that we have methods to do polling :)... It also allows for User with permission to product A and user with permissions product B simultaneously update the changeset.. >> >> >> Thoughts ?? > > I think locking it down to single user access would be prohibitively annoying for an end user. We should implement a polling mechanism but I wouldn't do it as often as 2-3 seconds, I'd increase it to something like 60-120 seconds to reduce the load on the Katello server. 2-3 second polling is a bit much even if the API call is very minimal. That could scale to be something pretty bad if you have hundreds or thousands of users on the site. > > > Mike > -- > 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 paji at redhat.com Tue May 31 23:07:16 2011 From: paji at redhat.com (Partha Aji) Date: Tue, 31 May 2011 19:07:16 -0400 (EDT) Subject: [katello-devel] Approaches on Changeset Manipulation by multiple users In-Reply-To: <4DE5718A.5080509@redhat.com> Message-ID: <196509420.392648.1306883236142.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Mike McCune" > To: "Partha Aji" > Cc: katello-devel at redhat.com > Sent: Tuesday, May 31, 2011 6:54:02 PM > Subject: Re: [katello-devel] Approaches on Changeset Manipulation by multiple users > On 05/31/2011 02:25 PM, Partha Aji wrote: > > Justin and I have been looking for a method for enabling multiple > > users manipulate/update the same changeset simultaneously before > > promoting it to the next environment. Main issue here is that the > > updates made to the changeset should be transparent to both users. > > Before promotion they should exactly know what is getting promoted. > > Problem here is that when 2 users are updating the changeset at the > > same time or the same user has the same page opened in 2 browser > > windows and clicks promote, the last change wins. So to remedy this > > 2 approaches were suggested > > > > 1) Polling based approach. Here, every 2 or 3 seconds a check will > > be made to the server asking if the changeset changed at the server > > (similar to how notifications behave) and the changset UI will auto > > refresh if it changed. I guess the User will be given some notice > > saying "the changeset has been changed, refreshing your promotion > > tree and changset contents..." > > > > 2) Locking based approach. Only one user can change the changeset at > > a time. So user kinda acquires a lock on changeset and modifies it > > and unlocks it or unlocks on time out so that some other user can > > work on it. Before deciding to promote. > > > > > > Pros of approach 1 > > Multiple users can update a changeset and be aware of changes > > happening actively. > > > > Cons > > It can be an annoying experience with contents you just changed > > automatically getting refreshed/overwritten with the updated stuff. > > The hard part from the coding perspective will be reconciling the > > changes you made with the changes in the updated changeset. > > > > Pros of approach 2 > > No reconciling business as simultaneous updates on a changeset are > > forbidden. > > > > Cons > > When will the changeset lock get released. What happens if a user > > stays on the same changeset forever and wont allow others to update > > or promote. Locking/Unlocking has to be worked out from the coding > > perspective. We'd have to be cognizant of the fact that the same > > user may be updating the changeset from 2 different browsers (should > > we allow that or not ...). > > > > I prefer 1 for the simple reason it makes best use of the model > > based changes justin has made so that changeset can be updated by > > multiple users and also that we have methods to do polling :)... It > > also allows for User with permission to product A and user with > > permissions product B simultaneously update the changeset.. > > > > > > Thoughts ?? > > I think locking it down to single user access would be prohibitively > annoying for an end user. We should implement a polling mechanism but > I > wouldn't do it as often as 2-3 seconds, I'd increase it to something > like 60-120 seconds to reduce the load on the Katello server. 2-3 > second polling is a bit much even if the API call is very minimal. > That > could scale to be something pretty bad if you have hundreds or > thousands > of users on the site. > > One thing I hadn't thought of in the polling case was when will "promote" be acceptable. As in User A -> Updates Changeset C User B -> updates the same Now user A hits promote before the polling interval. So if we added the smarts to do a check here, the behaviour should be "User A - Your changeset has been updated by some one else. Reloading the changeset. Click promote again if you happy with it." Now when User A is happy and clicks "promote", User B needs to know that the changeset has been promoted already. This is a kind of oddity. Have to think of how to solve this one next I guess. Partha > Mike > -- > Mike McCune > mmccune AT redhat.com > Red Hat Engineering | Portland, OR > Systems Management | 650.254.4248 From tsanders at redhat.com Tue May 31 23:09:02 2011 From: tsanders at redhat.com (Todd Sanders) Date: Tue, 31 May 2011 19:09:02 -0400 (EDT) Subject: [katello-devel] Approaches on Changeset Manipulation by multiple users In-Reply-To: <4DE5718A.5080509@redhat.com> References: <482530592.391043.1306877106668.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <4DE5718A.5080509@redhat.com> Message-ID: <652BC646-84D9-45BB-8AA9-81A8D83FEDFE@redhat.com> On May 31, 2011, at 6:54 PM, Mike McCune wrote: > On 05/31/2011 02:25 PM, Partha Aji wrote: >> Justin and I have been looking for a method for enabling multiple users manipulate/update the same changeset simultaneously before promoting it to the next environment. Main issue here is that the updates made to the changeset should be transparent to both users. Before promotion they should exactly know what is getting promoted. Problem here is that when 2 users are updating the changeset at the same time or the same user has the same page opened in 2 browser windows and clicks promote, the last change wins. So to remedy this 2 approaches were suggested >> >> 1) Polling based approach. Here, every 2 or 3 seconds a check will be made to the server asking if the changeset changed at the server (similar to how notifications behave) and the changset UI will auto refresh if it changed. I guess the User will be given some notice saying "the changeset has been changed, refreshing your promotion tree and changset contents..." >> >> 2) Locking based approach. Only one user can change the changeset at a time. So user kinda acquires a lock on changeset and modifies it and unlocks it or unlocks on time out so that some other user can work on it. Before deciding to promote. >> >> >> Pros of approach 1 >> Multiple users can update a changeset and be aware of changes happening actively. >> >> Cons >> It can be an annoying experience with contents you just changed automatically getting refreshed/overwritten with the updated stuff. The hard part from the coding perspective will be reconciling the changes you made with the changes in the updated changeset. >> >> Pros of approach 2 >> No reconciling business as simultaneous updates on a changeset are forbidden. >> >> Cons >> When will the changeset lock get released. What happens if a user stays on the same changeset forever and wont allow others to update or promote. Locking/Unlocking has to be worked out from the coding perspective. We'd have to be cognizant of the fact that the same user may be updating the changeset from 2 different browsers (should we allow that or not ...). >> >> I prefer 1 for the simple reason it makes best use of the model based changes justin has made so that changeset can be updated by multiple users and also that we have methods to do polling :)... It also allows for User with permission to product A and user with permissions product B simultaneously update the changeset.. >> >> >> Thoughts ?? > > I think locking it down to single user access would be prohibitively annoying for an end user. We should implement a polling mechanism but I wouldn't do it as often as 2-3 seconds, I'd increase it to something like 60-120 seconds to reduce the load on the Katello server. 2-3 second polling is a bit much even if the API call is very minimal. That could scale to be something pretty bad if you have hundreds or thousands of users on the site. > > > Mike > -- > 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- I would actually prefer option 2. I don't think since we are supporting multiple change sets, locking would be limiting. Users shouldn't need to edit change sets simultaneously. We do need to present the userid and name of the person currently editing. Polling doesn't scale well. -Todd From tsanders at redhat.com Tue May 31 23:13:17 2011 From: tsanders at redhat.com (Todd Sanders) Date: Tue, 31 May 2011 19:13:17 -0400 (EDT) Subject: [katello-devel] Approaches on Changeset Manipulation by multiple users In-Reply-To: <196509420.392648.1306883236142.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <196509420.392648.1306883236142.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: Another reason for choosing the locking approach. -Todd Sent from my iPhone On May 31, 2011, at 7:07 PM, Partha Aji wrote: > > > ----- Original Message ----- >> From: "Mike McCune" >> To: "Partha Aji" >> Cc: katello-devel at redhat.com >> Sent: Tuesday, May 31, 2011 6:54:02 PM >> Subject: Re: [katello-devel] Approaches on Changeset Manipulation by multiple users >> On 05/31/2011 02:25 PM, Partha Aji wrote: >>> Justin and I have been looking for a method for enabling multiple >>> users manipulate/update the same changeset simultaneously before >>> promoting it to the next environment. Main issue here is that the >>> updates made to the changeset should be transparent to both users. >>> Before promotion they should exactly know what is getting promoted. >>> Problem here is that when 2 users are updating the changeset at the >>> same time or the same user has the same page opened in 2 browser >>> windows and clicks promote, the last change wins. So to remedy this >>> 2 approaches were suggested >>> >>> 1) Polling based approach. Here, every 2 or 3 seconds a check will >>> be made to the server asking if the changeset changed at the server >>> (similar to how notifications behave) and the changset UI will auto >>> refresh if it changed. I guess the User will be given some notice >>> saying "the changeset has been changed, refreshing your promotion >>> tree and changset contents..." >>> >>> 2) Locking based approach. Only one user can change the changeset at >>> a time. So user kinda acquires a lock on changeset and modifies it >>> and unlocks it or unlocks on time out so that some other user can >>> work on it. Before deciding to promote. >>> >>> >>> Pros of approach 1 >>> Multiple users can update a changeset and be aware of changes >>> happening actively. >>> >>> Cons >>> It can be an annoying experience with contents you just changed >>> automatically getting refreshed/overwritten with the updated stuff. >>> The hard part from the coding perspective will be reconciling the >>> changes you made with the changes in the updated changeset. >>> >>> Pros of approach 2 >>> No reconciling business as simultaneous updates on a changeset are >>> forbidden. >>> >>> Cons >>> When will the changeset lock get released. What happens if a user >>> stays on the same changeset forever and wont allow others to update >>> or promote. Locking/Unlocking has to be worked out from the coding >>> perspective. We'd have to be cognizant of the fact that the same >>> user may be updating the changeset from 2 different browsers (should >>> we allow that or not ...). >>> >>> I prefer 1 for the simple reason it makes best use of the model >>> based changes justin has made so that changeset can be updated by >>> multiple users and also that we have methods to do polling :)... It >>> also allows for User with permission to product A and user with >>> permissions product B simultaneously update the changeset.. >>> >>> >>> Thoughts ?? >> >> I think locking it down to single user access would be prohibitively >> annoying for an end user. We should implement a polling mechanism but >> I >> wouldn't do it as often as 2-3 seconds, I'd increase it to something >> like 60-120 seconds to reduce the load on the Katello server. 2-3 >> second polling is a bit much even if the API call is very minimal. >> That >> could scale to be something pretty bad if you have hundreds or >> thousands >> of users on the site. >> >> > One thing I hadn't thought of in the polling case was when will "promote" be acceptable. > As in > User A -> Updates Changeset C > User B -> updates the same > Now user A hits promote before the polling interval. > > So if we added the smarts to do a check here, the behaviour should be > "User A - Your changeset has been updated by some one else. Reloading the changeset. Click promote again if you happy with it." > > Now when User A is happy and clicks "promote", User B needs to know that the changeset has been promoted already. This is a kind of oddity. Have to think of how to solve this one next I guess. > > Partha > > > > >> Mike >> -- >> 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 mmccune at redhat.com Tue May 31 23:30:38 2011 From: mmccune at redhat.com (Mike McCune) Date: Tue, 31 May 2011 16:30:38 -0700 Subject: [katello-devel] Approaches on Changeset Manipulation by multiple users In-Reply-To: References: <196509420.392648.1306883236142.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <4DE57A1E.7030302@redhat.com> On 05/31/2011 04:13 PM, Todd Sanders wrote: > Another reason for choosing the locking approach. > > -Todd > > Sent from my iPhone > > On May 31, 2011, at 7:07 PM, Partha Aji wrote: > >> >> >> ----- Original Message ----- >>> From: "Mike McCune" >>> To: "Partha Aji" >>> Cc: katello-devel at redhat.com >>> Sent: Tuesday, May 31, 2011 6:54:02 PM >>> Subject: Re: [katello-devel] Approaches on Changeset Manipulation by multiple users >>> On 05/31/2011 02:25 PM, Partha Aji wrote: >>>> Justin and I have been looking for a method for enabling multiple >>>> users manipulate/update the same changeset simultaneously before >>>> promoting it to the next environment. Main issue here is that the >>>> updates made to the changeset should be transparent to both users. >>>> Before promotion they should exactly know what is getting promoted. >>>> Problem here is that when 2 users are updating the changeset at the >>>> same time or the same user has the same page opened in 2 browser >>>> windows and clicks promote, the last change wins. So to remedy this >>>> 2 approaches were suggested >>>> >>>> 1) Polling based approach. Here, every 2 or 3 seconds a check will >>>> be made to the server asking if the changeset changed at the server >>>> (similar to how notifications behave) and the changset UI will auto >>>> refresh if it changed. I guess the User will be given some notice >>>> saying "the changeset has been changed, refreshing your promotion >>>> tree and changset contents..." >>>> >>>> 2) Locking based approach. Only one user can change the changeset at >>>> a time. So user kinda acquires a lock on changeset and modifies it >>>> and unlocks it or unlocks on time out so that some other user can >>>> work on it. Before deciding to promote. >>>> >>>> >>>> Pros of approach 1 >>>> Multiple users can update a changeset and be aware of changes >>>> happening actively. >>>> >>>> Cons >>>> It can be an annoying experience with contents you just changed >>>> automatically getting refreshed/overwritten with the updated stuff. >>>> The hard part from the coding perspective will be reconciling the >>>> changes you made with the changes in the updated changeset. >>>> >>>> Pros of approach 2 >>>> No reconciling business as simultaneous updates on a changeset are >>>> forbidden. >>>> >>>> Cons >>>> When will the changeset lock get released. What happens if a user >>>> stays on the same changeset forever and wont allow others to update >>>> or promote. Locking/Unlocking has to be worked out from the coding >>>> perspective. We'd have to be cognizant of the fact that the same >>>> user may be updating the changeset from 2 different browsers (should >>>> we allow that or not ...). >>>> >>>> I prefer 1 for the simple reason it makes best use of the model >>>> based changes justin has made so that changeset can be updated by >>>> multiple users and also that we have methods to do polling :)... It >>>> also allows for User with permission to product A and user with >>>> permissions product B simultaneously update the changeset.. >>>> >>>> >>>> Thoughts ?? >>> >>> I think locking it down to single user access would be prohibitively >>> annoying for an end user. We should implement a polling mechanism but >>> I >>> wouldn't do it as often as 2-3 seconds, I'd increase it to something >>> like 60-120 seconds to reduce the load on the Katello server. 2-3 >>> second polling is a bit much even if the API call is very minimal. >>> That >>> could scale to be something pretty bad if you have hundreds or >>> thousands >>> of users on the site. >>> >>> >> One thing I hadn't thought of in the polling case was when will "promote" be acceptable. >> As in >> User A -> Updates Changeset C >> User B -> updates the same >> Now user A hits promote before the polling interval. >> >> So if we added the smarts to do a check here, the behaviour should be >> "User A - Your changeset has been updated by some one else. Reloading the changeset. Click promote again if you happy with it." >> >> Now when User A is happy and clicks "promote", User B needs to know that the changeset has been promoted already. This is a kind of oddity. Have to think of how to solve this one next I guess. >> >> Partha >> I talked to Todd on the phone for a bit and I'm now leaning towards a locking mechanism so each user is aware someone else is editing the changeset and can't step on each other's changes. The thought was we would have buttons to lock or unlock a changeset for editing or at least some mechanism to manage the changes to the changeset. Partha, can you setup a meeting tomorrow so we can finalize some solutions for this issue? Mike