From mhulan at redhat.com Fri Mar 1 13:55:19 2013 From: mhulan at redhat.com (Marek Hulan) Date: Fri, 01 Mar 2013 14:55:19 +0100 Subject: [katello-devel] Design of SSO Message-ID: <8519698.OQj6EZSIeR@edna> Hi all As a part of US I work on this iteration I created a design wiki page [1] for SSO discussed recently. Please take a look and ping me if you have any comments or questions. [1] https://fedorahosted.org/katello/wiki/SingleSignOn -- Marek From lzap at redhat.com Mon Mar 4 08:36:11 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 4 Mar 2013 09:36:11 +0100 Subject: [katello-devel] Design of SSO In-Reply-To: <8519698.OQj6EZSIeR@edna> References: <8519698.OQj6EZSIeR@edna> Message-ID: <20130304083611.GA2756@lzapx.brq.redhat.com> Thanks for the writeup. Couple of questions: Why not to store whole OpenID URL instead of just username in the cookie. It looks more consistent to me. For security reasons, both applications would need to check the url if it is in expected format. For security reasons, application<->SSO must be https with server certificate check (both ends). Don't we want to condition SSO usage by LDAP? Then there is no need of asking Katello for authentication. Also migration could be easier - you can use Foreman as standalone application with LDAP and then add Katello without any pain of migration user accounts. LZ On Fri, Mar 01, 2013 at 02:55:19PM +0100, Marek Hulan wrote: > Hi all > > As a part of US I work on this iteration I created a design wiki page [1] for > SSO discussed recently. Please take a look and ping me if you have any > comments or questions. > > [1] https://fedorahosted.org/katello/wiki/SingleSignOn > > -- > Marek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From mhulan at redhat.com Mon Mar 4 09:17:25 2013 From: mhulan at redhat.com (Marek Hulan) Date: Mon, 04 Mar 2013 10:17:25 +0100 Subject: [katello-devel] Design of SSO In-Reply-To: <20130304083611.GA2756@lzapx.brq.redhat.com> References: <8519698.OQj6EZSIeR@edna> <20130304083611.GA2756@lzapx.brq.redhat.com> Message-ID: <7616116.7JxJ3tCPgB@edna> Hi answers below in text > Why not to store whole OpenID URL instead of just username in the > cookie. It looks more consistent to me. For security reasons, both > applications would need to check the url if it is in expected format. I thought of login as a primary user identifier across all related systems. We can later use kerberos as SSO auth backend so we'd need mapping of login to kerberos principal etc. SSO identifier is just for RP <-> SSO authentication. > For security reasons, application<->SSO must be https with server > certificate check (both ends). Yes that's for sure, I forgot to mention it on Wiki. I'll add it. The reason (maybe not the only one) is that DiffieHellman exchange is subjected to MITM attacks. Also user <-> SSO must be protected by https (user sends password). > Don't we want to condition SSO usage by LDAP? Then there is no need of > asking Katello for authentication. Also migration could be easier - you > can use Foreman as standalone application with LDAP and then add Katello > without any pain of migration user accounts. I thought there are possible setups where customer have users in Katello internal DB without LDAP and also uses Foreman. They would be forced to migrate to LDAP in order to use SSO then? Katello seemed to me as natural choice because it's already primary source of users for Katello and Foreman. There can exist Foreman-only users but they have no access to Katello then however all Katello users have access to Foreman right? By forcing LDAP user database, SSO could be used even without Katello by other services however we would also duplicate this logic which is already in Katello (and will stay there as fallback). Thank you for questions and comments. Marek > > LZ > > On Fri, Mar 01, 2013 at 02:55:19PM +0100, Marek Hulan wrote: > > Hi all > > > > As a part of US I work on this iteration I created a design wiki page [1] > > for SSO discussed recently. Please take a look and ping me if you have > > any comments or questions. > > > > [1] https://fedorahosted.org/katello/wiki/SingleSignOn -- Marek From inecas at redhat.com Mon Mar 4 10:46:02 2013 From: inecas at redhat.com (Ivan Necas) Date: Mon, 4 Mar 2013 05:46:02 -0500 (EST) Subject: [katello-devel] Design of SSO In-Reply-To: <7616116.7JxJ3tCPgB@edna> Message-ID: <818133209.12136155.1362393962991.JavaMail.root@redhat.com> ----- Original Message ----- > Hi > > answers below in text > > > Why not to store whole OpenID URL instead of just username in the > > cookie. It looks more consistent to me. For security reasons, both > > applications would need to check the url if it is in expected > > format. > I thought of login as a primary user identifier across all related > systems. We > can later use kerberos as SSO auth backend so we'd need mapping of > login to > kerberos principal etc. SSO identifier is just for RP <-> SSO > authentication. > > > For security reasons, application<->SSO must be https with server > > certificate check (both ends). > Yes that's for sure, I forgot to mention it on Wiki. I'll add it. The > reason > (maybe not the only one) is that DiffieHellman exchange is subjected > to MITM > attacks. Also user <-> SSO must be protected by https (user sends > password). > > > Don't we want to condition SSO usage by LDAP? Then there is no need > > of > > asking Katello for authentication. Also migration could be easier - > > you > > can use Foreman as standalone application with LDAP and then add > > Katello > > without any pain of migration user accounts. > I thought there are possible setups where customer have users in > Katello > internal DB without LDAP and also uses Foreman. They would be forced > to > migrate to LDAP in order to use SSO then? Katello seemed to me as > natural > choice because it's already primary source of users for Katello and > Foreman. > There can exist Foreman-only users but they have no access to Katello > then > however all Katello users have access to Foreman right? By forcing > LDAP user > database, SSO could be used even without Katello by other services > however we > would also duplicate this logic which is already in Katello (and will > stay > there as fallback). > +1 for leaving LDAP as optional if possible, which is this case. -- Ivan > Thank you for questions and comments. > > Marek > > > > > LZ > > > > On Fri, Mar 01, 2013 at 02:55:19PM +0100, Marek Hulan wrote: > > > Hi all > > > > > > As a part of US I work on this iteration I created a design wiki > > > page [1] > > > for SSO discussed recently. Please take a look and ping me if you > > > have > > > any comments or questions. > > > > > > [1] https://fedorahosted.org/katello/wiki/SingleSignOn > -- > Marek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From thomasmckay at redhat.com Mon Mar 4 13:17:52 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 4 Mar 2013 08:17:52 -0500 (EST) Subject: [katello-devel] Design of SSO In-Reply-To: <7616116.7JxJ3tCPgB@edna> Message-ID: <1474616007.9805072.1362403072693.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Marek Hulan" > To: katello-devel at redhat.com > Sent: Monday, March 4, 2013 4:17:25 AM > Subject: Re: [katello-devel] Design of SSO > > Hi > > answers below in text > > > Why not to store whole OpenID URL instead of just username in the > > cookie. It looks more consistent to me. For security reasons, both > > applications would need to check the url if it is in expected > > format. > I thought of login as a primary user identifier across all related > systems. We > can later use kerberos as SSO auth backend so we'd need mapping of > login to > kerberos principal etc. SSO identifier is just for RP <-> SSO > authentication. > > > For security reasons, application<->SSO must be https with server > > certificate check (both ends). > Yes that's for sure, I forgot to mention it on Wiki. I'll add it. The > reason > (maybe not the only one) is that DiffieHellman exchange is subjected > to MITM > attacks. Also user <-> SSO must be protected by https (user sends > password). > > > Don't we want to condition SSO usage by LDAP? Then there is no need > > of > > asking Katello for authentication. Also migration could be easier - > > you > > can use Foreman as standalone application with LDAP and then add > > Katello > > without any pain of migration user accounts. > I thought there are possible setups where customer have users in > Katello > internal DB without LDAP and also uses Foreman. They would be forced > to > migrate to LDAP in order to use SSO then? Katello seemed to me as > natural > choice because it's already primary source of users for Katello and > Foreman. > There can exist Foreman-only users but they have no access to Katello > then > however all Katello users have access to Foreman right? By forcing > LDAP user > database, SSO could be used even without Katello by other services > however we > would also duplicate this logic which is already in Katello (and will > stay > there as fallback). I think LDAP has to be an available option from the very start, even if it's a requirement that you can't mix-and-match (ie. both or neither must use LDAP). > > Thank you for questions and comments. > > Marek > > > > > LZ > > > > On Fri, Mar 01, 2013 at 02:55:19PM +0100, Marek Hulan wrote: > > > Hi all > > > > > > As a part of US I work on this iteration I created a design wiki > > > page [1] > > > for SSO discussed recently. Please take a look and ping me if you > > > have > > > any comments or questions. > > > > > > [1] https://fedorahosted.org/katello/wiki/SingleSignOn > -- > Marek > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From dmitri at redhat.com Mon Mar 4 14:19:42 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 04 Mar 2013 14:19:42 +0000 Subject: [katello-devel] Design of SSO In-Reply-To: <8519698.OQj6EZSIeR@edna> References: <8519698.OQj6EZSIeR@edna> Message-ID: <5134AD7E.9000405@redhat.com> Why not use real OpenID server/protocol for user authentication? RP side: - displays user identity dialog (and performs html-based OP discovery, see [2]) - when using our SSO we can use pre-configured user id prefix (http://redhat.com/sso/user in Marek'e example) - creates and handles the cookie (that stores user identity) OP side: - performs authentication. Automatically assumes that user trusts Katello and Foreman (requires some amount of modification on the provider side). This would give us better control over the cookie (OpenID provider is not involved). We also would be using a mostly normal OpenID provider. The somewhat inconvenient bit is in userid and password being entered on separate screens. Thoughts? -d [2] http://openid.net/specs/openid-authentication-2_0.html#html_disco On 01/03/13 01:55 PM, Marek Hulan wrote: > Hi all > > As a part of US I work on this iteration I created a design wiki page [1] for > SSO discussed recently. Please take a look and ping me if you have any > comments or questions. > > [1] https://fedorahosted.org/katello/wiki/SingleSignOn > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkearney at redhat.com Mon Mar 4 14:32:07 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 04 Mar 2013 09:32:07 -0500 Subject: [katello-devel] Design of SSO In-Reply-To: <1474616007.9805072.1362403072693.JavaMail.root@redhat.com> References: <1474616007.9805072.1362403072693.JavaMail.root@redhat.com> Message-ID: <5134B067.6020300@redhat.com> On 03/04/2013 08:17 AM, Tom McKay wrote: >> I thought there are possible setups where customer have users in >> >Katello >> >internal DB without LDAP and also uses Foreman. They would be forced >> >to >> >migrate to LDAP in order to use SSO then? Katello seemed to me as >> >natural >> >choice because it's already primary source of users for Katello and >> >Foreman. >> >There can exist Foreman-only users but they have no access to Katello >> >then >> >however all Katello users have access to Foreman right? By forcing >> >LDAP user >> >database, SSO could be used even without Katello by other services >> >however we >> >would also duplicate this logic which is already in Katello (and will >> >stay >> >there as fallback). > I think LDAP has to be an available option from the very start, even if it's a requirement that you can't mix-and-match (ie. both or neither must use LDAP). > i think we need the following priority driven order of development: 1) DB backed user storage, credentials checked agains tthat. 2) LDAP backed user storage, credentials checked against that. 3) User identity taken from Kerberos ticket How the Communication is done, and what contraints exist on Foreman and Katello may be different. However.. that should be the order. Eventually, all users and groups needs to come from LDAP. -- kb From mhulan at redhat.com Mon Mar 4 15:22:52 2013 From: mhulan at redhat.com (Marek Hulan) Date: Mon, 04 Mar 2013 16:22:52 +0100 Subject: [katello-devel] Design of SSO In-Reply-To: <5134B067.6020300@redhat.com> References: <1474616007.9805072.1362403072693.JavaMail.root@redhat.com> <5134B067.6020300@redhat.com> Message-ID: <1539253.qxu9aejKRn@edna> On Monday 04 of March 2013 09:32:07 Bryan Kearney wrote: > On 03/04/2013 08:17 AM, Tom McKay wrote: > >> I thought there are possible setups where customer have users in > >> > >> >Katello > >> >internal DB without LDAP and also uses Foreman. They would be forced > >> >to > >> >migrate to LDAP in order to use SSO then? Katello seemed to me as > >> >natural > >> >choice because it's already primary source of users for Katello and > >> >Foreman. > >> >There can exist Foreman-only users but they have no access to Katello > >> >then > >> >however all Katello users have access to Foreman right? By forcing > >> >LDAP user > >> >database, SSO could be used even without Katello by other services > >> >however we > >> >would also duplicate this logic which is already in Katello (and will > >> >stay > >> >there as fallback). > > > > I think LDAP has to be an available option from the very start, even if > > it's a requirement that you can't mix-and-match (ie. both or neither must > > use LDAP). > i think we need the following priority driven order of development: > > 1) DB backed user storage, credentials checked agains tthat. > 2) LDAP backed user storage, credentials checked against that. > 3) User identity taken from Kerberos ticket Ok, this is not how it currently works so should I take it as a part of SSO US or we'll solve it in future? Currently Katello asks DB xor LDAP based on configuration. If we agree that SSO (new app) will use Katello to authenticate, this will be the way how login will work when US is finished. > > How the Communication is done, and what contraints exist on Foreman and > Katello may be different. However.. that should be the order. > > Eventually, all users and groups needs to come from LDAP. > -- kb > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Marek From lzap at redhat.com Mon Mar 4 16:22:46 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 4 Mar 2013 17:22:46 +0100 Subject: [katello-devel] Design of SSO In-Reply-To: <5134AD7E.9000405@redhat.com> References: <8519698.OQj6EZSIeR@edna> <5134AD7E.9000405@redhat.com> Message-ID: <20130304162246.GH2756@lzapx.brq.redhat.com> On Mon, Mar 04, 2013 at 02:19:42PM +0000, Dmitri Dolguikh wrote: > provider. The somewhat inconvenient bit is in userid and password > being entered on separate screens. I am fine with that, but I can imagine many confused users :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From sseago at redhat.com Mon Mar 4 16:46:05 2013 From: sseago at redhat.com (Scott Seago) Date: Mon, 04 Mar 2013 11:46:05 -0500 Subject: [katello-devel] Design of SSO In-Reply-To: <20130304162246.GH2756@lzapx.brq.redhat.com> References: <8519698.OQj6EZSIeR@edna> <5134AD7E.9000405@redhat.com> <20130304162246.GH2756@lzapx.brq.redhat.com> Message-ID: <5134CFCD.6080201@redhat.com> On 03/04/2013 11:22 AM, Lukas Zapletal wrote: > On Mon, Mar 04, 2013 at 02:19:42PM +0000, Dmitri Dolguikh wrote: >> provider. The somewhat inconvenient bit is in userid and password >> being entered on separate screens. > I am fine with that, but I can imagine many confused users :-) > Unrelated to the overall SSO question, but I've seen username and password on different screens on various sites in the past. When it's done, it's often deliberate (with doc links explaining why they separated them). I have no idea what the merits of that decision were -- I'm just pointing out that users are likely to have seen this scenario in the past, even if it's not the most common arrangement. Scott From bkearney at redhat.com Mon Mar 4 16:48:48 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 04 Mar 2013 11:48:48 -0500 Subject: [katello-devel] Design of SSO In-Reply-To: <5134CFCD.6080201@redhat.com> References: <8519698.OQj6EZSIeR@edna> <5134AD7E.9000405@redhat.com> <20130304162246.GH2756@lzapx.brq.redhat.com> <5134CFCD.6080201@redhat.com> Message-ID: <5134D070.3090905@redhat.com> On 03/04/2013 11:46 AM, Scott Seago wrote: > On 03/04/2013 11:22 AM, Lukas Zapletal wrote: >> On Mon, Mar 04, 2013 at 02:19:42PM +0000, Dmitri Dolguikh wrote: >>> provider. The somewhat inconvenient bit is in userid and password >>> being entered on separate screens. >> I am fine with that, but I can imagine many confused users :-) >> > Unrelated to the overall SSO question, but I've seen username and > password on different screens on various sites in the past. When it's > done, it's often deliberate (with doc links explaining why they > separated them). I have no idea what the merits of that decision were -- > I'm just pointing out that users are likely to have seen this scenario > in the past, even if it's not the most common arrangement. > > Scott > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel It does seem a bit on the nasty side. -- bk From sseago at redhat.com Mon Mar 4 16:57:16 2013 From: sseago at redhat.com (Scott Seago) Date: Mon, 04 Mar 2013 11:57:16 -0500 Subject: [katello-devel] Design of SSO In-Reply-To: <5134D070.3090905@redhat.com> References: <8519698.OQj6EZSIeR@edna> <5134AD7E.9000405@redhat.com> <20130304162246.GH2756@lzapx.brq.redhat.com> <5134CFCD.6080201@redhat.com> <5134D070.3090905@redhat.com> Message-ID: <5134D26C.3040801@redhat.com> On 03/04/2013 11:48 AM, Bryan Kearney wrote: > On 03/04/2013 11:46 AM, Scott Seago wrote: >> On 03/04/2013 11:22 AM, Lukas Zapletal wrote: >>> On Mon, Mar 04, 2013 at 02:19:42PM +0000, Dmitri Dolguikh wrote: >>>> provider. The somewhat inconvenient bit is in userid and password >>>> being entered on separate screens. >>> I am fine with that, but I can imagine many confused users :-) >>> >> Unrelated to the overall SSO question, but I've seen username and >> password on different screens on various sites in the past. When it's >> done, it's often deliberate (with doc links explaining why they >> separated them). I have no idea what the merits of that decision were -- >> I'm just pointing out that users are likely to have seen this scenario >> in the past, even if it's not the most common arrangement. >> >> Scott >> > It does seem a bit on the nasty side. > -- bk > That could be -- I wasn't recommending it so much as suggesting that it probably wouldn't confuse users too badly -- whether it's the best/correct approach is a separate question. Scott From bkearney at redhat.com Mon Mar 4 16:57:48 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 04 Mar 2013 11:57:48 -0500 Subject: [katello-devel] Design of SSO In-Reply-To: <1539253.qxu9aejKRn@edna> References: <1474616007.9805072.1362403072693.JavaMail.root@redhat.com> <5134B067.6020300@redhat.com> <1539253.qxu9aejKRn@edna> Message-ID: <5134D28C.2060308@redhat.com> On 03/04/2013 10:22 AM, Marek Hulan wrote: > Ok, this is not how it currently works so should I take it as a part of SSO US > or we'll solve it in future? Currently Katello asks DB xor LDAP based on > configuration. If we agree that SSO (new app) will use Katello to authenticate, > this will be the way how login will work when US is finished. I assumed that SSO would be a stand alone thing which both Katello and FOreman can use. If we require LDAP only for that, then I would actually be fine with it. - bk From mhulan at redhat.com Mon Mar 4 17:12:26 2013 From: mhulan at redhat.com (Marek Hulan) Date: Mon, 04 Mar 2013 18:12:26 +0100 Subject: [katello-devel] Design of SSO In-Reply-To: <5134D28C.2060308@redhat.com> References: <1474616007.9805072.1362403072693.JavaMail.root@redhat.com> <1539253.qxu9aejKRn@edna> <5134D28C.2060308@redhat.com> Message-ID: <7746013.7pGRmRLpPz@edna> On Monday 04 of March 2013 11:57:48 Bryan Kearney wrote: > On 03/04/2013 10:22 AM, Marek Hulan wrote: > > Ok, this is not how it currently works so should I take it as a part of > > SSO US or we'll solve it in future? Currently Katello asks DB xor LDAP > > based on configuration. If we agree that SSO (new app) will use Katello > > to authenticate, this will be the way how login will work when US is > > finished. > > I assumed that SSO would be a stand alone thing which both Katello and > FOreman can use. If we require LDAP only for that, then I would actually > be fine with it. It will but the plan was to use Katello also for it's auth backend. Copying LDAP authentication from Katello to SSO is possible but would mean code duplication (it must stay also in Katello because of fallback). So why not to use Katello which already knows how to deal with DB/LDAP and is already authoritative user DB. Using Foremen without Katello probably does not require SSO (or is there use case for other systems that would benefit from using this SSO and won't use Katello?) -- Marek From tstrachota at redhat.com Tue Mar 5 12:57:27 2013 From: tstrachota at redhat.com (Tomas Strachota) Date: Tue, 05 Mar 2013 13:57:27 +0100 Subject: [katello-devel] API v2 - proposed changes in routes Message-ID: <5135EBB7.808@redhat.com> Hi team, Martin and me are working on API v2. We went through the pain points that were discovered and described during documentation process of v1 [1]. In terms of routing the changes we propose are summarized in [2]. I divided them into 4 groups: 1) routes created by mistake in routes.rb or unused routes 2) routes nested too deep 3) other duplicate or not much resty routes 4) RPC-like calls I guess we can't do anything with The routes in the etherpad are in "rake routes" format with comments under each of them. There are also planned changes in output json format and accepted parameter. We will describe them in separate email. In a discussion on irc Jeff suggested new feature - possibility to identify resources by it's names. I think it's something we can extend the clean api v2 with later. For sake of simplicity and speed of development I'd rather stay only with cleanup and making the api consistent. We can do names as identifiers later as a separate task if we find it useful. Opinions are welcome Tomas [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts [2] https://pad-katello.rhcloud.com/p/API_v2_routes From jweiss at redhat.com Tue Mar 5 13:21:36 2013 From: jweiss at redhat.com (Jeff Weiss) Date: Tue, 05 Mar 2013 08:21:36 -0500 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <5135EBB7.808@redhat.com> References: <5135EBB7.808@redhat.com> Message-ID: <87k3pmugm7.fsf@blinky.jweiss.com> Tomas Strachota writes: > Hi team, > Martin and me are working on API v2. We went through the pain points > that were discovered and described during documentation process of v1 [1]. > > In terms of routing the changes we propose are summarized in [2]. > I divided them into 4 groups: > 1) routes created by mistake in routes.rb or unused routes > 2) routes nested too deep > 3) other duplicate or not much resty routes > 4) RPC-like calls I guess we can't do anything with > The routes in the etherpad are in "rake routes" format with comments > under each of them. > > There are also planned changes in output json format and accepted > parameter. We will describe them in separate email. > > In a discussion on irc Jeff suggested new feature - possibility to > identify resources by it's names. I think it's something we can extend > the clean api v2 with later. For sake of simplicity and speed of > development I'd rather stay only with cleanup and making the api > consistent. We can do names as identifiers later as a separate task if > we find it useful. > > Opinions are welcome > Tomas > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > [2] https://pad-katello.rhcloud.com/p/API_v2_routes > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Looks good to me. Fixing #2 will be helpful to me as well, it will require fewer queries to get id's. -- Jeff Weiss Principal Quality Assurance Engineer jweiss at redhat.com (919)886-6533 From ericdhelms at gmail.com Tue Mar 5 13:29:02 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Tue, 5 Mar 2013 08:29:02 -0500 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <87k3pmugm7.fsf@blinky.jweiss.com> References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> Message-ID: On #2, if one of our core operating principles is that nearly everything is scoped based on an organization, why would we want to abstract that away and not make it explicit as part of resource look-up? Given that a design goal of RESTful APIs is to be predictable, I would think the form that includes organization at the trunk of the route is more predictable and mimics how resources are structured. On changes to JSON format, I would like to make the request that there be thought put into API "paging". I am starting to work on using the API for some UI components and adding our Elasticsearch infrastructure to these API calls. This typically involves requesting a chunk of resources (say 25 for example) and then requesting the next 25 as the user demands them. As well, being able to look at the returned data to know the total number of records even though I am only getting say 26-50 with that particular call. - Eric On Tue, Mar 5, 2013 at 8:21 AM, Jeff Weiss wrote: > Tomas Strachota writes: > > > Hi team, > > Martin and me are working on API v2. We went through the pain points > > that were discovered and described during documentation process of v1 > [1]. > > > > In terms of routing the changes we propose are summarized in [2]. > > I divided them into 4 groups: > > 1) routes created by mistake in routes.rb or unused routes > > 2) routes nested too deep > > 3) other duplicate or not much resty routes > > 4) RPC-like calls I guess we can't do anything with > > The routes in the etherpad are in "rake routes" format with comments > > under each of them. > > > > There are also planned changes in output json format and accepted > > parameter. We will describe them in separate email. > > > > In a discussion on irc Jeff suggested new feature - possibility to > > identify resources by it's names. I think it's something we can extend > > the clean api v2 with later. For sake of simplicity and speed of > > development I'd rather stay only with cleanup and making the api > > consistent. We can do names as identifiers later as a separate task if > > we find it useful. > > > > Opinions are welcome > > Tomas > > > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > > [2] https://pad-katello.rhcloud.com/p/API_v2_routes > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > Looks good to me. > > Fixing #2 will be helpful to me as well, it will require fewer queries > to get id's. > > -- > Jeff Weiss > Principal Quality Assurance Engineer > jweiss at redhat.com > (919)886-6533 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jweiss at redhat.com Tue Mar 5 14:02:48 2013 From: jweiss at redhat.com (Jeff Weiss) Date: Tue, 05 Mar 2013 09:02:48 -0500 Subject: [katello-devel] Menu usability needs more work Message-ID: <87hakquepj.fsf@blinky.jweiss.com> So far I've counted at least 4 of our own engineers who could not figure out where the "Manage Orgs" link is. Here's what I propose to make the katello easier to navigate. * Move the Manage Orgs link to the top level, always visible (possibly in the header, similar to where the Administer link used to be). * Maybe rename the menu link to something else. I think Tom mentioned "Global". * All javascript menu. Moving between the "Manage Orgs" menu and Main menu should not require a full page load. Thoughts, suggestions? -jeff -- Jeff Weiss Principal Quality Assurance Engineer jweiss at redhat.com (919)886-6533 From thomasmckay at redhat.com Tue Mar 5 14:08:03 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 5 Mar 2013 09:08:03 -0500 (EST) Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: Message-ID: <785747676.10327657.1362492483151.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eric D Helms" > To: "Jeff Weiss" > Cc: katello-devel at redhat.com > Sent: Tuesday, March 5, 2013 8:29:02 AM > Subject: Re: [katello-devel] API v2 - proposed changes in routes > > > > On #2, if one of our core operating principles is that nearly > everything is scoped based on an organization, why would we want to > abstract that away and not make it explicit as part of resource > look-up? Given that a design goal of RESTful APIs is to be > predictable, I would think the form that includes organization at > the trunk of the route is more predictable and mimics how resources > are structured. Yes please! If we can get the organization label at the base of the path in this work that would be fantastic. At the moment is impossible to create links that can be saved and used later. > > > On changes to JSON format, I would like to make the request that > there be thought put into API "paging". I am starting to work on > using the API for some UI components and adding our Elasticsearch > infrastructure to these API calls. This typically involves > requesting a chunk of resources (say 25 for example) and then > requesting the next 25 as the user demands them. As well, being able > to look at the returned data to know the total number of records > even though I am only getting say 26-50 with that particular call. > > > > > - Eric > > > > On Tue, Mar 5, 2013 at 8:21 AM, Jeff Weiss < jweiss at redhat.com > > wrote: > > > > > Tomas Strachota < tstrachota at redhat.com > writes: > > > Hi team, > > Martin and me are working on API v2. We went through the pain > > points > > that were discovered and described during documentation process of > > v1 [1]. > > > > In terms of routing the changes we propose are summarized in [2]. > > I divided them into 4 groups: > > 1) routes created by mistake in routes.rb or unused routes > > 2) routes nested too deep > > 3) other duplicate or not much resty routes > > 4) RPC-like calls I guess we can't do anything with > > The routes in the etherpad are in "rake routes" format with > > comments > > under each of them. > > > > There are also planned changes in output json format and accepted > > parameter. We will describe them in separate email. > > > > In a discussion on irc Jeff suggested new feature - possibility to > > identify resources by it's names. I think it's something we can > > extend > > the clean api v2 with later. For sake of simplicity and speed of > > development I'd rather stay only with cleanup and making the api > > consistent. We can do names as identifiers later as a separate task > > if > > we find it useful. > > > > Opinions are welcome > > Tomas > > > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > > [2] https://pad-katello.rhcloud.com/p/API_v2_routes > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > Looks good to me. > > Fixing #2 will be helpful to me as well, it will require fewer > queries > to get id's. > > -- > Jeff Weiss > Principal Quality Assurance Engineer > jweiss at redhat.com > (919)886-6533 > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From tstrachota at redhat.com Tue Mar 5 14:11:29 2013 From: tstrachota at redhat.com (Tomas Strachota) Date: Tue, 05 Mar 2013 15:11:29 +0100 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> Message-ID: <5135FD11.601@redhat.com> On 03/05/2013 02:29 PM, Eric D Helms wrote: > On #2, if one of our core operating principles is that nearly everything > is scoped based on an organization, why would we want to abstract that > away and not make it explicit as part of resource look-up? Given that a > design goal of RESTful APIs is to be predictable, I would think the form > that includes organization at the trunk of the route is more predictable > and mimics how resources are structured. > The idea was not to get rid of the resource relations. The scope would still be there for collections. For example environments would look like: crate: POST /organization/ACME/ list: GET /organization/ACME/environments/ show: POST /environments/1/ update: PUT /environments/1/ destroy: DELETE /environments/1/ I think of it like this: I want to see what environments I have in org ACME -> I go to /organization/ACME/environments/. Now I know ids of all the environments I'm interested in. If I want to change it, I know it's environment so I go to /environments/1/. I don't have to keep in mind what org it's in. When whole api behaves the same I find it predictable. Basically everything in Katello is scoped under orgs. I'm afraid that if we wanted to be consistent and keep the full paths, we would get really long routes like DELETE /organization/ACME/changesets/:id/packages/:id/ > On changes to JSON format, I would like to make the request that there > be thought put into API "paging". I am starting to work on using the > API for some UI components and adding our Elasticsearch infrastructure > to these API calls. This typically involves requesting a chunk of > resources (say 25 for example) and then requesting the next 25 as the > user demands them. As well, being able to look at the returned data to > know the total number of records even though I am only getting say 26-50 > with that particular call. > +1 I like paging. > > - Eric > > > On Tue, Mar 5, 2013 at 8:21 AM, Jeff Weiss > wrote: > > Tomas Strachota > writes: > > > Hi team, > > Martin and me are working on API v2. We went through the pain points > > that were discovered and described during documentation process > of v1 [1]. > > > > In terms of routing the changes we propose are summarized in [2]. > > I divided them into 4 groups: > > 1) routes created by mistake in routes.rb or unused routes > > 2) routes nested too deep > > 3) other duplicate or not much resty routes > > 4) RPC-like calls I guess we can't do anything with > > The routes in the etherpad are in "rake routes" format with comments > > under each of them. > > > > There are also planned changes in output json format and accepted > > parameter. We will describe them in separate email. > > > > In a discussion on irc Jeff suggested new feature - possibility to > > identify resources by it's names. I think it's something we can > extend > > the clean api v2 with later. For sake of simplicity and speed of > > development I'd rather stay only with cleanup and making the api > > consistent. We can do names as identifiers later as a separate > task if > > we find it useful. > > > > Opinions are welcome > > Tomas > > > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > > [2] https://pad-katello.rhcloud.com/p/API_v2_routes > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > Looks good to me. > > Fixing #2 will be helpful to me as well, it will require fewer queries > to get id's. > > -- > Jeff Weiss > Principal Quality Assurance Engineer > jweiss at redhat.com > (919)886-6533 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > From dmitri at redhat.com Tue Mar 5 14:19:53 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 05 Mar 2013 14:19:53 +0000 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <5135EBB7.808@redhat.com> References: <5135EBB7.808@redhat.com> Message-ID: <5135FF09.3020004@redhat.com> Thanks for sharing the ongoing work - this is awesome. Please see comments below. On 05/03/13 12:57 PM, Tomas Strachota wrote: > Hi team, > Martin and me are working on API v2. We went through the pain points > that were discovered and described during documentation process of v1 > [1]. > > In terms of routing the changes we propose are summarized in [2]. > I divided them into 4 groups: > 1) routes created by mistake in routes.rb or unused routes > 2) routes nested too deep It appears sync_plans resource uses a non-unique resource id which has to be used in the context of its parent resource (see https://github.com/Katello/katello/blob/master/src/app/controllers/api/sync_plans_controller.rb#L109). I don't know the reasons behind sync_plan not being globally unique. The rest of the changes look ok. > > 3) other duplicate or not much resty routes > 4) RPC-like calls I guess we can't do anything with /api/providers/:id/refresh_products(.:format) Ought to be a dedicated resource (possibly and async operation). Probably should return status of each product refresh (the operation can fail) /api/content_views/:id/refresh and /api/content_views/:id/promote - both are async tasks, I think it would be better to introduce resources like: content_views/tasks/promotion content_views/tasks/refresh or content_views/:id/tasks/promotion content_views/:id/tasks/refresh and then use returned task id to track the status via tasks/:id same goes for POST /api/changesets/:id/apply(.:format) > The routes in the etherpad are in "rake routes" format with comments > under each of them. > > There are also planned changes in output json format and accepted > parameter. We will describe them in separate email. > > In a discussion on irc Jeff suggested new feature - possibility to > identify resources by it's names. I think it's something we can extend > the clean api v2 with later. For sake of simplicity and speed of > development I'd rather stay only with cleanup and making the api > consistent. We can do names as identifiers later as a separate task if > we find it useful. We had this discussion awhile ago. I think we should support searching by any attribute (or combination). Using two resource ID's is probably not worth the trouble, and the bigger issue is using intrinsically non-unique names/labels for resource identification, as it drags in issues with renames (should we return 301?), delete and create (should we prevent from creating new resources with the name of the deleted one? What about the users who are unaware of the delete and now think that the resource has simply been updated?), etc, etc. Cheers, -d > > Opinions are welcome > Tomas > > [1] https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > [2] https://pad-katello.rhcloud.com/p/API_v2_routes > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitri at redhat.com Tue Mar 5 14:27:01 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 05 Mar 2013 14:27:01 +0000 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <5135FD11.601@redhat.com> References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> <5135FD11.601@redhat.com> Message-ID: <513600B5.1070804@redhat.com> On 05/03/13 02:11 PM, Tomas Strachota wrote: > On 03/05/2013 02:29 PM, Eric D Helms wrote: >> On #2, if one of our core operating principles is that nearly everything >> is scoped based on an organization, why would we want to abstract that >> away and not make it explicit as part of resource look-up? Given that a >> design goal of RESTful APIs is to be predictable, I would think the form >> that includes organization at the trunk of the route is more predictable >> and mimics how resources are structured. >> > > The idea was not to get rid of the resource relations. The scope would > still be there for collections. For example environments would look like: > > crate: POST /organization/ACME/ > list: GET /organization/ACME/environments/ > show: POST /environments/1/ > update: PUT /environments/1/ > destroy: DELETE /environments/1/ > > I think of it like this: > I want to see what environments I have in org ACME -> I go to > /organization/ACME/environments/. Now I know ids of all the > environments I'm interested in. If I want to change it, I know it's > environment so I go to /environments/1/. I don't have to keep in mind > what org it's in. > When whole api behaves the same I find it predictable. +1. That's precisely it. Internally, if you don't do a join on the organization, its id is superfluous - there's no need to drag it in the resource url. -d From dmitri at redhat.com Tue Mar 5 14:31:14 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 05 Mar 2013 14:31:14 +0000 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> Message-ID: <513601B2.9050306@redhat.com> On 05/03/13 01:29 PM, Eric D Helms wrote: > On #2, if one of our core operating principles is that nearly > everything is scoped based on an organization, why would we want to > abstract that away and not make it explicit as part of resource > look-up? Given that a design goal of RESTful APIs is to be > predictable, I would think the form that includes organization at the > trunk of the route is more predictable and mimics how resources are > structured. > > On changes to JSON format, I would like to make the request that there > be thought put into API "paging". I am starting to work on using the > API for some UI components and adding our Elasticsearch infrastructure > to these API calls. This typically involves requesting a chunk of > resources (say 25 for example) and then requesting the next 25 as the > user demands them. As well, being able to look at the returned data > to know the total number of records even though I am only getting say > 26-50 with that particular call. Hmm, wouldn't paging be better expressed as a url parameter (it is in essence a filter after all): /organizations/?from=10&to=20 Total number of records in the collection would come in json though. -d From ericdhelms at gmail.com Tue Mar 5 14:46:50 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Tue, 5 Mar 2013 09:46:50 -0500 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <513601B2.9050306@redhat.com> References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> <513601B2.9050306@redhat.com> Message-ID: On Tue, Mar 5, 2013 at 9:31 AM, Dmitri Dolguikh wrote: > On 05/03/13 01:29 PM, Eric D Helms wrote: > >> On #2, if one of our core operating principles is that nearly everything >> is scoped based on an organization, why would we want to abstract that away >> and not make it explicit as part of resource look-up? Given that a design >> goal of RESTful APIs is to be predictable, I would think the form that >> includes organization at the trunk of the route is more predictable and >> mimics how resources are structured. >> >> On changes to JSON format, I would like to make the request that there be >> thought put into API "paging". I am starting to work on using the API for >> some UI components and adding our Elasticsearch infrastructure to these API >> calls. This typically involves requesting a chunk of resources (say 25 for >> example) and then requesting the next 25 as the user demands them. As >> well, being able to look at the returned data to know the total number of >> records even though I am only getting say 26-50 with that particular call. >> > > Hmm, wouldn't paging be better expressed as a url parameter (it is in > essence a filter after all): > > /organizations/?from=10&to=20 > > Total number of records in the collection would come in json though. It would still be expressed as URL parameters but the collection object should also contain this. Consider you are working with just the collection, you want to know what chunk you are dealing with without having to parse out the URL. This is a common pattern from my experience as well, e.g. Possibly even including what generated this particular chunk. But at a minimum: { total: 365, offset: 25, limit: 25 items : [{ }] } > > > -d > > > ______________________________**_________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/**mailman/listinfo/katello-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericdhelms at gmail.com Tue Mar 5 14:52:13 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Tue, 5 Mar 2013 09:52:13 -0500 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <5135FD11.601@redhat.com> References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> <5135FD11.601@redhat.com> Message-ID: On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota wrote: > On 03/05/2013 02:29 PM, Eric D Helms wrote: > >> On #2, if one of our core operating principles is that nearly everything >> is scoped based on an organization, why would we want to abstract that >> away and not make it explicit as part of resource look-up? Given that a >> design goal of RESTful APIs is to be predictable, I would think the form >> that includes organization at the trunk of the route is more predictable >> and mimics how resources are structured. >> >> > The idea was not to get rid of the resource relations. The scope would > still be there for collections. For example environments would look like: > > crate: POST /organization/ACME/ > list: GET /organization/ACME/**environments/ > show: POST /environments/1/ > update: PUT /environments/1/ > destroy: DELETE /environments/1/ > > I think of it like this: > I want to see what environments I have in org ACME -> I go to > /organization/ACME/**environments/. Now I know ids of all the > environments I'm interested in. If I want to change it, I know it's > environment so I go to /environments/1/. I don't have to keep in mind what > org it's in. > When whole api behaves the same I find it predictable. > > Given that the API is another user interface, I feel that it's important for all our interfaces to mimic one another in structure as well as keep certain details in the forefront of users minds. In the UI, most entities are scoped based on Organization and this is expressed throughout the design goals. This should, in my opinion, spill over into the API so that resources are predictable and mimic other workflows the user will be accustomed to. Using our API, I should have to actively deal with the fact that System A is a part of Org X to help me understand the implications and because this is a built in hierarchy that we've expressed as a guiding principle of our design. I can understand your argument for predictability, but if I start querying the collection via /organization/ACME_Corporation/environments/, based on the principles of REST, I would expect that I can just add an ID to the end of that URL and acquire the specific resource. Eric > Basically everything in Katello is scoped under orgs. I'm afraid that if > we wanted to be consistent and keep the full paths, we would get really > long routes like > DELETE /organization/ACME/changesets/**:id/packages/:id/ > > > On changes to JSON format, I would like to make the request that there >> be thought put into API "paging". I am starting to work on using the >> API for some UI components and adding our Elasticsearch infrastructure >> to these API calls. This typically involves requesting a chunk of >> resources (say 25 for example) and then requesting the next 25 as the >> user demands them. As well, being able to look at the returned data to >> know the total number of records even though I am only getting say 26-50 >> with that particular call. >> >> > +1 I like paging. > > >> - Eric >> >> >> On Tue, Mar 5, 2013 at 8:21 AM, Jeff Weiss > > wrote: >> >> Tomas Strachota > **> writes: >> >> > Hi team, >> > Martin and me are working on API v2. We went through the pain >> points >> > that were discovered and described during documentation process >> of v1 [1]. >> > >> > In terms of routing the changes we propose are summarized in [2]. >> > I divided them into 4 groups: >> > 1) routes created by mistake in routes.rb or unused routes >> > 2) routes nested too deep >> > 3) other duplicate or not much resty routes >> > 4) RPC-like calls I guess we can't do anything with >> > The routes in the etherpad are in "rake routes" format with >> comments >> > under each of them. >> > >> > There are also planned changes in output json format and accepted >> > parameter. We will describe them in separate email. >> > >> > In a discussion on irc Jeff suggested new feature - possibility to >> > identify resources by it's names. I think it's something we can >> extend >> > the clean api v2 with later. For sake of simplicity and speed of >> > development I'd rather stay only with cleanup and making the api >> > consistent. We can do names as identifiers later as a separate >> task if >> > we find it useful. >> > >> > Opinions are welcome >> > Tomas >> > >> > [1] https://fedorahosted.org/**katello/wiki/** >> APIDocumentationEfforts >> > [2] https://pad-katello.rhcloud.**com/p/API_v2_routes >> > >> > ______________________________**_________________ >> > katello-devel mailing list >> > katello-devel at redhat.com >> > >> >> > https://www.redhat.com/**mailman/listinfo/katello-devel >> >> Looks good to me. >> >> Fixing #2 will be helpful to me as well, it will require fewer queries >> to get id's. >> >> -- >> Jeff Weiss >> Principal Quality Assurance Engineer >> jweiss at redhat.com >> (919)886-6533 >> >> ______________________________**_________________ >> katello-devel mailing list >> katello-devel at redhat.com >> > >> https://www.redhat.com/**mailman/listinfo/katello-devel >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmckay at redhat.com Tue Mar 5 15:00:16 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 5 Mar 2013 10:00:16 -0500 (EST) Subject: [katello-devel] Menu usability needs more work In-Reply-To: <87hakquepj.fsf@blinky.jweiss.com> Message-ID: <1346831855.10351593.1362495616091.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Jeff Weiss" > To: katello-devel at redhat.com > Sent: Tuesday, March 5, 2013 9:02:48 AM > Subject: [katello-devel] Menu usability needs more work > > So far I've counted at least 4 of our own engineers who could not > figure > out where the "Manage Orgs" link is. > > Here's what I propose to make the katello easier to navigate. > > * Move the Manage Orgs link to the top level, always visible > (possibly > in the header, similar to where the Administer link used to be). > > * Maybe rename the menu link to something else. I think Tom > mentioned > "Global". > > * All javascript menu. Moving between the "Manage Orgs" menu and > Main > menu should not require a full page load. > > Thoughts, suggestions? > > -jeff > Agree that there needs to be a more prominent way to get to the "global" features. Ideally it would be an tab at the same level as Dashboard, Content, Systems. Perhaps it could be differentiated by placing it to the far right of the screen (beneath the user, notice count, and Log Out)? This would let me hover over it as well and jump right to Users, etc. When switching to global context, the User, Roles, etc. could still be moved to be top level tabs. From thomasmckay at redhat.com Tue Mar 5 15:05:19 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 5 Mar 2013 10:05:19 -0500 (EST) Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <513600B5.1070804@redhat.com> Message-ID: <1358772958.10355253.1362495919629.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dmitri Dolguikh" > To: katello-devel at redhat.com > Sent: Tuesday, March 5, 2013 9:27:01 AM > Subject: Re: [katello-devel] API v2 - proposed changes in routes > > On 05/03/13 02:11 PM, Tomas Strachota wrote: > > On 03/05/2013 02:29 PM, Eric D Helms wrote: > >> On #2, if one of our core operating principles is that nearly > >> everything > >> is scoped based on an organization, why would we want to abstract > >> that > >> away and not make it explicit as part of resource look-up? Given > >> that a > >> design goal of RESTful APIs is to be predictable, I would think > >> the form > >> that includes organization at the trunk of the route is more > >> predictable > >> and mimics how resources are structured. > >> > > > > The idea was not to get rid of the resource relations. The scope > > would > > still be there for collections. For example environments would look > > like: > > > > crate: POST /organization/ACME/ > > list: GET /organization/ACME/environments/ > > show: POST /environments/1/ > > update: PUT /environments/1/ > > destroy: DELETE /environments/1/ > > > > I think of it like this: > > I want to see what environments I have in org ACME -> I go to > > /organization/ACME/environments/. Now I know ids of all the > > environments I'm interested in. If I want to change it, I know it's > > environment so I go to /environments/1/. I don't have to keep in > > mind > > what org it's in. > > When whole api behaves the same I find it predictable. > > +1. That's precisely it. Internally, if you don't do a join on the > organization, its id is superfluous - there's no need to drag it in > the > resource url. > > -d So we won't allow labels in the URLs, or labels would be required to use the deeper nesting? GET /organization/ACME/environments -> {id: 1, label: DEV} GET /environment/1 -> {id: 1, label: DEV} GET /organization/ACME/environments/DEV -> {id: 1, label: DEV} maybe? From dmitri at redhat.com Tue Mar 5 15:14:12 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 05 Mar 2013 15:14:12 +0000 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <1358772958.10355253.1362495919629.JavaMail.root@redhat.com> References: <1358772958.10355253.1362495919629.JavaMail.root@redhat.com> Message-ID: <51360BC4.5090405@redhat.com> On 05/03/13 03:05 PM, Tom McKay wrote: > > ----- Original Message ----- >> From: "Dmitri Dolguikh" >> To: katello-devel at redhat.com >> Sent: Tuesday, March 5, 2013 9:27:01 AM >> Subject: Re: [katello-devel] API v2 - proposed changes in routes >> >> On 05/03/13 02:11 PM, Tomas Strachota wrote: >>> On 03/05/2013 02:29 PM, Eric D Helms wrote: >>>> On #2, if one of our core operating principles is that nearly >>>> everything >>>> is scoped based on an organization, why would we want to abstract >>>> that >>>> away and not make it explicit as part of resource look-up? Given >>>> that a >>>> design goal of RESTful APIs is to be predictable, I would think >>>> the form >>>> that includes organization at the trunk of the route is more >>>> predictable >>>> and mimics how resources are structured. >>>> >>> The idea was not to get rid of the resource relations. The scope >>> would >>> still be there for collections. For example environments would look >>> like: >>> >>> crate: POST /organization/ACME/ >>> list: GET /organization/ACME/environments/ >>> show: POST /environments/1/ >>> update: PUT /environments/1/ >>> destroy: DELETE /environments/1/ >>> >>> I think of it like this: >>> I want to see what environments I have in org ACME -> I go to >>> /organization/ACME/environments/. Now I know ids of all the >>> environments I'm interested in. If I want to change it, I know it's >>> environment so I go to /environments/1/. I don't have to keep in >>> mind >>> what org it's in. >>> When whole api behaves the same I find it predictable. >> +1. That's precisely it. Internally, if you don't do a join on the >> organization, its id is superfluous - there's no need to drag it in >> the >> resource url. >> >> -d > So we won't allow labels in the URLs, or labels would be required to use the deeper nesting? > > GET /organization/ACME/environments -> {id: 1, label: DEV} > GET /environment/1 -> {id: 1, label: DEV} > GET /organization/ACME/environments/DEV -> {id: 1, label: DEV} > > maybe? Heh heh. I suppose labels could be used when the scope is constrained (by the organization in this case). However, I would very much prefer GET /organization/ACME/environments?label=DEV -> {id: 1, label: DEV} As it clearly shows that "DEV" is not an id, and consequently is less permanent, and the resource may or may not be there. -d From thomasmckay at redhat.com Tue Mar 5 15:21:17 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 5 Mar 2013 10:21:17 -0500 (EST) Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <51360BC4.5090405@redhat.com> Message-ID: <438246262.10362794.1362496877227.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dmitri Dolguikh" > To: "Tom McKay" > Cc: katello-devel at redhat.com > Sent: Tuesday, March 5, 2013 10:14:12 AM > Subject: Re: [katello-devel] API v2 - proposed changes in routes > > On 05/03/13 03:05 PM, Tom McKay wrote: > > > > ----- Original Message ----- > >> From: "Dmitri Dolguikh" > >> To: katello-devel at redhat.com > >> Sent: Tuesday, March 5, 2013 9:27:01 AM > >> Subject: Re: [katello-devel] API v2 - proposed changes in routes > >> > >> On 05/03/13 02:11 PM, Tomas Strachota wrote: > >>> On 03/05/2013 02:29 PM, Eric D Helms wrote: > >>>> On #2, if one of our core operating principles is that nearly > >>>> everything > >>>> is scoped based on an organization, why would we want to > >>>> abstract > >>>> that > >>>> away and not make it explicit as part of resource look-up? Given > >>>> that a > >>>> design goal of RESTful APIs is to be predictable, I would think > >>>> the form > >>>> that includes organization at the trunk of the route is more > >>>> predictable > >>>> and mimics how resources are structured. > >>>> > >>> The idea was not to get rid of the resource relations. The scope > >>> would > >>> still be there for collections. For example environments would > >>> look > >>> like: > >>> > >>> crate: POST /organization/ACME/ > >>> list: GET /organization/ACME/environments/ > >>> show: POST /environments/1/ > >>> update: PUT /environments/1/ > >>> destroy: DELETE /environments/1/ > >>> > >>> I think of it like this: > >>> I want to see what environments I have in org ACME -> I go to > >>> /organization/ACME/environments/. Now I know ids of all the > >>> environments I'm interested in. If I want to change it, I know > >>> it's > >>> environment so I go to /environments/1/. I don't have to keep in > >>> mind > >>> what org it's in. > >>> When whole api behaves the same I find it predictable. > >> +1. That's precisely it. Internally, if you don't do a join on the > >> organization, its id is superfluous - there's no need to drag it > >> in > >> the > >> resource url. > >> > >> -d > > So we won't allow labels in the URLs, or labels would be required > > to use the deeper nesting? > > > > GET /organization/ACME/environments -> {id: 1, label: DEV} > > GET /environment/1 -> {id: 1, label: DEV} > > GET /organization/ACME/environments/DEV -> {id: 1, label: DEV} > > > > maybe? > > Heh heh. I suppose labels could be used when the scope is constrained > (by the organization in this case). However, I would very much prefer > > GET /organization/ACME/environments?label=DEV -> {id: 1, label: DEV} > > As it clearly shows that "DEV" is not an id, and consequently is less > permanent, and the resource may or may not be there. > > -d Params would be better. All of the following would return same result: GET /organization/environments?label=DEV GET /organization/environments?name=DEV GET /organization/environments?id=1 GET /organization/environments/1 From dmitri at redhat.com Tue Mar 5 15:28:42 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 05 Mar 2013 15:28:42 +0000 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> <5135FD11.601@redhat.com> Message-ID: <51360F2A.7010005@redhat.com> On 05/03/13 02:52 PM, Eric D Helms wrote: > > > > On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota > wrote: > > On 03/05/2013 02:29 PM, Eric D Helms wrote: > > On #2, if one of our core operating principles is that nearly > everything > is scoped based on an organization, why would we want to > abstract that > away and not make it explicit as part of resource look-up? > Given that a > design goal of RESTful APIs is to be predictable, I would > think the form > that includes organization at the trunk of the route is more > predictable > and mimics how resources are structured. > > > The idea was not to get rid of the resource relations. The scope > would still be there for collections. For example environments > would look like: > > crate: POST /organization/ACME/ > list: GET /organization/ACME/environments/ > show: POST /environments/1/ > update: PUT /environments/1/ > destroy: DELETE /environments/1/ > > I think of it like this: > I want to see what environments I have in org ACME -> I go to > /organization/ACME/environments/. Now I know ids of all the > environments I'm interested in. If I want to change it, I know > it's environment so I go to /environments/1/. I don't have to keep > in mind what org it's in. > When whole api behaves the same I find it predictable. > > Given that the API is another user interface, I feel that it's > important for all our interfaces to mimic one another in structure as > well as keep certain details in the forefront of users minds. In the > UI, most entities are scoped based on Organization and this is > expressed throughout the design goals. This should, in my opinion, > spill over into the API so that resources are predictable and mimic > other workflows the user will be accustomed to. Using our API, I > should have to actively deal with the fact that System A is a part of > Org X to help me understand the implications and because this is a > built in hierarchy that we've expressed as a guiding principle of our > design. API doesn't have a concept of the 'current' organization, which is another hint at the fact that API is used differently from UI. Using organizations and environments as an example, a typical flow would be: GET organizations/:id/environments PUT environments/:id The presence of the organization bit in the url would imply to me that the environment id is unique within organization only (which has its own consequences). As this is not the case here, organization information isn't merely noise, it's misleading. > > I can understand your argument for predictability, but if I start > querying the collection via > /organization/ACME_Corporation/environments/, based on the principles > of REST, I would expect that I can just add an ID to the end of that > URL and acquire the specific resource. What principle[s] of REST do you refer to here? -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitri at redhat.com Tue Mar 5 15:34:45 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 05 Mar 2013 15:34:45 +0000 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <438246262.10362794.1362496877227.JavaMail.root@redhat.com> References: <438246262.10362794.1362496877227.JavaMail.root@redhat.com> Message-ID: <51361095.7070705@redhat.com> >>> So we won't allow labels in the URLs, or labels would be required >>> to use the deeper nesting? >>> >>> GET /organization/ACME/environments -> {id: 1, label: DEV} >>> GET /environment/1 -> {id: 1, label: DEV} >>> GET /organization/ACME/environments/DEV -> {id: 1, label: DEV} >>> >>> maybe? >> Heh heh. I suppose labels could be used when the scope is constrained >> (by the organization in this case). However, I would very much prefer >> >> GET /organization/ACME/environments?label=DEV -> {id: 1, label: DEV} >> >> As it clearly shows that "DEV" is not an id, and consequently is less >> permanent, and the resource may or may not be there. >> >> -d > Params would be better. All of the following would return same result: > > GET /organization/environments?label=DEV > GET /organization/environments?name=DEV > GET /organization/environments?id=1 > GET /organization/environments/1 Sure. The difference between the last two (and the last call should really be GET /environments/1 unless environment id is non-unique globally) is that: - GET /organizations/:id/environments?id=1 (or any other attribute) either returns a list of matching resources, or an empty list - GET /organizations/:id/environments/1 either returns the resource (singular), or a 404 In other words, the difference in semantics between "get" (the resource is expected to exist) and "find" (may or may not exist) calls. -d From thomasmckay at redhat.com Tue Mar 5 15:37:44 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 5 Mar 2013 10:37:44 -0500 (EST) Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <51361095.7070705@redhat.com> Message-ID: <1401648118.10406833.1362497864412.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Dmitri Dolguikh" > To: "Tom McKay" > Cc: katello-devel at redhat.com > Sent: Tuesday, March 5, 2013 10:34:45 AM > Subject: Re: [katello-devel] API v2 - proposed changes in routes > > > >>> So we won't allow labels in the URLs, or labels would be required > >>> to use the deeper nesting? > >>> > >>> GET /organization/ACME/environments -> {id: 1, label: DEV} > >>> GET /environment/1 -> {id: 1, label: DEV} > >>> GET /organization/ACME/environments/DEV -> {id: 1, label: DEV} > >>> > >>> maybe? > >> Heh heh. I suppose labels could be used when the scope is > >> constrained > >> (by the organization in this case). However, I would very much > >> prefer > >> > >> GET /organization/ACME/environments?label=DEV -> {id: 1, label: > >> DEV} > >> > >> As it clearly shows that "DEV" is not an id, and consequently is > >> less > >> permanent, and the resource may or may not be there. > >> > >> -d > > Params would be better. All of the following would return same > > result: > > > > GET /organization/environments?label=DEV > > GET /organization/environments?name=DEV > > GET /organization/environments?id=1 > > GET /organization/environments/1 > > Sure. The difference between the last two (and the last call should > really be GET /environments/1 unless environment id is non-unique > globally) is that: > > - GET /organizations/:id/environments?id=1 (or any other attribute) > either returns a list of matching resources, or an empty list > - GET /organizations/:id/environments/1 either returns the resource > (singular), or a 404 > > In other words, the difference in semantics between "get" (the > resource > is expected to exist) and "find" (may or may not exist) calls. > > -d > > So all the param-based calls would return list (or empty list), while explicit use of /$id would return single item (or 404)? From jsherril at redhat.com Tue Mar 5 15:39:44 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 05 Mar 2013 10:39:44 -0500 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <51360F2A.7010005@redhat.com> References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> <5135FD11.601@redhat.com> <51360F2A.7010005@redhat.com> Message-ID: <513611C0.2020206@redhat.com> On 03/05/2013 10:28 AM, Dmitri Dolguikh wrote: > On 05/03/13 02:52 PM, Eric D Helms wrote: >> >> >> >> On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota >> > wrote: >> >> On 03/05/2013 02:29 PM, Eric D Helms wrote: >> >> On #2, if one of our core operating principles is that nearly >> everything >> is scoped based on an organization, why would we want to >> abstract that >> away and not make it explicit as part of resource look-up? >> Given that a >> design goal of RESTful APIs is to be predictable, I would >> think the form >> that includes organization at the trunk of the route is more >> predictable >> and mimics how resources are structured. >> >> >> The idea was not to get rid of the resource relations. The scope >> would still be there for collections. For example environments >> would look like: >> >> crate: POST /organization/ACME/ >> list: GET /organization/ACME/environments/ >> show: POST /environments/1/ >> update: PUT /environments/1/ >> destroy: DELETE /environments/1/ >> >> I think of it like this: >> I want to see what environments I have in org ACME -> I go to >> /organization/ACME/environments/. Now I know ids of all the >> environments I'm interested in. If I want to change it, I know >> it's environment so I go to /environments/1/. I don't have to >> keep in mind what org it's in. >> When whole api behaves the same I find it predictable. >> >> Given that the API is another user interface, I feel that it's >> important for all our interfaces to mimic one another in structure as >> well as keep certain details in the forefront of users minds. In the >> UI, most entities are scoped based on Organization and this is >> expressed throughout the design goals. This should, in my opinion, >> spill over into the API so that resources are predictable and mimic >> other workflows the user will be accustomed to. Using our API, I >> should have to actively deal with the fact that System A is a part of >> Org X to help me understand the implications and because this is a >> built in hierarchy that we've expressed as a guiding principle of our >> design. > > API doesn't have a concept of the 'current' organization, which is > another hint at the fact that API is used differently from UI. Using > organizations and environments as an example, a typical flow would be: > > GET organizations/:id/environments > PUT environments/:id > > The presence of the organization bit in the url would imply to me that > the environment id is unique within organization only (which has its > own consequences). As this is not the case here, organization > information isn't merely noise, it's misleading. I think not having the org_id in the url makes our api much more confusing today. For example, GET environments/ requires organization_id as a parameter, as does POST environments/ so the user is left guessing, does this require an org_id or not? I also think the concept of "if the environment id is unique within the org only or not" is moot, as the user does not define the id, so why does he care under what scope is it unique? If the id was set by the user that might be a valid point. -Justin > >> >> I can understand your argument for predictability, but if I start >> querying the collection via >> /organization/ACME_Corporation/environments/, based on the principles >> of REST, I would expect that I can just add an ID to the end of that >> URL and acquire the specific resource. > > What principle[s] of REST do you refer to here? > > -d > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmckay at redhat.com Tue Mar 5 15:43:07 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 5 Mar 2013 10:43:07 -0500 (EST) Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <513611C0.2020206@redhat.com> Message-ID: <2088341628.10408942.1362498187550.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Justin Sherrill" > To: katello-devel at redhat.com > Sent: Tuesday, March 5, 2013 10:39:44 AM > Subject: Re: [katello-devel] API v2 - proposed changes in routes > > > On 03/05/2013 10:28 AM, Dmitri Dolguikh wrote: > > > On 05/03/13 02:52 PM, Eric D Helms wrote: > > > > > > > > > On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota < > tstrachota at redhat.com > wrote: > > > > On 03/05/2013 02:29 PM, Eric D Helms wrote: > > > On #2, if one of our core operating principles is that nearly > everything > is scoped based on an organization, why would we want to abstract > that > away and not make it explicit as part of resource look-up? Given that > a > design goal of RESTful APIs is to be predictable, I would think the > form > that includes organization at the trunk of the route is more > predictable > and mimics how resources are structured. > > > The idea was not to get rid of the resource relations. The scope > would still be there for collections. For example environments would > look like: > > crate: POST /organization/ACME/ > list: GET /organization/ACME/environments/ > show: POST /environments/1/ > update: PUT /environments/1/ > destroy: DELETE /environments/1/ > > I think of it like this: > I want to see what environments I have in org ACME -> I go to > /organization/ACME/environments/. Now I know ids of all the > environments I'm interested in. If I want to change it, I know it's > environment so I go to /environments/1/. I don't have to keep in > mind what org it's in. > When whole api behaves the same I find it predictable. > > > Given that the API is another user interface, I feel that it's > important for all our interfaces to mimic one another in structure > as well as keep certain details in the forefront of users minds. In > the UI, most entities are scoped based on Organization and this is > expressed throughout the design goals. This should, in my opinion, > spill over into the API so that resources are predictable and mimic > other workflows the user will be accustomed to. Using our API, I > should have to actively deal with the fact that System A is a part > of Org X to help me understand the implications and because this is > a built in hierarchy that we've expressed as a guiding principle of > our design. > API doesn't have a concept of the 'current' organization, which is > another hint at the fact that API is used differently from UI. Using > organizations and environments as an example, a typical flow would > be: > > GET organizations/:id/environments > PUT environments/:id > > The presence of the organization bit in the url would imply to me > that the environment id is unique within organization only (which > has its own consequences). As this is not the case here, > organization information isn't merely noise, it's misleading. > > I think not having the org_id in the url makes our api much more > confusing today. For example, > > GET environments/ requires organization_id as a parameter, as does > POST environments/ > I think GET /environments/ would return _all_ environments for _all_ orgs. Adding ?org_id=1 would limit (as would adding ?org_label=ACME). > so the user is left guessing, does this require an org_id or not? I > also think the concept of "if the environment id is unique within > the org only or not" is moot, as the user does not define the id, so > why does he care under what scope is it unique? If the id was set by > the user that might be a valid point. > > -Justin > > > > > > > > > > > > > > I can understand your argument for predictability, but if I start > querying the collection via > /organization/ACME_Corporation/environments/, based on the > principles of REST, I would expect that I can just add an ID to the > end of that URL and acquire the specific resource. > What principle[s] of REST do you refer to here? > > -d > > > _______________________________________________ > katello-devel mailing list katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jsherril at redhat.com Tue Mar 5 15:46:12 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 05 Mar 2013 10:46:12 -0500 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <2088341628.10408942.1362498187550.JavaMail.root@redhat.com> References: <2088341628.10408942.1362498187550.JavaMail.root@redhat.com> Message-ID: <51361344.2030707@redhat.com> On 03/05/2013 10:43 AM, Tom McKay wrote: > > ----- Original Message ----- >> From: "Justin Sherrill" >> To: katello-devel at redhat.com >> Sent: Tuesday, March 5, 2013 10:39:44 AM >> Subject: Re: [katello-devel] API v2 - proposed changes in routes >> >> >> On 03/05/2013 10:28 AM, Dmitri Dolguikh wrote: >> >> >> On 05/03/13 02:52 PM, Eric D Helms wrote: >> >> >> >> >> >> >> >> >> On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota< >> tstrachota at redhat.com> wrote: >> >> >> >> On 03/05/2013 02:29 PM, Eric D Helms wrote: >> >> >> On #2, if one of our core operating principles is that nearly >> everything >> is scoped based on an organization, why would we want to abstract >> that >> away and not make it explicit as part of resource look-up? Given that >> a >> design goal of RESTful APIs is to be predictable, I would think the >> form >> that includes organization at the trunk of the route is more >> predictable >> and mimics how resources are structured. >> >> >> The idea was not to get rid of the resource relations. The scope >> would still be there for collections. For example environments would >> look like: >> >> crate: POST /organization/ACME/ >> list: GET /organization/ACME/environments/ >> show: POST /environments/1/ >> update: PUT /environments/1/ >> destroy: DELETE /environments/1/ >> >> I think of it like this: >> I want to see what environments I have in org ACME -> I go to >> /organization/ACME/environments/. Now I know ids of all the >> environments I'm interested in. If I want to change it, I know it's >> environment so I go to /environments/1/. I don't have to keep in >> mind what org it's in. >> When whole api behaves the same I find it predictable. >> >> >> Given that the API is another user interface, I feel that it's >> important for all our interfaces to mimic one another in structure >> as well as keep certain details in the forefront of users minds. In >> the UI, most entities are scoped based on Organization and this is >> expressed throughout the design goals. This should, in my opinion, >> spill over into the API so that resources are predictable and mimic >> other workflows the user will be accustomed to. Using our API, I >> should have to actively deal with the fact that System A is a part >> of Org X to help me understand the implications and because this is >> a built in hierarchy that we've expressed as a guiding principle of >> our design. >> API doesn't have a concept of the 'current' organization, which is >> another hint at the fact that API is used differently from UI. Using >> organizations and environments as an example, a typical flow would >> be: >> >> GET organizations/:id/environments >> PUT environments/:id >> >> The presence of the organization bit in the url would imply to me >> that the environment id is unique within organization only (which >> has its own consequences). As this is not the case here, >> organization information isn't merely noise, it's misleading. >> >> I think not having the org_id in the url makes our api much more >> confusing today. For example, >> >> GET environments/ requires organization_id as a parameter, as does >> POST environments/ >> > I think GET /environments/ would return _all_ environments for _all_ orgs. Adding ?org_id=1 would limit (as would adding ?org_label=ACME). And that would make sorta sense logically (although its not what we do). Do we really want to list all environments across all orgs? Do we want to list every/any arbitrary resource across all orgs? Especially considering names of things can be the same across orgs, could it be confusing? We are very explicit in the UI and cli that the user is working within a single org, do we want to break that philosophy in the api? -Justin >> so the user is left guessing, does this require an org_id or not? I >> also think the concept of "if the environment id is unique within >> the org only or not" is moot, as the user does not define the id, so >> why does he care under what scope is it unique? If the id was set by >> the user that might be a valid point. >> >> -Justin >> >> >> >> >> >> >> >> >> >> >> >> >> >> I can understand your argument for predictability, but if I start >> querying the collection via >> /organization/ACME_Corporation/environments/, based on the >> principles of REST, I would expect that I can just add an ID to the >> end of that URL and acquire the specific resource. >> What principle[s] of REST do you refer to here? >> >> -d >> >> >> _______________________________________________ >> katello-devel mailing list katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From dmitri at redhat.com Tue Mar 5 15:49:44 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 05 Mar 2013 15:49:44 +0000 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> <513601B2.9050306@redhat.com> Message-ID: <51361418.9010803@redhat.com> On 05/03/13 02:46 PM, Eric D Helms wrote: > > > > On Tue, Mar 5, 2013 at 9:31 AM, Dmitri Dolguikh > wrote: > > On 05/03/13 01:29 PM, Eric D Helms wrote: > > On #2, if one of our core operating principles is that nearly > everything is scoped based on an organization, why would we > want to abstract that away and not make it explicit as part of > resource look-up? Given that a design goal of RESTful APIs is > to be predictable, I would think the form that includes > organization at the trunk of the route is more predictable and > mimics how resources are structured. > > On changes to JSON format, I would like to make the request > that there be thought put into API "paging". I am starting to > work on using the API for some UI components and adding our > Elasticsearch infrastructure to these API calls. This > typically involves requesting a chunk of resources (say 25 for > example) and then requesting the next 25 as the user demands > them. As well, being able to look at the returned data to > know the total number of records even though I am only getting > say 26-50 with that particular call. > > > Hmm, wouldn't paging be better expressed as a url parameter (it is > in essence a filter after all): > > /organizations/?from=10&to=20 > > Total number of records in the collection would come in json though. > > > It would still be expressed as URL parameters but the collection > object should also contain this. Consider you are working with just > the collection, you want to know what chunk you are dealing with > without having to parse out the URL. This is a common pattern from my > experience as well, e.g. Possibly even including what generated this > particular chunk. But at a minimum: > > { > total: 365, > offset: 25, > limit: 25 > > items : [{ > > }] > } Hmm. I actually don't see the need for the offset and limit *inside* the collection: - You don't need to parse the url, as you have "offset" and "limit" values in the scope from which the collection retrieval happened (and you can use them directly) - This introduces iteration state into the collection, which turns it into a cursor/iterator style object (which it isn't). You *could* introduce a cursor resource if you wanted to keep track of paging on the server-side, but really - You should wrap collection paging into an iterator-style helper on the client/web-ui-controller. -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitri at redhat.com Tue Mar 5 15:50:35 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 05 Mar 2013 15:50:35 +0000 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <1401648118.10406833.1362497864412.JavaMail.root@redhat.com> References: <1401648118.10406833.1362497864412.JavaMail.root@redhat.com> Message-ID: <5136144B.4000108@redhat.com> On 05/03/13 03:37 PM, Tom McKay wrote: > > ----- Original Message ----- >> From: "Dmitri Dolguikh" >> To: "Tom McKay" >> Cc: katello-devel at redhat.com >> Sent: Tuesday, March 5, 2013 10:34:45 AM >> Subject: Re: [katello-devel] API v2 - proposed changes in routes >> >> >>>>> So we won't allow labels in the URLs, or labels would be required >>>>> to use the deeper nesting? >>>>> >>>>> GET /organization/ACME/environments -> {id: 1, label: DEV} >>>>> GET /environment/1 -> {id: 1, label: DEV} >>>>> GET /organization/ACME/environments/DEV -> {id: 1, label: DEV} >>>>> >>>>> maybe? >>>> Heh heh. I suppose labels could be used when the scope is >>>> constrained >>>> (by the organization in this case). However, I would very much >>>> prefer >>>> >>>> GET /organization/ACME/environments?label=DEV -> {id: 1, label: >>>> DEV} >>>> >>>> As it clearly shows that "DEV" is not an id, and consequently is >>>> less >>>> permanent, and the resource may or may not be there. >>>> >>>> -d >>> Params would be better. All of the following would return same >>> result: >>> >>> GET /organization/environments?label=DEV >>> GET /organization/environments?name=DEV >>> GET /organization/environments?id=1 >>> GET /organization/environments/1 >> Sure. The difference between the last two (and the last call should >> really be GET /environments/1 unless environment id is non-unique >> globally) is that: >> >> - GET /organizations/:id/environments?id=1 (or any other attribute) >> either returns a list of matching resources, or an empty list >> - GET /organizations/:id/environments/1 either returns the resource >> (singular), or a 404 >> >> In other words, the difference in semantics between "get" (the >> resource >> is expected to exist) and "find" (may or may not exist) calls. >> >> -d >> >> > So all the param-based calls would return list (or empty list), while explicit use of /$id would return single item (or 404)? That's the idea. -d From dmitri at redhat.com Tue Mar 5 16:13:23 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 05 Mar 2013 16:13:23 +0000 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <513611C0.2020206@redhat.com> References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> <5135FD11.601@redhat.com> <51360F2A.7010005@redhat.com> <513611C0.2020206@redhat.com> Message-ID: <513619A3.3080100@redhat.com> On 05/03/13 03:39 PM, Justin Sherrill wrote: > On 03/05/2013 10:28 AM, Dmitri Dolguikh wrote: >> On 05/03/13 02:52 PM, Eric D Helms wrote: >>> >>> >>> >>> On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota >>> > wrote: >>> >>> On 03/05/2013 02:29 PM, Eric D Helms wrote: >>> >>> On #2, if one of our core operating principles is that >>> nearly everything >>> is scoped based on an organization, why would we want to >>> abstract that >>> away and not make it explicit as part of resource look-up? >>> Given that a >>> design goal of RESTful APIs is to be predictable, I would >>> think the form >>> that includes organization at the trunk of the route is more >>> predictable >>> and mimics how resources are structured. >>> >>> >>> The idea was not to get rid of the resource relations. The scope >>> would still be there for collections. For example environments >>> would look like: >>> >>> crate: POST /organization/ACME/ >>> list: GET /organization/ACME/environments/ >>> show: POST /environments/1/ >>> update: PUT /environments/1/ >>> destroy: DELETE /environments/1/ >>> >>> I think of it like this: >>> I want to see what environments I have in org ACME -> I go to >>> /organization/ACME/environments/. Now I know ids of all the >>> environments I'm interested in. If I want to change it, I know >>> it's environment so I go to /environments/1/. I don't have to >>> keep in mind what org it's in. >>> When whole api behaves the same I find it predictable. >>> >>> Given that the API is another user interface, I feel that it's >>> important for all our interfaces to mimic one another in structure >>> as well as keep certain details in the forefront of users minds. In >>> the UI, most entities are scoped based on Organization and this is >>> expressed throughout the design goals. This should, in my opinion, >>> spill over into the API so that resources are predictable and mimic >>> other workflows the user will be accustomed to. Using our API, I >>> should have to actively deal with the fact that System A is a part >>> of Org X to help me understand the implications and because this is >>> a built in hierarchy that we've expressed as a guiding principle of >>> our design. >> >> API doesn't have a concept of the 'current' organization, which is >> another hint at the fact that API is used differently from UI. Using >> organizations and environments as an example, a typical flow would be: >> >> GET organizations/:id/environments >> PUT environments/:id >> >> The presence of the organization bit in the url would imply to me >> that the environment id is unique within organization only (which has >> its own consequences). As this is not the case here, organization >> information isn't merely noise, it's misleading. > > I think not having the org_id in the url makes our api much more > confusing today. For example, > > GET environments/ requires organization_id as a parameter, as does > POST environments/ > > so the user is left guessing, does this require an org_id or not? I > also think the concept of "if the environment id is unique within the > org only or not" is moot, as the user does not define the id, so why > does he care under what scope is it unique? If the id was set by the > user that might be a valid point. > > -Justin I think we are now in the subjective territory, and the conversations about what would or would not be confusing to users are speculative. In my reasoning I relied on how resources and their collections are commonly expressed. This approach shouldn't come as a surprise (perhaps worth documenting this though?). I somewhat agree re: resource ids: Ideally, any resource id should be globally unique for this resource if it was automatically generated. I don't think this is always the case in Katello (the side-effect of having "user-friendly" ids), hence the disclaimer. I disagree whether users should be aware the scope of resource ids - they should be, especially if it's atypical. -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitri at redhat.com Tue Mar 5 16:25:24 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Tue, 05 Mar 2013 16:25:24 +0000 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <51361344.2030707@redhat.com> References: <2088341628.10408942.1362498187550.JavaMail.root@redhat.com> <51361344.2030707@redhat.com> Message-ID: <51361C74.3010300@redhat.com> On 05/03/13 03:46 PM, Justin Sherrill wrote: > On 03/05/2013 10:43 AM, Tom McKay wrote: >> >> ----- Original Message ----- >>> From: "Justin Sherrill" >>> To: katello-devel at redhat.com >>> Sent: Tuesday, March 5, 2013 10:39:44 AM >>> Subject: Re: [katello-devel] API v2 - proposed changes in routes >>> >>> >>> On 03/05/2013 10:28 AM, Dmitri Dolguikh wrote: >>> >>> >>> On 05/03/13 02:52 PM, Eric D Helms wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota< >>> tstrachota at redhat.com> wrote: >>> >>> >>> >>> On 03/05/2013 02:29 PM, Eric D Helms wrote: >>> >>> >>> On #2, if one of our core operating principles is that nearly >>> everything >>> is scoped based on an organization, why would we want to abstract >>> that >>> away and not make it explicit as part of resource look-up? Given that >>> a >>> design goal of RESTful APIs is to be predictable, I would think the >>> form >>> that includes organization at the trunk of the route is more >>> predictable >>> and mimics how resources are structured. >>> >>> >>> The idea was not to get rid of the resource relations. The scope >>> would still be there for collections. For example environments would >>> look like: >>> >>> crate: POST /organization/ACME/ >>> list: GET /organization/ACME/environments/ >>> show: POST /environments/1/ >>> update: PUT /environments/1/ >>> destroy: DELETE /environments/1/ >>> >>> I think of it like this: >>> I want to see what environments I have in org ACME -> I go to >>> /organization/ACME/environments/. Now I know ids of all the >>> environments I'm interested in. If I want to change it, I know it's >>> environment so I go to /environments/1/. I don't have to keep in >>> mind what org it's in. >>> When whole api behaves the same I find it predictable. >>> >>> >>> Given that the API is another user interface, I feel that it's >>> important for all our interfaces to mimic one another in structure >>> as well as keep certain details in the forefront of users minds. In >>> the UI, most entities are scoped based on Organization and this is >>> expressed throughout the design goals. This should, in my opinion, >>> spill over into the API so that resources are predictable and mimic >>> other workflows the user will be accustomed to. Using our API, I >>> should have to actively deal with the fact that System A is a part >>> of Org X to help me understand the implications and because this is >>> a built in hierarchy that we've expressed as a guiding principle of >>> our design. >>> API doesn't have a concept of the 'current' organization, which is >>> another hint at the fact that API is used differently from UI. Using >>> organizations and environments as an example, a typical flow would >>> be: >>> >>> GET organizations/:id/environments >>> PUT environments/:id >>> >>> The presence of the organization bit in the url would imply to me >>> that the environment id is unique within organization only (which >>> has its own consequences). As this is not the case here, >>> organization information isn't merely noise, it's misleading. >>> >>> I think not having the org_id in the url makes our api much more >>> confusing today. For example, >>> >>> GET environments/ requires organization_id as a parameter, as does >>> POST environments/ >>> >> I think GET /environments/ would return _all_ environments for _all_ >> orgs. Adding ?org_id=1 would limit (as would adding ?org_label=ACME). > > And that would make sorta sense logically (although its not what we do). It is the logic we follow in API. However collection index and create operations are not available from the top-level "environments" resource, only through the "organization" parent. > > > Do we really want to list all environments across all orgs? I doubt it. > Do we want to list every/any arbitrary resource across all orgs? I doubt it. > > Especially considering names of things can be the same across orgs, > could it be confusing? We are very explicit in the UI and cli that > the user is working within a single org, do we want to break that > philosophy in the api? I pointed this out in reply to Eric: API is used differently from UI; adding organization information to the resource url carries semantic load (at least to people familiar with REST), and therefore should only be used when said relation needs to be expressed. -d From ericdhelms at gmail.com Tue Mar 5 16:37:08 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Tue, 5 Mar 2013 11:37:08 -0500 Subject: [katello-devel] Menu usability needs more work In-Reply-To: <87hakquepj.fsf@blinky.jweiss.com> References: <87hakquepj.fsf@blinky.jweiss.com> Message-ID: >From an implementation perspective, this makes sense and can be a longer term goal. I have talked to Kyle about the header and navigation in general and there is a design plan in the works, however, the delivery time will be longer than we want I believe. That being said, I have heard lots of different mentions of behaviors and requests for features but not as much concrete "here is what the menu is trying to provide for the user". There appears to be: * Site user - user that has access to cross-organization entities * Organization user - user that has access to organization specific entities * Site-Organization user - user that has access to organization specific entities and cross-organization entities * Organization Mode - when a user is managing organization specific entities * Site mode - when a user is managing cross-organization entities The question I have is -- is managing cross-organization entities a fundamentally different activity than managing organization specific entities? I think the above question drives the overall design, as it dictates the context that users need to be placed in. For example, if the answer is 'yes', then entering Organization Mode should feel like entering a different part of the application. If the answer is 'no', then entering Organization Mode should feel like just another set of screens within the application that removes the organization "context". -Eric On Tue, Mar 5, 2013 at 9:02 AM, Jeff Weiss wrote: > So far I've counted at least 4 of our own engineers who could not figure > out where the "Manage Orgs" link is. > > Here's what I propose to make the katello easier to navigate. > > * Move the Manage Orgs link to the top level, always visible (possibly > in the header, similar to where the Administer link used to be). > I think we an do this short term. > > * Maybe rename the menu link to something else. I think Tom mentioned > "Global". > > * All javascript menu. Moving between the "Manage Orgs" menu and Main > menu should not require a full page load. > > Thoughts, suggestions? > > -jeff > > -- > Jeff Weiss > Principal Quality Assurance Engineer > jweiss at redhat.com > (919)886-6533 > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tstrachota at redhat.com Tue Mar 5 17:00:09 2013 From: tstrachota at redhat.com (Tomas Strachota) Date: Tue, 05 Mar 2013 18:00:09 +0100 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <513611C0.2020206@redhat.com> References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> <5135FD11.601@redhat.com> <51360F2A.7010005@redhat.com> <513611C0.2020206@redhat.com> Message-ID: <51362499.3040105@redhat.com> On 03/05/2013 04:39 PM, Justin Sherrill wrote: > On 03/05/2013 10:28 AM, Dmitri Dolguikh wrote: >> On 05/03/13 02:52 PM, Eric D Helms wrote: >>> >>> >>> >>> On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota >>> > wrote: >>> >>> On 03/05/2013 02:29 PM, Eric D Helms wrote: >>> >>> On #2, if one of our core operating principles is that nearly >>> everything >>> is scoped based on an organization, why would we want to >>> abstract that >>> away and not make it explicit as part of resource look-up? >>> Given that a >>> design goal of RESTful APIs is to be predictable, I would >>> think the form >>> that includes organization at the trunk of the route is more >>> predictable >>> and mimics how resources are structured. >>> >>> >>> The idea was not to get rid of the resource relations. The scope >>> would still be there for collections. For example environments >>> would look like: >>> >>> crate: POST /organization/ACME/ >>> list: GET /organization/ACME/environments/ >>> show: POST /environments/1/ >>> update: PUT /environments/1/ >>> destroy: DELETE /environments/1/ >>> >>> I think of it like this: >>> I want to see what environments I have in org ACME -> I go to >>> /organization/ACME/environments/. Now I know ids of all the >>> environments I'm interested in. If I want to change it, I know >>> it's environment so I go to /environments/1/. I don't have to >>> keep in mind what org it's in. >>> When whole api behaves the same I find it predictable. >>> >>> Given that the API is another user interface, I feel that it's >>> important for all our interfaces to mimic one another in structure as >>> well as keep certain details in the forefront of users minds. In the >>> UI, most entities are scoped based on Organization and this is >>> expressed throughout the design goals. This should, in my opinion, >>> spill over into the API so that resources are predictable and mimic >>> other workflows the user will be accustomed to. Using our API, I >>> should have to actively deal with the fact that System A is a part of >>> Org X to help me understand the implications and because this is a >>> built in hierarchy that we've expressed as a guiding principle of our >>> design. >> >> API doesn't have a concept of the 'current' organization, which is >> another hint at the fact that API is used differently from UI. Using >> organizations and environments as an example, a typical flow would be: >> >> GET organizations/:id/environments >> PUT environments/:id >> >> The presence of the organization bit in the url would imply to me that >> the environment id is unique within organization only (which has its >> own consequences). As this is not the case here, organization >> information isn't merely noise, it's misleading. > > I think not having the org_id in the url makes our api much more > confusing today. For example, > > GET environments/ requires organization_id as a parameter, as does > POST environments/ > > so the user is left guessing, does this require an org_id or not? I also > think the concept of "if the environment id is unique within the org > only or not" is moot, as the user does not define the id, so why does he > care under what scope is it unique? If the id was set by the user that > might be a valid point. > I'm not sure if it was obvious but I agree with what you say here. We also try to solve this problem in the proposal. The routes I mention in the etherpad document are always tied to a method. If there is a note "Move to" it means we want to move only the named methods. The rest would stay as it is. What I find confusing today: 1) Not having ids of parent resources in the url This is what you mention above. GET and POST environments/ requires organization_id as a parameter Solution: Nest the GETs (for collection) and POSTs. In this case GET /organizations/:id/environments/ for listing envs in an org POST /organizations/:id/environments/ for creating new envs 2) Requiring two unique ids in routes I guess the problem is understood and we all just differ in opinions. Proposed solution is to get rid of the redundant ids: GET /environments/:id/ for showing a single env PUT /environments/:id/ for updates DELETE /environments/:id/ for destroy T. > -Justin > > >> >>> >>> I can understand your argument for predictability, but if I start >>> querying the collection via >>> /organization/ACME_Corporation/environments/, based on the principles >>> of REST, I would expect that I can just add an ID to the end of that >>> URL and acquire the specific resource. >> >> What principle[s] of REST do you refer to here? >> >> -d >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From bkearney at redhat.com Tue Mar 5 17:16:56 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 05 Mar 2013 12:16:56 -0500 Subject: [katello-devel] Menu usability needs more work In-Reply-To: References: <87hakquepj.fsf@blinky.jweiss.com> Message-ID: <51362888.50503@redhat.com> On 03/05/2013 11:37 AM, Eric D Helms wrote: > From an implementation perspective, this makes sense and can be a > longer term goal. > > I have talked to Kyle about the header and navigation in general and > there is a design plan in the works, however, the delivery time will be > longer than we want I believe. That being said, I have heard lots of > different mentions of behaviors and requests for features but not as > much concrete "here is what the menu is trying to provide for the user". > > > There appears to be: > > * Site user - user that has access to cross-organization entities > * Organization user - user that has access to organization specific entities > * Site-Organization user - user that has access to organization specific > entities and cross-organization entities > > * Organization Mode - when a user is managing organization specific entities > * Site mode - when a user is managing cross-organization entities > > > The question I have is -- is managing cross-organization entities a > fundamentally different activity than managing organization specific > entities? > > I think the above question drives the overall design, as it dictates the > context that users need to be placed in. For example, if the answer is > 'yes', then entering Organization Mode should feel like entering a > different part of the application. If the answer is 'no', then entering > Organization Mode should feel like just another set of screens within > the application that removes the organization "context". > > -Eric > I believe that site items are different than organization items. I assume site items to be: - Users - Roles - The org definitions. - Pulp Nodes (I know tihs is a point of disagreement) - Certificates -- bk From bkearney at redhat.com Tue Mar 5 17:23:09 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 05 Mar 2013 12:23:09 -0500 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <5135FD11.601@redhat.com> References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> <5135FD11.601@redhat.com> Message-ID: <513629FD.5010306@redhat.com> On 03/05/2013 09:11 AM, Tomas Strachota wrote: > On 03/05/2013 02:29 PM, Eric D Helms wrote: >> On #2, if one of our core operating principles is that nearly everything >> is scoped based on an organization, why would we want to abstract that >> away and not make it explicit as part of resource look-up? Given that a >> design goal of RESTful APIs is to be predictable, I would think the form >> that includes organization at the trunk of the route is more predictable >> and mimics how resources are structured. >> > > The idea was not to get rid of the resource relations. The scope would > still be there for collections. For example environments would look like: > > crate: POST /organization/ACME/ > list: GET /organization/ACME/environments/ > show: POST /environments/1/ > update: PUT /environments/1/ > destroy: DELETE /environments/1/ FWIW.. this is consistent with Candlepin. You get to a collection from its parent, but the canonical location is at /{OBJECT}/{ID} -- bk From bkearney at redhat.com Tue Mar 5 17:24:28 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 05 Mar 2013 12:24:28 -0500 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <5136144B.4000108@redhat.com> References: <1401648118.10406833.1362497864412.JavaMail.root@redhat.com> <5136144B.4000108@redhat.com> Message-ID: <51362A4C.7020603@redhat.com> On 03/05/2013 10:50 AM, Dmitri Dolguikh wrote: > On 05/03/13 03:37 PM, Tom McKay wrote: >> >> ----- Original Message ----- >>> From: "Dmitri Dolguikh" >>> To: "Tom McKay" >>> Cc: katello-devel at redhat.com >>> Sent: Tuesday, March 5, 2013 10:34:45 AM >>> Subject: Re: [katello-devel] API v2 - proposed changes in routes >>> >>> >>>>>> So we won't allow labels in the URLs, or labels would be required >>>>>> to use the deeper nesting? >>>>>> >>>>>> GET /organization/ACME/environments -> {id: 1, label: DEV} >>>>>> GET /environment/1 -> {id: 1, label: DEV} >>>>>> GET /organization/ACME/environments/DEV -> {id: 1, label: DEV} >>>>>> >>>>>> maybe? >>>>> Heh heh. I suppose labels could be used when the scope is >>>>> constrained >>>>> (by the organization in this case). However, I would very much >>>>> prefer >>>>> >>>>> GET /organization/ACME/environments?label=DEV -> {id: 1, label: >>>>> DEV} >>>>> >>>>> As it clearly shows that "DEV" is not an id, and consequently is >>>>> less >>>>> permanent, and the resource may or may not be there. >>>>> >>>>> -d >>>> Params would be better. All of the following would return same >>>> result: >>>> >>>> GET /organization/environments?label=DEV >>>> GET /organization/environments?name=DEV >>>> GET /organization/environments?id=1 >>>> GET /organization/environments/1 >>> Sure. The difference between the last two (and the last call should >>> really be GET /environments/1 unless environment id is non-unique >>> globally) is that: >>> >>> - GET /organizations/:id/environments?id=1 (or any other attribute) >>> either returns a list of matching resources, or an empty list >>> - GET /organizations/:id/environments/1 either returns the resource >>> (singular), or a 404 >>> >>> In other words, the difference in semantics between "get" (the >>> resource >>> is expected to exist) and "find" (may or may not exist) calls. >>> >>> -d >>> >>> >> So all the param-based calls would return list (or empty list), while >> explicit use of /$id would return single item (or 404)? > That's the idea. > -d +1 -- bk From bkearney at redhat.com Tue Mar 5 17:26:31 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 05 Mar 2013 12:26:31 -0500 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: References: <5135EBB7.808@redhat.com> <87k3pmugm7.fsf@blinky.jweiss.com> <5135FD11.601@redhat.com> Message-ID: <51362AC7.2020308@redhat.com> On 03/05/2013 09:52 AM, Eric D Helms wrote: > > > > On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota > wrote: > > On 03/05/2013 02:29 PM, Eric D Helms wrote: > > On #2, if one of our core operating principles is that nearly > everything > is scoped based on an organization, why would we want to > abstract that > away and not make it explicit as part of resource look-up? > Given that a > design goal of RESTful APIs is to be predictable, I would think > the form > that includes organization at the trunk of the route is more > predictable > and mimics how resources are structured. > > > The idea was not to get rid of the resource relations. The scope > would still be there for collections. For example environments would > look like: > > crate: POST /organization/ACME/ > list: GET /organization/ACME/__environments/ > show: POST /environments/1/ > update: PUT /environments/1/ > destroy: DELETE /environments/1/ > > I think of it like this: > I want to see what environments I have in org ACME -> I go to > /organization/ACME/__environments/. Now I know ids of all the > environments I'm interested in. If I want to change it, I know it's > environment so I go to /environments/1/. I don't have to keep in > mind what org it's in. > When whole api behaves the same I find it predictable. > > Given that the API is another user interface, I feel that it's important > for all our interfaces to mimic one another in structure as well as keep > certain details in the forefront of users minds. In the UI, most > entities are scoped based on Organization and this is expressed > throughout the design goals. This should, in my opinion, spill over > into the API so that resources are predictable and mimic other workflows > the user will be accustomed to. Using our API, I should have to > actively deal with the fact that System A is a part of Org X to help me > understand the implications and because this is a built in hierarchy > that we've expressed as a guiding principle of our design. > > I can understand your argument for predictability, but if I start > querying the collection via > /organization/ACME_Corporation/environments/, based on the principles of > REST, I would expect that I can just add an ID to the end of that URL > and acquire the specific resource. I think the API should have all actions available to it, but I dont know if it should mimic the UI. If user create is in /admin today i dont think the api should be: /admin/users it should just be /users -- bk From bkearney at redhat.com Tue Mar 5 17:26:46 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 05 Mar 2013 12:26:46 -0500 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <2088341628.10408942.1362498187550.JavaMail.root@redhat.com> References: <2088341628.10408942.1362498187550.JavaMail.root@redhat.com> Message-ID: <51362AD6.6070700@redhat.com> On 03/05/2013 10:43 AM, Tom McKay wrote: > I think GET/environments/ would return_all_ environments for_all_ orgs. Adding ?org_id=1 would limit (as would adding ?org_label=ACME). All those you have permission to see. -- bk From tstrachota at redhat.com Tue Mar 5 17:34:14 2013 From: tstrachota at redhat.com (Tomas Strachota) Date: Tue, 05 Mar 2013 18:34:14 +0100 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <51361C74.3010300@redhat.com> References: <2088341628.10408942.1362498187550.JavaMail.root@redhat.com> <51361344.2030707@redhat.com> <51361C74.3010300@redhat.com> Message-ID: <51362C96.6090508@redhat.com> On 03/05/2013 05:25 PM, Dmitri Dolguikh wrote: > On 05/03/13 03:46 PM, Justin Sherrill wrote: >> On 03/05/2013 10:43 AM, Tom McKay wrote: >>> >>> ----- Original Message ----- >>>> From: "Justin Sherrill" >>>> To: katello-devel at redhat.com >>>> Sent: Tuesday, March 5, 2013 10:39:44 AM >>>> Subject: Re: [katello-devel] API v2 - proposed changes in routes >>>> >>>> >>>> On 03/05/2013 10:28 AM, Dmitri Dolguikh wrote: >>>> >>>> >>>> On 05/03/13 02:52 PM, Eric D Helms wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota< >>>> tstrachota at redhat.com> wrote: >>>> >>>> >>>> >>>> On 03/05/2013 02:29 PM, Eric D Helms wrote: >>>> >>>> >>>> On #2, if one of our core operating principles is that nearly >>>> everything >>>> is scoped based on an organization, why would we want to abstract >>>> that >>>> away and not make it explicit as part of resource look-up? Given that >>>> a >>>> design goal of RESTful APIs is to be predictable, I would think the >>>> form >>>> that includes organization at the trunk of the route is more >>>> predictable >>>> and mimics how resources are structured. >>>> >>>> >>>> The idea was not to get rid of the resource relations. The scope >>>> would still be there for collections. For example environments would >>>> look like: >>>> >>>> crate: POST /organization/ACME/ >>>> list: GET /organization/ACME/environments/ >>>> show: POST /environments/1/ >>>> update: PUT /environments/1/ >>>> destroy: DELETE /environments/1/ >>>> >>>> I think of it like this: >>>> I want to see what environments I have in org ACME -> I go to >>>> /organization/ACME/environments/. Now I know ids of all the >>>> environments I'm interested in. If I want to change it, I know it's >>>> environment so I go to /environments/1/. I don't have to keep in >>>> mind what org it's in. >>>> When whole api behaves the same I find it predictable. >>>> >>>> >>>> Given that the API is another user interface, I feel that it's >>>> important for all our interfaces to mimic one another in structure >>>> as well as keep certain details in the forefront of users minds. In >>>> the UI, most entities are scoped based on Organization and this is >>>> expressed throughout the design goals. This should, in my opinion, >>>> spill over into the API so that resources are predictable and mimic >>>> other workflows the user will be accustomed to. Using our API, I >>>> should have to actively deal with the fact that System A is a part >>>> of Org X to help me understand the implications and because this is >>>> a built in hierarchy that we've expressed as a guiding principle of >>>> our design. >>>> API doesn't have a concept of the 'current' organization, which is >>>> another hint at the fact that API is used differently from UI. Using >>>> organizations and environments as an example, a typical flow would >>>> be: >>>> >>>> GET organizations/:id/environments >>>> PUT environments/:id >>>> >>>> The presence of the organization bit in the url would imply to me >>>> that the environment id is unique within organization only (which >>>> has its own consequences). As this is not the case here, >>>> organization information isn't merely noise, it's misleading. >>>> >>>> I think not having the org_id in the url makes our api much more >>>> confusing today. For example, >>>> >>>> GET environments/ requires organization_id as a parameter, as does >>>> POST environments/ >>>> >>> I think GET /environments/ would return _all_ environments for _all_ >>> orgs. Adding ?org_id=1 would limit (as would adding ?org_label=ACME). >> >> And that would make sorta sense logically (although its not what we do). > > It is the logic we follow in API. However collection index and create > operations are not available from the top-level "environments" resource, > only through the "organization" parent. > >> >> >> Do we really want to list all environments across all orgs? > > I doubt it. > > >> Do we want to list every/any arbitrary resource across all orgs? > > I doubt it. > >> >> Especially considering names of things can be the same across orgs, >> could it be confusing? We are very explicit in the UI and cli that >> the user is working within a single org, do we want to break that >> philosophy in the api? > I don't see it as breaking the philosophy. We actually want to emphasize that we're working within an org by removing all routes that list the resources globally (eg. get /systems, get /envs). I understand your concerns about the intuitiveness for users. In my opinion, removing redundant unique ids would make potential api bindings simpler (eg. our cli python bindings) and more intuitive from coder's point of view. Do you think it would help users if we added links to resources into our json responses? Something like get on /organizations/:id/environments would return [{ environment: { ... }, links: [{ name: show, href: /environments/:id/ }] }] T. > I pointed this out in reply to Eric: API is used differently from UI; > adding organization information to the resource url carries semantic > load (at least to people familiar with REST), and therefore should only > be used when said relation needs to be expressed. > > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From tstrachota at redhat.com Tue Mar 5 17:39:14 2013 From: tstrachota at redhat.com (Tomas Strachota) Date: Tue, 05 Mar 2013 18:39:14 +0100 Subject: [katello-devel] API v2 - proposed changes in routes In-Reply-To: <51362C96.6090508@redhat.com> References: <2088341628.10408942.1362498187550.JavaMail.root@redhat.com> <51361344.2030707@redhat.com> <51361C74.3010300@redhat.com> <51362C96.6090508@redhat.com> Message-ID: <51362DC2.3060100@redhat.com> On 03/05/2013 06:34 PM, Tomas Strachota wrote: > On 03/05/2013 05:25 PM, Dmitri Dolguikh wrote: >> On 05/03/13 03:46 PM, Justin Sherrill wrote: >>> On 03/05/2013 10:43 AM, Tom McKay wrote: >>>> >>>> ----- Original Message ----- >>>>> From: "Justin Sherrill" >>>>> To: katello-devel at redhat.com >>>>> Sent: Tuesday, March 5, 2013 10:39:44 AM >>>>> Subject: Re: [katello-devel] API v2 - proposed changes in routes >>>>> >>>>> >>>>> On 03/05/2013 10:28 AM, Dmitri Dolguikh wrote: >>>>> >>>>> >>>>> On 05/03/13 02:52 PM, Eric D Helms wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Mar 5, 2013 at 9:11 AM, Tomas Strachota< >>>>> tstrachota at redhat.com> wrote: >>>>> >>>>> >>>>> >>>>> On 03/05/2013 02:29 PM, Eric D Helms wrote: >>>>> >>>>> >>>>> On #2, if one of our core operating principles is that nearly >>>>> everything >>>>> is scoped based on an organization, why would we want to abstract >>>>> that >>>>> away and not make it explicit as part of resource look-up? Given that >>>>> a >>>>> design goal of RESTful APIs is to be predictable, I would think the >>>>> form >>>>> that includes organization at the trunk of the route is more >>>>> predictable >>>>> and mimics how resources are structured. >>>>> >>>>> >>>>> The idea was not to get rid of the resource relations. The scope >>>>> would still be there for collections. For example environments would >>>>> look like: >>>>> >>>>> crate: POST /organization/ACME/ >>>>> list: GET /organization/ACME/environments/ >>>>> show: POST /environments/1/ >>>>> update: PUT /environments/1/ >>>>> destroy: DELETE /environments/1/ >>>>> >>>>> I think of it like this: >>>>> I want to see what environments I have in org ACME -> I go to >>>>> /organization/ACME/environments/. Now I know ids of all the >>>>> environments I'm interested in. If I want to change it, I know it's >>>>> environment so I go to /environments/1/. I don't have to keep in >>>>> mind what org it's in. >>>>> When whole api behaves the same I find it predictable. >>>>> >>>>> >>>>> Given that the API is another user interface, I feel that it's >>>>> important for all our interfaces to mimic one another in structure >>>>> as well as keep certain details in the forefront of users minds. In >>>>> the UI, most entities are scoped based on Organization and this is >>>>> expressed throughout the design goals. This should, in my opinion, >>>>> spill over into the API so that resources are predictable and mimic >>>>> other workflows the user will be accustomed to. Using our API, I >>>>> should have to actively deal with the fact that System A is a part >>>>> of Org X to help me understand the implications and because this is >>>>> a built in hierarchy that we've expressed as a guiding principle of >>>>> our design. >>>>> API doesn't have a concept of the 'current' organization, which is >>>>> another hint at the fact that API is used differently from UI. Using >>>>> organizations and environments as an example, a typical flow would >>>>> be: >>>>> >>>>> GET organizations/:id/environments >>>>> PUT environments/:id >>>>> >>>>> The presence of the organization bit in the url would imply to me >>>>> that the environment id is unique within organization only (which >>>>> has its own consequences). As this is not the case here, >>>>> organization information isn't merely noise, it's misleading. >>>>> >>>>> I think not having the org_id in the url makes our api much more >>>>> confusing today. For example, >>>>> >>>>> GET environments/ requires organization_id as a parameter, as does >>>>> POST environments/ >>>>> >>>> I think GET /environments/ would return _all_ environments for _all_ >>>> orgs. Adding ?org_id=1 would limit (as would adding ?org_label=ACME). >>> >>> And that would make sorta sense logically (although its not what we do). >> >> It is the logic we follow in API. However collection index and create >> operations are not available from the top-level "environments" resource, >> only through the "organization" parent. >> >>> >>> >>> Do we really want to list all environments across all orgs? >> >> I doubt it. >> >> >>> Do we want to list every/any arbitrary resource across all orgs? >> >> I doubt it. >> >>> >>> Especially considering names of things can be the same across orgs, >>> could it be confusing? We are very explicit in the UI and cli that >>> the user is working within a single org, do we want to break that >>> philosophy in the api? >> > > I don't see it as breaking the philosophy. We actually want to emphasize > that we're working within an org by removing all routes that list the > resources globally (eg. get /systems, get /envs). > > I understand your concerns about the intuitiveness for users. > In my opinion, removing redundant unique ids would make potential api > bindings simpler (eg. our cli python bindings) and more intuitive from > coder's point of view. > Do you think it would help users if we added links to resources into our > json responses? Something like get on /organizations/:id/environments > would return > [{ > environment: { > ... > }, > links: [{ > name: show, > href: /environments/:id/ > }] > }] > Sorry, I meant ... href: /environments/1/ ... No intention to do any kind of templating in the urls. > T. > >> I pointed this out in reply to Eric: API is used differently from UI; >> adding organization information to the resource url carries semantic >> load (at least to people familiar with REST), and therefore should only >> be used when said relation needs to be expressed. >> >> -d >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From kybaker at redhat.com Tue Mar 5 18:18:06 2013 From: kybaker at redhat.com (Kyle Baker) Date: Tue, 5 Mar 2013 13:18:06 -0500 (EST) Subject: [katello-devel] Menu usability needs more work In-Reply-To: <51362888.50503@redhat.com> Message-ID: <905629878.9596272.1362507486654.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/05/2013 11:37 AM, Eric D Helms wrote: > > From an implementation perspective, this makes sense and can be a > > longer term goal. > > > > I have talked to Kyle about the header and navigation in general > > and > > there is a design plan in the works, however, the delivery time > > will be > > longer than we want I believe. That being said, I have heard lots > > of > > different mentions of behaviors and requests for features but not > > as > > much concrete "here is what the menu is trying to provide for the > > user". This design plan is related to branding and 'shell' design visuals. This is unrelated to Katello specific content such as navigation or the org switcher. > > > > > > There appears to be: > > > > * Site user - user that has access to cross-organization entities > > * Organization user - user that has access to organization specific > > entities > > * Site-Organization user - user that has access to organization > > specific > > entities and cross-organization entities > > > > * Organization Mode - when a user is managing organization specific > > entities > > * Site mode - when a user is managing cross-organization entities > > > > > > The question I have is -- is managing cross-organization entities a > > fundamentally different activity than managing organization > > specific > > entities? > > > > I think the above question drives the overall design, as it > > dictates the > > context that users need to be placed in. For example, if the > > answer is > > 'yes', then entering Organization Mode should feel like entering a > > different part of the application. If the answer is 'no', then > > entering > > Organization Mode should feel like just another set of screens > > within > > the application that removes the organization "context". > > > > -Eric > > > > I believe that site items are different than organization items. I > assume site items to be: > > - Users > - Roles > - The org definitions. > - Pulp Nodes (I know tihs is a point of disagreement) > - Certificates This is where the confusion occurs. We have chose to display all of the content on the page within the context of an org. If we are displaying content(users, roles, org lists) which are cross org, we can not do it under the heading of the org context as we were. I think the real issue with the last org changes that were merged is discover-ability and accessibility of content. I will take it as an action item to address these issues in with new mockups. > > -- bk > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From thomasmckay at redhat.com Tue Mar 5 22:24:17 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 5 Mar 2013 17:24:17 -0500 (EST) Subject: [katello-devel] failed travis on 1.8.7, green on 1.9.3 In-Reply-To: <1896275105.10569469.1362522158956.JavaMail.root@redhat.com> Message-ID: <91099294.10570036.1362522257437.JavaMail.root@redhat.com> https://travis-ci.org/thomasmckay/katello/builds/5257001 /home/travis/.rvm/gems/ruby-1.8.7-p371/gems/activerecord-3.0.10/lib/active_record/base.rb:1014:in `method_missing': undefined method `use_index_of' for # (NoMethodError) from /home/travis/build/thomasmckay/katello/src/app/models/hypervisor.rb:14 class Hypervisor < System use_index_of System <-- line 14 Any idea why this would be a problem just on 1.8.7? From mhulan at redhat.com Wed Mar 6 15:02:35 2013 From: mhulan at redhat.com (Marek Hulan) Date: Wed, 06 Mar 2013 16:02:35 +0100 Subject: [katello-devel] Design of SSO - screencast In-Reply-To: <7746013.7pGRmRLpPz@edna> References: <1474616007.9805072.1362403072693.JavaMail.root@redhat.com> <5134D28C.2060308@redhat.com> <7746013.7pGRmRLpPz@edna> Message-ID: <2624882.olzb1c1klo@edna> Hey all I just finished a short screencast about SSO design spike I worked on recently. You can find on youtube http://www.youtube.com/watch?v=4Ov771INMns Comments or questions are welcome -- Marek From bkearney at redhat.com Wed Mar 6 20:06:08 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 06 Mar 2013 15:06:08 -0500 Subject: [katello-devel] anyone have gettext testing fu? Message-ID: <5137A1B0.6020807@redhat.com> Has anyone triend monkey patching _() (or somethinkg like that) to test that all strings on a page a localized? I would like to avoid having to regen the strings file all the time. -- bk From lzap at redhat.com Thu Mar 7 10:13:48 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 7 Mar 2013 11:13:48 +0100 Subject: [katello-devel] anyone have gettext testing fu? In-Reply-To: <5137A1B0.6020807@redhat.com> References: <5137A1B0.6020807@redhat.com> Message-ID: <20130307101348.GE1757@lzapx.brq.redhat.com> > Has anyone triend monkey patching _() (or somethinkg like that) to > test that all strings on a page a localized? I would like to avoid > having to regen the strings file all the time. What? :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Thu Mar 7 11:15:50 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 7 Mar 2013 12:15:50 +0100 Subject: [katello-devel] [WORKAROUND] Issues with Fedora 18 and our Koji Message-ID: <20130307111550.GF1757@lzapx.brq.redhat.com> Hey, for the past four days, I was experiencing problems with our Koji. My client was timeouting way to often and sometimes it was not possible to upload a bigger RPM into our Koji at all. So I made a small research and with some help from guys at #koji channel, I finally found a workaround. WARNING: Latest openssl package breaks koji client in Fedora 18. It is possible if your connection speed is fast enough, you will not encounter these issues. My uplink apparently sucks. The workaround - use older version of openssl: sudo rpm -Uvh --force "http://kojipkgs.fedoraproject.org//packages/openssl/1.0.1c/7.fc18/x86_64/openssl-1.0.1c-7.fc18.x86_64.rpm" "http://kojipkgs.fedoraproject.org//packages/openssl/1.0.1c/7.fc18/x86_64/openssl-libs-1.0.1c-7.fc18.x86_64.rpm" "http://kojipkgs.fedoraproject.org//packages/openssl/1.0.1c/7.fc18/x86_64/openssl-devel-1.0.1c-7.fc18.x86_64.rpm" I have filled very rich bug report and hopefully this gets fixed soon: https://bugzilla.redhat.com/show_bug.cgi?id=918995 This was driving me crazy last couple of days. Also it was literally blocking me from any Koji work. Now I am back on track. -- Later, Lukas "lzap" Zapletal #katello #systemengine From thomasmckay at redhat.com Thu Mar 7 13:17:43 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 7 Mar 2013 08:17:43 -0500 (EST) Subject: [katello-devel] failed travis on 1.8.7, green on 1.9.3 In-Reply-To: <91099294.10570036.1362522257437.JavaMail.root@redhat.com> Message-ID: <1855221929.11447796.1362662263149.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Tom McKay" > To: "katello-devel" > Sent: Tuesday, March 5, 2013 5:24:17 PM > Subject: failed travis on 1.8.7, green on 1.9.3 > > https://travis-ci.org/thomasmckay/katello/builds/5257001 > > /home/travis/.rvm/gems/ruby-1.8.7-p371/gems/activerecord-3.0.10/lib/active_record/base.rb:1014:in > `method_missing': undefined method `use_index_of' for > # (NoMethodError) > from > /home/travis/build/thomasmckay/katello/src/app/models/hypervisor.rb:14 > > class Hypervisor < System > use_index_of System <-- line 14 > > > Any idea why this would be a problem just on 1.8.7? The missing use_index_of was a result of incorrectly defaulting use_elasticsearch to false. (Thanks Jordan for pointing me in the correct direction!) From bkearney at redhat.com Thu Mar 7 16:13:23 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 07 Mar 2013 11:13:23 -0500 Subject: [katello-devel] anyone have gettext testing fu? In-Reply-To: <20130307101348.GE1757@lzapx.brq.redhat.com> References: <5137A1B0.6020807@redhat.com> <20130307101348.GE1757@lzapx.brq.redhat.com> Message-ID: <5138BCA3.10208@redhat.com> On 03/07/2013 05:13 AM, Lukas Zapletal wrote: >> Has anyone triend monkey patching _() (or somethinkg like that) to >> test that all strings on a page a localized? I would like to avoid >> having to regen the strings file all the time. > > What? :-) > My real goal is to help with ensuring that all strings on a page are translated during development. I was hoping to alias the _() method so that it returns the string wiht: X{THE ORIGINAL STRING }X so that I could look at a page to know if anything was missed. Once the strings are extracted and trasnlated, it is easy to do by switching languages. -- bk From lzap at redhat.com Thu Mar 7 17:00:07 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Thu, 7 Mar 2013 18:00:07 +0100 Subject: [katello-devel] Purpose of katello and katello-common packages Message-ID: <20130307170007.GL1757@lzapx.brq.redhat.com> Hey, today I noticed we deliver some shared bits in two packages: katello katello-common It looks like both holds files that are common for both katello and headpin. Why do we split these? LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From mbacovsk at redhat.com Thu Mar 7 16:46:29 2013 From: mbacovsk at redhat.com (Martin Bacovsky) Date: Thu, 07 Mar 2013 17:46:29 +0100 Subject: [katello-devel] API V2 format changes Message-ID: <5138C465.7080807@redhat.com> We (Tomas and Martin) are working on API redesign and cleanup. The motivation for this is that the practices are not consistent in current API which makes UX not pleasant and is causing difficulties while creating CLI. In the future it could be possible to autogenerate python bindings for Katello and/or parts of the CLI. Current state * nesting of elements is not consistent * when use of as_json the representation of entities is distributed over the code * some results render as text instead of JSON Our goals: * make the transition as simple as possible * use RABL for JSON output definition * make responses consistent * unify error handling * make it easy to change the output behaviour from one place There are some decision that needs to be done. We are looking for opinions on following things: Support messages in 2XX responses? e.g. 'message: "Environment was successfully deleted"' Pagination handeling * support in every GET that returns collection or just where it make sense? * suggested format /api/organizations//environments/?page=2&items_per_page=20 * Should result contain item count, offset, items per page? POST * return 201 or 200? * return URI or entitiy in body? PUT * return entity or empty body? JSON conventions for V2 as we would prefer them to be, but is subject to changes according to comments on questions s above GET * returns either entity or list of entities * pagination supported where it makes sense, no extra information in paginated response, add methods entities_count or similar * all entities have root POST * 201 * return entity in body, URI in Location PUT * 200 * entity in body DELETE * 200 * empty body No messages in 2XX responses. (status of the action is told by the code, passing it to the user should be responsibility of client app) Work shown in the pull request (https://github.com/Katello/katello/pull/1714) should demonstrate the desired state of things after our mission is completed. We choosed environments as a suitable sample controller: V1 refactoring to minimize changes in controllers in V2 and to avoid support of two sets of controllers as much as possible * isolated output handling to set of methods, taht could be changed in the next version without need to touch the controllers * keep the V1 behavior unchanged is priority * change inheritance of the controllers to allow inherit V2 controllers from the V1 ones while adding V2 specific behaviour from module V2 * added RABL templates TODO * handeling of errors in V2 * pagination support Comments are welcome, Martin From jweiss at redhat.com Thu Mar 7 17:42:25 2013 From: jweiss at redhat.com (Jeff Weiss) Date: Thu, 07 Mar 2013 12:42:25 -0500 Subject: [katello-devel] API V2 format changes In-Reply-To: <5138C465.7080807@redhat.com> References: <5138C465.7080807@redhat.com> Message-ID: <87boavjeda.fsf@blinky.jweiss.com> Martin Bacovsky writes: > We (Tomas and Martin) are working on API redesign and cleanup. The > motivation for this is that the practices are not consistent in current > API which makes UX not pleasant and is causing difficulties while > creating CLI. In the future it could be possible to autogenerate python > bindings for Katello and/or parts of the CLI. > > Current state > * nesting of elements is not consistent > * when use of as_json the representation of entities is distributed > over the code > * some results render as text instead of JSON > > Our goals: > * make the transition as simple as possible > * use RABL for JSON output definition > * make responses consistent > * unify error handling > * make it easy to change the output behaviour from one place > > There are some decision that needs to be done. We are looking for > opinions on following things: > > Support messages in 2XX responses? e.g. 'message: "Environment was > successfully deleted"' > > Pagination handeling > * support in every GET that returns collection or just where it > make sense? > * suggested format > /api/organizations//environments/?page=2&items_per_page=20 > * Should result contain item count, offset, items per page? > > POST > * return 201 or 200? > * return URI or entitiy in body? > > PUT > * return entity or empty body? > > JSON conventions for V2 as we would prefer them to be, but is subject to > changes according to comments on questions s above > > GET > * returns either entity or list of entities > * pagination supported where it makes sense, no extra information > in paginated response, add methods entities_count or similar > * all entities have root > > POST > * 201 > * return entity in body, URI in Location > > PUT > * 200 > * entity in body > > DELETE > * 200 > * empty body > > No messages in 2XX responses. (status of the action is told by the > code, passing it to the user should be responsibility of client app) > > > Work shown in the pull request > (https://github.com/Katello/katello/pull/1714) should demonstrate the > desired state of things after our mission is completed. We choosed > environments as a suitable sample controller: > > V1 refactoring to minimize changes in controllers in V2 and to > avoid support of two sets of controllers as much as possible > * isolated output handling to set of methods, taht could be changed > in the next version without need to touch the controllers > * keep the V1 behavior unchanged is priority > * change inheritance of the controllers to allow inherit V2 > controllers from the V1 ones while adding V2 specific behaviour from module > > V2 > * added RABL templates > > TODO > * handeling of errors in V2 > * pagination support > > Comments are welcome, > Martin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Sounds great! I have some opinions on a couple of items: * Support messages in 2XX responses? No, unless there's something to be conveyed, beyond "the operation succeeded". The success should be evident by the response code right? That's a lot easier to check than an english string. * Return entities in the body? I'd at least want the ability to do this, it makes it easier to sync the client's representation of the entity if you get the whole thing back. I'd say make it an option in the request, but if it hurts performance (and it probably will), leave it off by default. * Pagination - If the caller can freely set the items per page and page number, just let him specify the range of items he wants: /api/organizations//environments/?range=40-60 (last is exclusive here). No need to return any pagination or range information in the response, AFAICT, since the caller knows it already. eg, he requests ?range=40-60 and there are only 47 items, he knows he's getting items 40-47 by counting the items. I'm not sure what the REST way of saying we're past the end of the list? either empty list or 404 i guess. -Jeff -- Jeff Weiss Principal Quality Assurance Engineer jweiss at redhat.com (919)886-6533 From bkearney at redhat.com Thu Mar 7 19:10:46 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 07 Mar 2013 14:10:46 -0500 Subject: [katello-devel] anyone have gettext testing fu? In-Reply-To: <5138BCA3.10208@redhat.com> References: <5137A1B0.6020807@redhat.com> <20130307101348.GE1757@lzapx.brq.redhat.com> <5138BCA3.10208@redhat.com> Message-ID: <5138E636.8020806@redhat.com> On 03/07/2013 11:13 AM, Bryan Kearney wrote: > On 03/07/2013 05:13 AM, Lukas Zapletal wrote: >>> Has anyone triend monkey patching _() (or somethinkg like that) to >>> test that all strings on a page a localized? I would like to avoid >>> having to regen the strings file all the time. >> >> What? :-) >> > My real goal is to help with ensuring that all strings on a page are > translated during development. I was hoping to alias the _() method so > that it returns the string wiht: > > X{THE ORIGINAL STRING }X > > so that I could look at a page to know if anything was missed. Once the > strings are extracted and trasnlated, it is easy to do by switching > languages. > > -- bk > ok.. found it.. add this to your fastgettext initializer in module FastGettext module Translation alias :old_ :_ def _(key) "X" + old_(key) + "X" end end end -- bk From lzap at redhat.com Fri Mar 8 08:59:01 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 8 Mar 2013 09:59:01 +0100 Subject: [katello-devel] API V2 format changes In-Reply-To: <87boavjeda.fsf@blinky.jweiss.com> References: <5138C465.7080807@redhat.com> <87boavjeda.fsf@blinky.jweiss.com> Message-ID: <20130308085901.GB1730@lzapx.brq.redhat.com> On Thu, Mar 07, 2013 at 12:42:25PM -0500, Jeff Weiss wrote: > * Support messages in 2XX responses? No, unless there's something to be > conveyed, beyond "the operation succeeded". The success should be > evident by the response code right? That's a lot easier to check than > an english string. Well I think the motivation is not to force clients to check the message, you can ignore it. The thing is we are able to hand over this information in the cli client directly. So you could do something like: if response.code == 200 then print response.message -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Fri Mar 8 09:00:48 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 8 Mar 2013 10:00:48 +0100 Subject: [katello-devel] API V2 format changes In-Reply-To: <5138C465.7080807@redhat.com> References: <5138C465.7080807@redhat.com> Message-ID: <20130308090048.GC1730@lzapx.brq.redhat.com> On Thu, Mar 07, 2013 at 05:46:29PM +0100, Martin Bacovsky wrote: > V2 > * added RABL templates Whatever you add, I insist on a deep dive about the new technology, maybe some comparisons with other stacks ;-) Nice work! -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Fri Mar 8 11:55:17 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 08 Mar 2013 11:55:17 +0000 Subject: [katello-devel] API V2 format changes In-Reply-To: <5138C465.7080807@redhat.com> References: <5138C465.7080807@redhat.com> Message-ID: <5139D1A5.5020502@redhat.com> On 07/03/13 04:46 PM, Martin Bacovsky wrote: > We (Tomas and Martin) are working on API redesign and cleanup. The > motivation for this is that the practices are not consistent in > current API which makes UX not pleasant and is causing difficulties > while creating CLI. In the future it could be possible to autogenerate > python bindings for Katello and/or parts of the CLI. > > Current state > * nesting of elements is not consistent > * when use of as_json the representation of entities is > distributed over the code > * some results render as text instead of JSON > > Our goals: > * make the transition as simple as possible > * use RABL for JSON output definition > * make responses consistent > * unify error handling > * make it easy to change the output behaviour from one place > > There are some decision that needs to be done. We are looking for > opinions on following things: > > Support messages in 2XX responses? e.g. 'message: "Environment was > successfully deleted"' I think messages are redundant: the client knows the resource it's accessing, the operation, and can figure out the result based on the status code. > > Pagination handeling > * support in every GET that returns collection or just where it > make sense? > * suggested format > /api/organizations//environments/?page=2&items_per_page=20 > * Should result contain item count, offset, items per page? Depends. I think it's wrong to introduce offset and items per page in the resource (these reflect iterator/cursor state and should be modelled accordingly). Including a hyper-link to retrieve the next x items would be ok though. > > > POST > * return 201 or 200? > * return URI or entitiy in body? I think either 200 or 201 would be ok (201 is more specific though). The main difference between these is that 200 contains the resource itself, while 201 only the URI and some metadata. In a lot of cases we are actually interested in the created entity, so a 200 response makes the life a bit easier. > > > PUT > * return entity or empty body? 204 sounds appealing... > > JSON conventions for V2 as we would prefer them to be, but is subject > to changes according to comments on questions s above > > GET > * returns either entity or list of entities > * pagination supported where it makes sense, no extra information > in paginated response, add methods entities_count or similar > * all entities have root > > POST > * 201 > * return entity in body, URI in Location According to the spec it's either 200 + entity or 201 + URI. My vote goes for 200. > > PUT > * 200 > * entity in body > > DELETE > * 200 > * empty body Perhaps 204 or 205 would be better? Empty body by definition. I think semantically 205 is more appropriate... > > No messages in 2XX responses. (status of the action is told by the > code, passing it to the user should be responsibility of client app) > > > Work shown in the pull request > (https://github.com/Katello/katello/pull/1714) should demonstrate the > desired state of things after our mission is completed. We choosed > environments as a suitable sample controller: > > V1 refactoring to minimize changes in controllers in V2 and to > avoid support of two sets of controllers as much as possible > * isolated output handling to set of methods, taht could be > changed in the next version without need to touch the controllers > * keep the V1 behavior unchanged is priority > * change inheritance of the controllers to allow inherit V2 > controllers from the V1 ones while adding V2 specific behaviour from > module > > V2 > * added RABL templates YEAY!!!!!!!!!!!!!!!!!! > > > TODO > * handeling of errors in V2 > * pagination support > > Comments are welcome, > Martin -d From lzap at redhat.com Fri Mar 8 12:02:04 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 8 Mar 2013 13:02:04 +0100 Subject: [katello-devel] State of R19R and Katello Message-ID: <20130308120204.GF1730@lzapx.brq.redhat.com> Ok, first of all I am **tired** of writing ruby193-rubygem after this week. Therefore R19R = Ruby 1.9.3 Rails stack (SCL). So, yesterday I finally reach the point when Katello actually starts starting (uh) and fails due to old version of haml. Currently I am building some nokogiri rubygem dependencies and this is the last Katello dependency that prevents it from starting. It is good progress, it means we have all the dependencies that are required for the runtime (without katello-devel* packages). At this point, more folks are able to start testing Katello on R19R. If you want to try Katello on R19R stack today, you need to ping me (I will generate fresh repo for you), then you need to comment out "anemone" rubygem (nokogiri not yet built - hard one) and then you need to do this: # yum -y install ruby193* # cd /usr/share/katello # RAILS_ENV=production scl enable ruby193 "rails s" Btw if you try that you will see haml error - I am still building new rubygem-haml which unfortunately needs bunch of new dependencies (with native extensions of course). Feel free to hack with it. In the thirdparty repo, we have two new scripts: import-fedora - pulls a package from fedora 18 git, unpacks, clears .git directory, adds to thirdparty, tags, adds to koji and submits to koji. import-ruby193-fedora - the same but it will do SCL conversion and blacklist the package for non-RHEL6 platforms I made these scripts so we can quickly adopt rubygems from Fedora 18 branch (we can't use master for some gems because there are new macros we dont have yet). Oh FYI to speedup the process I have turned off automatic repogeneration which slows down Koji a lot. I will turn it on again 5 PM CET. If you need nightly today, ping me and I will generate it for you. I think I hate writing R19R too on Czech keyboard layout :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From dmitri at redhat.com Fri Mar 8 15:29:49 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 08 Mar 2013 15:29:49 +0000 Subject: [katello-devel] Rspec and/or mini-test? Message-ID: <513A03ED.4090601@redhat.com> We found ourselves in a situation where we use two rather different testing frameworks: rspec and mini-test. Should we migrate to mini-test only? How should we do it? One approach could be not adding any new tests into rspec, and migrate existing rspec tests one-by-one into mini-test. Should we decide to stay with both, I think making factory_girl factories accessible under both suites would be important, as well as updating rspec tests to use the factories... Thoughts/opinions? -d From lzap at redhat.com Fri Mar 8 15:35:44 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 8 Mar 2013 16:35:44 +0100 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <513A03ED.4090601@redhat.com> References: <513A03ED.4090601@redhat.com> Message-ID: <20130308153544.GG1730@lzapx.brq.redhat.com> On Fri, Mar 08, 2013 at 03:29:49PM +0000, Dmitri Dolguikh wrote: > We found ourselves in a situation where we use two rather different > testing frameworks: rspec and mini-test. Should we migrate to > mini-test only? How should we do it? One approach could be not > adding any new tests into rspec, and migrate existing rspec tests > one-by-one into mini-test. > 2000 rspec examples Do we want to do that? I never liked rspec, but I would maybe stick with it and we could only write new tests in mini-test which is much more easier to learn for newcomers. > Should we decide to stay with both, I think making factory_girl > factories accessible under both suites would be important, as well > as updating rspec tests to use the factories... +1 -- Later, Lukas "lzap" Zapletal #katello #systemengine From jomara at redhat.com Fri Mar 8 15:36:53 2013 From: jomara at redhat.com (Jordan OMara) Date: Fri, 8 Mar 2013 10:36:53 -0500 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <20130308153544.GG1730@lzapx.brq.redhat.com> References: <513A03ED.4090601@redhat.com> <20130308153544.GG1730@lzapx.brq.redhat.com> Message-ID: <20130308153652.GC38689@redhat.com> On 08/03/13 16:35 +0100, Lukas Zapletal wrote: >On Fri, Mar 08, 2013 at 03:29:49PM +0000, Dmitri Dolguikh wrote: >> We found ourselves in a situation where we use two rather different >> testing frameworks: rspec and mini-test. Should we migrate to >> mini-test only? How should we do it? One approach could be not >> adding any new tests into rspec, and migrate existing rspec tests >> one-by-one into mini-test. >> > >2000 rspec examples > >Do we want to do that? > >I never liked rspec, but I would maybe stick with it and we could only >write new tests in mini-test which is much more easier to learn for >newcomers. > I support an rspec moratorium rather than trying to do a full conversion. Would be a monumental effort -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From dmitri at redhat.com Fri Mar 8 15:40:48 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Fri, 08 Mar 2013 15:40:48 +0000 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <20130308153652.GC38689@redhat.com> References: <513A03ED.4090601@redhat.com> <20130308153544.GG1730@lzapx.brq.redhat.com> <20130308153652.GC38689@redhat.com> Message-ID: <513A0680.2090209@redhat.com> On 08/03/13 03:36 PM, Jordan OMara wrote: > On 08/03/13 16:35 +0100, Lukas Zapletal wrote: >> On Fri, Mar 08, 2013 at 03:29:49PM +0000, Dmitri Dolguikh wrote: >>> We found ourselves in a situation where we use two rather different >>> testing frameworks: rspec and mini-test. Should we migrate to >>> mini-test only? How should we do it? One approach could be not >>> adding any new tests into rspec, and migrate existing rspec tests >>> one-by-one into mini-test. >>> >> >> 2000 rspec examples >> >> Do we want to do that? >> >> I never liked rspec, but I would maybe stick with it and we could only >> write new tests in mini-test which is much more easier to learn for >> newcomers. >> > > I support an rspec moratorium rather than trying to do a full > conversion. Would be a monumental effort I don't think moving all tests at once would be wise (feasible). Moving tests over to mini-tests when changes are needed sounds like a possible strategy for such a migration. -d From bbuckingham at redhat.com Fri Mar 8 15:44:42 2013 From: bbuckingham at redhat.com (Brad Buckingham) Date: Fri, 08 Mar 2013 10:44:42 -0500 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <513A03ED.4090601@redhat.com> References: <513A03ED.4090601@redhat.com> Message-ID: <513A076A.9030309@redhat.com> On 03/08/2013 10:29 AM, Dmitri Dolguikh wrote: > We found ourselves in a situation where we use two rather different > testing frameworks: rspec and mini-test. Should we migrate to > mini-test only? How should we do it? One approach could be not adding > any new tests into rspec, and migrate existing rspec tests one-by-one > into mini-test. > > Should we decide to stay with both, I think making factory_girl > factories accessible under both suites would be important, as well as > updating rspec tests to use the factories... > > > Thoughts/opinions? > -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I'd be Ok with recommending that new tests be written in minitest vs rspec, if the team prefers it. It is nice to give devs a choice, but over time it seems like it would only become more confusing and worse to manage and maintain if we continue adding in both. So, I'd recommend new tests in minitest. That said, in rspec there is a test pattern in place for handling the rbac tests. We need to have something similar in minitest; otherwise, those tests will either get missed or need to continue to be written in rspec. As for all of the existing rspec tests, my 2cents is, - if a test requires updates (e.g. as app changes), it could be removed from rspec and added to minitest - if a developer wants to 'on the side' rewrite tests in minitest, that's ok, but I wouldn't make that a focus given we have a lot of features that should get priority cheers, Brad From daviddavis at redhat.com Fri Mar 8 15:52:59 2013 From: daviddavis at redhat.com (David Davis) Date: Fri, 8 Mar 2013 10:52:59 -0500 (EST) Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <513A076A.9030309@redhat.com> Message-ID: <2104624675.17175474.1362757979771.JavaMail.root@redhat.com> I'd be happy to give up Rspec under the condition we can use spec-style minitest tests for when we are writing tests that are not unit tests. I like being able to use the spec style syntax along with features like nested describes when I am writing scenario or integration tests. Here's a link for more information about MiniTest::Spec. http://www.rubyinside.com/a-minitestspec-tutorial-elegant-spec-style-testing-that-comes-with-ruby-5354.html David ----- Original Message ----- > From: "Brad Buckingham" > To: katello-devel at redhat.com > Sent: Friday, March 8, 2013 10:44:42 AM > Subject: Re: [katello-devel] Rspec and/or mini-test? > > On 03/08/2013 10:29 AM, Dmitri Dolguikh wrote: > > We found ourselves in a situation where we use two rather different > > testing frameworks: rspec and mini-test. Should we migrate to > > mini-test only? How should we do it? One approach could be not > > adding > > any new tests into rspec, and migrate existing rspec tests > > one-by-one > > into mini-test. > > > > Should we decide to stay with both, I think making factory_girl > > factories accessible under both suites would be important, as well > > as > > updating rspec tests to use the factories... > > > > > > Thoughts/opinions? > > -d > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > I'd be Ok with recommending that new tests be written in minitest vs > rspec, if the team prefers it. It is nice to give devs a choice, but > over time it seems like it would only become more confusing and worse > to > manage and maintain if we continue adding in both. So, I'd recommend > new tests in minitest. That said, in rspec there is a test pattern > in > place for handling the rbac tests. We need to have something similar > in > minitest; otherwise, those tests will either get missed or need to > continue to be written in rspec. > > As for all of the existing rspec tests, my 2cents is, > - if a test requires updates (e.g. as app changes), it could be > removed > from rspec and added to minitest > - if a developer wants to 'on the side' rewrite tests in minitest, > that's ok, but I wouldn't make that a focus given we have a lot of > features that should get priority > > cheers, > Brad > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jomara at redhat.com Fri Mar 8 15:54:19 2013 From: jomara at redhat.com (Jordan OMara) Date: Fri, 8 Mar 2013 10:54:19 -0500 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <513A076A.9030309@redhat.com> References: <513A03ED.4090601@redhat.com> <513A076A.9030309@redhat.com> Message-ID: <20130308155419.GD38689@redhat.com> On 08/03/13 10:44 -0500, Brad Buckingham wrote: > > As for all of the existing rspec tests, my 2cents is, > - if a test requires updates (e.g. as app changes), it could be removed > from rspec and added to minitest > - if a developer wants to 'on the side' rewrite tests in minitest, > that's ok, but I wouldn't make that a focus given we have a lot of > features that should get priority > +1 -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From mhulan at redhat.com Fri Mar 8 16:50:02 2013 From: mhulan at redhat.com (Marek Hulan) Date: Fri, 08 Mar 2013 17:50:02 +0100 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <20130308153544.GG1730@lzapx.brq.redhat.com> References: <513A03ED.4090601@redhat.com> <20130308153544.GG1730@lzapx.brq.redhat.com> Message-ID: <1965670.iOLE1gUuWM@edna> On Friday 08 of March 2013 16:35:44 Lukas Zapletal wrote: > On Fri, Mar 08, 2013 at 03:29:49PM +0000, Dmitri Dolguikh wrote: > > We found ourselves in a situation where we use two rather different > > testing frameworks: rspec and mini-test. Should we migrate to > > mini-test only? How should we do it? One approach could be not > > adding any new tests into rspec, and migrate existing rspec tests > > one-by-one into mini-test. > > 2000 rspec examples > > Do we want to do that? > > I never liked rspec, but I would maybe stick with it and we could only > write new tests in mini-test which is much more easier to learn for > newcomers. > You can write minitest in syntax very similar to rspec. So converting existing tests does not necessarily mean to rewrite everything from scratch. But it's probably a lot of work anyway. But even if we start using minitest there is other decision to make. Should we use spec-like syntaxt or testunit-like syntax? Because of test helpers sharing I think choosing one style would be helpful. Personally I'd prefer spec-like syntax since it's more readable for me (unless stack level of blocks is too deep :-) -- Marek From jomara at redhat.com Fri Mar 8 19:13:36 2013 From: jomara at redhat.com (Jordan OMara) Date: Fri, 8 Mar 2013 14:13:36 -0500 Subject: [katello-devel] Purpose of katello and katello-common packages In-Reply-To: <20130307170007.GL1757@lzapx.brq.redhat.com> References: <20130307170007.GL1757@lzapx.brq.redhat.com> Message-ID: <20130308191336.GH38689@redhat.com> On 07/03/13 18:00 +0100, Lukas Zapletal wrote: >Hey, > >today I noticed we deliver some shared bits in two packages: > >katello >katello-common > katello is not delivered with headpin, but katello-common is. however, lots of overlap between katello and katello-headpin. it could definitely be organized better -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From bkearney at redhat.com Sat Mar 9 13:43:06 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Sat, 09 Mar 2013 08:43:06 -0500 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <20130308155419.GD38689@redhat.com> References: <513A03ED.4090601@redhat.com> <513A076A.9030309@redhat.com> <20130308155419.GD38689@redhat.com> Message-ID: <513B3C6A.3070401@redhat.com> On 03/08/2013 10:54 AM, Jordan OMara wrote: > On 08/03/13 10:44 -0500, Brad Buckingham wrote: >> >> As for all of the existing rspec tests, my 2cents is, >> - if a test requires updates (e.g. as app changes), it could be >> removed from rspec and added to minitest >> - if a developer wants to 'on the side' rewrite tests in minitest, >> that's ok, but I wouldn't make that a focus given we have a lot of >> features that should get priority >> > > +1 > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > Why are we adding a new testing framework? Is it fixing a problem in the current frameworks? -- bk From daviddavis at redhat.com Sat Mar 9 15:34:08 2013 From: daviddavis at redhat.com (David Davis) Date: Sat, 9 Mar 2013 10:34:08 -0500 (EST) Subject: [katello-devel] Fixing schema.rb merge conflicts In-Reply-To: <298795375.17579920.1362843059479.JavaMail.root@redhat.com> Message-ID: <740153164.17580014.1362843248922.JavaMail.root@redhat.com> If you ever get a merge conflict in your schema.rb file, the solution is very easy. Just run "rake db:migrate" to regenerate it. After that, you can just run git commit or git rebase --continue. As to why our schema.rb is in version control now, it's recommended in Rails as it's considered to be the authoritative source for what the db ought to look like [1]. Moreover, Travis is using it to load the database as it's about 50 seconds faster than migrating. [1] http://guides.rubyonrails.org/migrations.html#schema-dumping-and-you David From ohadlevy at redhat.com Sun Mar 10 13:13:04 2013 From: ohadlevy at redhat.com (Ohad Levy) Date: Sun, 10 Mar 2013 09:13:04 -0400 (EDT) Subject: [katello-devel] Design of SSO - screencast In-Reply-To: <2624882.olzb1c1klo@edna> Message-ID: <733950140.11806610.1362921184232.JavaMail.root@redhat.com> ----- Original Message ----- | Hey all | | I just finished a short screencast about SSO design spike I worked on | recently. | You can find on youtube http://www.youtube.com/watch?v=4Ov771INMns | | Comments or questions are welcome Looking good, a few questions 1. why are we authenticating to Katello? is this planned to be extracted back to the SSO app? 2. how are we validating the cookie, is it short lived? 3. how do i force idle timeout? should we still do it in katello/foreman? 4. would we support multiple backends? e.g. foreman now has the notion of authenticating against multiple auth sources (e.g. ldap / internal / ad) at the same time. 5. do you provide user details (e.g. ldap query can return additional user attributes such as email), or only authentication true / false? Foreman relay on such details (e.g. first name, last name, email etc) for auto creating the users in the database for their first login. thanks! Ohad | | -- | Marek | | _______________________________________________ | katello-devel mailing list | katello-devel at redhat.com | https://www.redhat.com/mailman/listinfo/katello-devel | From mhulan at redhat.com Mon Mar 11 08:01:05 2013 From: mhulan at redhat.com (Marek Hulan) Date: Mon, 11 Mar 2013 09:01:05 +0100 Subject: [katello-devel] Design of SSO - screencast In-Reply-To: <733950140.11806610.1362921184232.JavaMail.root@redhat.com> References: <733950140.11806610.1362921184232.JavaMail.root@redhat.com> Message-ID: <2463729.d74fTOrqCD@edna> Hi, sending answers in text below On Sunday 10 of March 2013 09:13:04 you wrote: > ----- Original Message ----- > > | Hey all > | > | I just finished a short screencast about SSO design spike I worked on > | recently. > | You can find on youtube http://www.youtube.com/watch?v=4Ov771INMns > | > | Comments or questions are welcome > > Looking good, a few questions > > 1. why are we authenticating to Katello? is this planned to be extracted > back to the SSO app? Because it's currently authoritative source of users and it knows whether to use LDAP or it's internal DB. However one of a first thing planned is to learn SSO app to communicate directly to LDAP. > 2. how are we validating the cookie, is it short > lived? There is no validation of cookie and it should not be required. Cookie does not contain any important information, it's just a shortcut for future login to avoid some redirect. Currently cookie lives for 10 hours but this is easy to make it configurable. > 3. how do i force idle timeout? should we still do it in katello/foreman? Yes, I don't see any easy way we could implement this on SSO side. Katello/Foreman must trigger SSO logout which then redirects to Katello/Foreman logout action so you logout from SSO and your app. > 4. would we support multiple backends? e.g. foreman now has the notion of > authenticating against multiple auth sources (e.g. ldap / internal / ad) at > the same time. Since it's lightweight application it should not be hard to add new backends. Currently it supports only one - Katello, but it's a plan to add more of them. > 5. do you provide user details (e.g. ldap query can return > additional user attributes such as email), or only authentication true / > false? Foreman relay on such details (e.g. first name, last name, email > etc) for auto creating the users in the database for their first login. This is auth only system so only true/false. However OpenID which we use has a mechanism (SREG [1]) to share some information about user. It's not implemented yet in our OpenID provider but it can be implemented if needed. Let me know if you have further questions. Thank you [1] http://openid.net/specs/openid-simple-registration-extension-1_0.html -- Marek From lzap at redhat.com Mon Mar 11 08:27:49 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 11 Mar 2013 09:27:49 +0100 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <1965670.iOLE1gUuWM@edna> References: <513A03ED.4090601@redhat.com> <20130308153544.GG1730@lzapx.brq.redhat.com> <1965670.iOLE1gUuWM@edna> Message-ID: <20130311082748.GA1760@lzapx.brq.redhat.com> On Fri, Mar 08, 2013 at 05:50:02PM +0100, Marek Hulan wrote: > Personally I'd prefer spec-like syntax since it's more readable for me (unless > stack level of blocks is too deep :-) I am for xUnit syntax, whatever this is called in Ruby world. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Mon Mar 11 08:32:37 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 11 Mar 2013 09:32:37 +0100 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <513B3C6A.3070401@redhat.com> References: <513A03ED.4090601@redhat.com> <513A076A.9030309@redhat.com> <20130308155419.GD38689@redhat.com> <513B3C6A.3070401@redhat.com> Message-ID: <20130311083237.GB1760@lzapx.brq.redhat.com> On Sat, Mar 09, 2013 at 08:43:06AM -0500, Bryan Kearney wrote: > Why are we adding a new testing framework? Is it fixing a problem in > the current frameworks? +1 If we are going to shift from rspec to minitest-rspec, I dont really see any added value, except we will get rid of few test-time dependencies. Please again, what is the pain we are trying to solve with this? I was under impression we don't like rspec syntax and wan't straightforward xunit syntax, but I can see this is not the case. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From ohadlevy at redhat.com Mon Mar 11 08:40:28 2013 From: ohadlevy at redhat.com (Ohad Levy) Date: Mon, 11 Mar 2013 04:40:28 -0400 (EDT) Subject: [katello-devel] Design of SSO - screencast In-Reply-To: <2463729.d74fTOrqCD@edna> Message-ID: <34994674.11978069.1362991228800.JavaMail.root@redhat.com> ----- Original Message ----- | Hi, | | sending answers in text below | | On Sunday 10 of March 2013 09:13:04 you wrote: | > ----- Original Message ----- | > | > | Hey all | > | | > | I just finished a short screencast about SSO design spike I | > | worked on | > | recently. | > | You can find on youtube | > | http://www.youtube.com/watch?v=4Ov771INMns | > | | > | Comments or questions are welcome | > | > Looking good, a few questions | > | > 1. why are we authenticating to Katello? is this planned to be | > extracted | > back to the SSO app? | Because it's currently authoritative source of users and it knows | whether to | use LDAP or it's internal DB. However one of a first thing planned is | to learn | SSO app to communicate directly to LDAP. | | > 2. how are we validating the cookie, is it short | > lived? | There is no validation of cookie and it should not be required. | Cookie does | not contain any important information, it's just a shortcut for | future login | to avoid some redirect. Currently cookie lives for 10 hours but this | is easy | to make it configurable. | | > 3. how do i force idle timeout? should we still do it in | > katello/foreman? | Yes, I don't see any easy way we could implement this on SSO side. | Katello/Foreman must trigger SSO logout which then redirects to | Katello/Foreman logout action so you logout from SSO and your app. | | > 4. would we support multiple backends? e.g. foreman now has the | > notion of | > authenticating against multiple auth sources (e.g. ldap / internal | > / ad) at | > the same time. | Since it's lightweight application it should not be hard to add new | backends. | Currently it supports only one - Katello, but it's a plan to add more | of them. | | > 5. do you provide user details (e.g. ldap query can return | > additional user attributes such as email), or only authentication | > true / | > false? Foreman relay on such details (e.g. first name, last name, | > email | > etc) for auto creating the users in the database for their first | > login. | This is auth only system so only true/false. However OpenID which we | use has a | mechanism (SREG [1]) to share some information about user. It's not | implemented yet in our OpenID provider but it can be implemented if | needed. | | Let me know if you have further questions. | Thank you Thanks Marek, My main concern is that this would not be a drop in replacement for current foreman users, and we would need to maintain multiple SSO backends (e.g. what foreman currently has with Apache) or plain authentication ( e.g. it wont answer get user details ). thanks, Ohad | | [1] | http://openid.net/specs/openid-simple-registration-extension-1_0.html | | -- | Marek | From paji at redhat.com Mon Mar 11 09:44:59 2013 From: paji at redhat.com (Partha Aji) Date: Mon, 11 Mar 2013 05:44:59 -0400 (EDT) Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <20130311083237.GB1760@lzapx.brq.redhat.com> References: <513A03ED.4090601@redhat.com> <513A076A.9030309@redhat.com> <20130308155419.GD38689@redhat.com> <513B3C6A.3070401@redhat.com> <20130311083237.GB1760@lzapx.brq.redhat.com> Message-ID: On Mar 11, 2013, at 2:02 PM, Lukas Zapletal wrote: > On Sat, Mar 09, 2013 at 08:43:06AM -0500, Bryan Kearney wrote: >> Why are we adding a new testing framework? Is it fixing a problem in >> the current frameworks? > > +1 > > If we are going to shift from rspec to minitest-rspec, I dont really see > any added value, except we will get rid of few test-time dependencies. +1 I like the xUnit syntax too. I would be ok with using just minitest as opposed to minitest:rspec Partha > > Please again, what is the pain we are trying to solve with this? I was > under impression we don't like rspec syntax and wan't straightforward > xunit syntax, but I can see this is not the case. > > LZ > > -- > Later, > > Lukas "lzap" Zapletal From msuchy at redhat.com Mon Mar 11 11:26:31 2013 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 11 Mar 2013 12:26:31 +0100 Subject: [katello-devel] anyone have gettext testing fu? In-Reply-To: <5138BCA3.10208@redhat.com> References: <5137A1B0.6020807@redhat.com> <20130307101348.GE1757@lzapx.brq.redhat.com> <5138BCA3.10208@redhat.com> Message-ID: <513DBF67.3090509@redhat.com> On 03/07/2013 05:13 PM, Bryan Kearney wrote: > My real goal is to help with ensuring that all strings on a page are > translated during development. I was hoping to alias the _() method so > that it returns the string wiht: > > X{THE ORIGINAL STRING }X We discussed exactly the same when QA was in Brno. And somebody (I think it was Og) come with idea to replace the original string with XXXXXXXXXXX. So once you switch to this XX locale, and you will see something else then X, you will know that it is not localized string. -- Miroslav Suchy Red Hat Systems Management Engineering From bkearney at redhat.com Mon Mar 11 11:48:24 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 11 Mar 2013 07:48:24 -0400 Subject: [katello-devel] anyone have gettext testing fu? In-Reply-To: <513DBF67.3090509@redhat.com> References: <5137A1B0.6020807@redhat.com> <20130307101348.GE1757@lzapx.brq.redhat.com> <5138BCA3.10208@redhat.com> <513DBF67.3090509@redhat.com> Message-ID: <513DC488.1050104@redhat.com> On 03/11/2013 07:26 AM, Miroslav Such? wrote: > On 03/07/2013 05:13 PM, Bryan Kearney wrote: >> My real goal is to help with ensuring that all strings on a page are >> translated during development. I was hoping to alias the _() method so >> that it returns the string wiht: >> >> X{THE ORIGINAL STRING }X > > We discussed exactly the same when QA was in Brno. And somebody (I think > it was Og) come with idea to replace the original string with > XXXXXXXXXXX. So once you switch to this XX locale, and you will see > something else then X, you will know that it is not localized string. > It would be easy to drive this off of a setting, so that you do not need to swtch the locale. -- bk From daviddavis at redhat.com Mon Mar 11 11:58:59 2013 From: daviddavis at redhat.com (David Davis) Date: Mon, 11 Mar 2013 07:58:59 -0400 (EDT) Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: Message-ID: <735561687.17937075.1363003139369.JavaMail.root@redhat.com> Another thing worth considering is that Rspec is by far the most popular Ruby testing framework [1] while TestUnit-style tests are probably more familiar to people outside of Ruby. [1] https://www.ruby-toolbox.com/categories/testing_frameworks David ----- Original Message ----- > From: "Partha Aji" > To: "Lukas Zapletal" > Cc: katello-devel at redhat.com > Sent: Monday, March 11, 2013 5:44:59 AM > Subject: Re: [katello-devel] Rspec and/or mini-test? > > > > On Mar 11, 2013, at 2:02 PM, Lukas Zapletal wrote: > > > On Sat, Mar 09, 2013 at 08:43:06AM -0500, Bryan Kearney wrote: > >> Why are we adding a new testing framework? Is it fixing a problem > >> in > >> the current frameworks? > > > > +1 > > > > If we are going to shift from rspec to minitest-rspec, I dont > > really see > > any added value, except we will get rid of few test-time > > dependencies. > +1 > I like the xUnit syntax too. > I would be ok with using just minitest as opposed to minitest:rspec > > > Partha > > > > > Please again, what is the pain we are trying to solve with this? I > > was > > under impression we don't like rspec syntax and wan't > > straightforward > > xunit syntax, but I can see this is not the case. > > > > LZ > > > > -- > > Later, > > > > Lukas "lzap" Zapletal > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From dmitri at redhat.com Mon Mar 11 12:18:12 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 11 Mar 2013 12:18:12 +0000 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <513B3C6A.3070401@redhat.com> References: <513A03ED.4090601@redhat.com> <513A076A.9030309@redhat.com> <20130308155419.GD38689@redhat.com> <513B3C6A.3070401@redhat.com> Message-ID: <513DCB84.9070002@redhat.com> On 09/03/13 01:43 PM, Bryan Kearney wrote: > On 03/08/2013 10:54 AM, Jordan OMara wrote: >> On 08/03/13 10:44 -0500, Brad Buckingham wrote: >>> >>> As for all of the existing rspec tests, my 2cents is, >>> - if a test requires updates (e.g. as app changes), it could be >>> removed from rspec and added to minitest >>> - if a developer wants to 'on the side' rewrite tests in minitest, >>> that's ok, but I wouldn't make that a focus given we have a lot of >>> features that should get priority >>> >> >> +1 >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > Why are we adding a new testing framework? Is it fixing a problem in > the current frameworks? Already happened as part of pulp v.2 work. I think the view of the folks who did the work is that mini-test (test::unit) leads to more readable tests compared to rspec. I'll let those involved speak for themselves... -d > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mhulan at redhat.com Mon Mar 11 12:23:15 2013 From: mhulan at redhat.com (Marek Hulan) Date: Mon, 11 Mar 2013 13:23:15 +0100 Subject: [katello-devel] Design of SSO - screencast In-Reply-To: <34994674.11978069.1362991228800.JavaMail.root@redhat.com> References: <34994674.11978069.1362991228800.JavaMail.root@redhat.com> Message-ID: <2992506.mk4zYcnIj8@edna> On Monday 11 of March 2013 04:40:28 you wrote: > ----- Original Message ----- > > | Hi, > | > | sending answers in text below > | > | On Sunday 10 of March 2013 09:13:04 you wrote: > | > ----- Original Message ----- > | > > | > | Hey all > | > | > | > | I just finished a short screencast about SSO design spike I > | > | worked on > | > | recently. > | > | You can find on youtube > | > | http://www.youtube.com/watch?v=4Ov771INMns > | > | > | > | Comments or questions are welcome > | > > | > Looking good, a few questions > | > > | > 1. why are we authenticating to Katello? is this planned to be > | > extracted > | > back to the SSO app? > | > | Because it's currently authoritative source of users and it knows > | whether to > | use LDAP or it's internal DB. However one of a first thing planned is > | to learn > | SSO app to communicate directly to LDAP. > | > | > 2. how are we validating the cookie, is it short > | > lived? > | > | There is no validation of cookie and it should not be required. > | Cookie does > | not contain any important information, it's just a shortcut for > | future login > | to avoid some redirect. Currently cookie lives for 10 hours but this > | is easy > | to make it configurable. > | > | > 3. how do i force idle timeout? should we still do it in > | > katello/foreman? > | > | Yes, I don't see any easy way we could implement this on SSO side. > | Katello/Foreman must trigger SSO logout which then redirects to > | Katello/Foreman logout action so you logout from SSO and your app. > | > | > 4. would we support multiple backends? e.g. foreman now has the > | > notion of > | > authenticating against multiple auth sources (e.g. ldap / internal > | > / ad) at > | > the same time. > | > | Since it's lightweight application it should not be hard to add new > | backends. > | Currently it supports only one - Katello, but it's a plan to add more > | of them. > | > | > 5. do you provide user details (e.g. ldap query can return > | > additional user attributes such as email), or only authentication > | > true / > | > false? Foreman relay on such details (e.g. first name, last name, > | > email > | > etc) for auto creating the users in the database for their first > | > login. > | > | This is auth only system so only true/false. However OpenID which we > | use has a > | mechanism (SREG [1]) to share some information about user. It's not > | implemented yet in our OpenID provider but it can be implemented if > | needed. > | > | Let me know if you have further questions. > | Thank you > > Thanks Marek, > > My main concern is that this would not be a drop in replacement for current > foreman users, and we would need to maintain multiple SSO backends (e.g. > what foreman currently has with Apache) or plain authentication ( e.g. it > wont answer get user details ). I'm not sure whether I get it right but this SSO application was not meant to be any replacement. Users would not be forced to use it at all. It should allow users only one thing that it's named after - they just sign in once and they can use other systems immediately. The only thing that's needed from Foreman point of view is adding support for custom OpenID provider. It's 39 LOC including whitelines and comments. The biggest benefit would be that Katello and Foreman (and maybe other systems) would not have to implement various authentication methods separately. It means having kerberos, LDAP and e.g. OpenID authentication on one place and reused by all applications. Hence you could remove some SSO backends you may already have in Foreman. Does it make sense? What should this SSO solution fulfill to meet Foreman requirements? Thanks -- Marek From dmitri at redhat.com Mon Mar 11 12:25:00 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Mon, 11 Mar 2013 12:25:00 +0000 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <2104624675.17175474.1362757979771.JavaMail.root@redhat.com> References: <2104624675.17175474.1362757979771.JavaMail.root@redhat.com> Message-ID: <513DCD1C.2000400@redhat.com> On 08/03/13 03:52 PM, David Davis wrote: > I'd be happy to give up Rspec under the condition we can use spec-style minitest tests for when we are writing tests that are not unit tests. > > I like being able to use the spec style syntax along with features like nested describes when I am writing scenario or integration tests. > > Here's a link for more information about MiniTest::Spec. > > http://www.rubyinside.com/a-minitestspec-tutorial-elegant-spec-style-testing-that-comes-with-ruby-5354.html > > David But without sprawling contexts? Or combining multiple suites into one? The biggest issue with rspec for me is that it's pretty hard to use them as documentation: nested contexts/describes make it hard to understand by looking at the code what's being tested. English-language descriptions often times are inadequate. -d > > ----- Original Message ----- >> From: "Brad Buckingham" >> To: katello-devel at redhat.com >> Sent: Friday, March 8, 2013 10:44:42 AM >> Subject: Re: [katello-devel] Rspec and/or mini-test? >> >> On 03/08/2013 10:29 AM, Dmitri Dolguikh wrote: >>> We found ourselves in a situation where we use two rather different >>> testing frameworks: rspec and mini-test. Should we migrate to >>> mini-test only? How should we do it? One approach could be not >>> adding >>> any new tests into rspec, and migrate existing rspec tests >>> one-by-one >>> into mini-test. >>> >>> Should we decide to stay with both, I think making factory_girl >>> factories accessible under both suites would be important, as well >>> as >>> updating rspec tests to use the factories... >>> >>> >>> Thoughts/opinions? >>> -d >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> I'd be Ok with recommending that new tests be written in minitest vs >> rspec, if the team prefers it. It is nice to give devs a choice, but >> over time it seems like it would only become more confusing and worse >> to >> manage and maintain if we continue adding in both. So, I'd recommend >> new tests in minitest. That said, in rspec there is a test pattern >> in >> place for handling the rbac tests. We need to have something similar >> in >> minitest; otherwise, those tests will either get missed or need to >> continue to be written in rspec. >> >> As for all of the existing rspec tests, my 2cents is, >> - if a test requires updates (e.g. as app changes), it could be >> removed >> from rspec and added to minitest >> - if a developer wants to 'on the side' rewrite tests in minitest, >> that's ok, but I wouldn't make that a focus given we have a lot of >> features that should get priority >> >> cheers, >> Brad >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From daviddavis at redhat.com Mon Mar 11 12:44:30 2013 From: daviddavis at redhat.com (David Davis) Date: Mon, 11 Mar 2013 08:44:30 -0400 (EDT) Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <513B3C6A.3070401@redhat.com> Message-ID: <419323691.17958734.1363005870352.JavaMail.root@redhat.com> I think this is a very good question. We're using a very large amount of technologies in Katello. We have something almost 10 languages already (Ruby, Python, SASS/SCSS, Bash, Javascript, YAML, HAML, HTML, etc) and countless numbers of libraries (frameworks, gems, etc). I think this is a barrier to entry for new developers. David ----- Original Message ----- > From: "Bryan Kearney" > To: katello-devel at redhat.com > Sent: Saturday, March 9, 2013 8:43:06 AM > Subject: Re: [katello-devel] Rspec and/or mini-test? > > On 03/08/2013 10:54 AM, Jordan OMara wrote: > > On 08/03/13 10:44 -0500, Brad Buckingham wrote: > >> > >> As for all of the existing rspec tests, my 2cents is, > >> - if a test requires updates (e.g. as app changes), it could be > >> removed from rspec and added to minitest > >> - if a developer wants to 'on the side' rewrite tests in minitest, > >> that's ok, but I wouldn't make that a focus given we have a lot of > >> features that should get priority > >> > > > > +1 > > > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > Why are we adding a new testing framework? Is it fixing a problem in > the > current frameworks? > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Mon Mar 11 12:47:58 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 11 Mar 2013 13:47:58 +0100 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <735561687.17937075.1363003139369.JavaMail.root@redhat.com> References: <735561687.17937075.1363003139369.JavaMail.root@redhat.com> Message-ID: <20130311124758.GE1760@lzapx.brq.redhat.com> Objection overruled :-) LZ On Mon, Mar 11, 2013 at 07:58:59AM -0400, David Davis wrote: > Another thing worth considering is that Rspec is by far the most popular Ruby testing framework [1] while TestUnit-style tests are probably more familiar to people outside of Ruby. > > [1] https://www.ruby-toolbox.com/categories/testing_frameworks > > David > > ----- Original Message ----- > > From: "Partha Aji" > > To: "Lukas Zapletal" > > Cc: katello-devel at redhat.com > > Sent: Monday, March 11, 2013 5:44:59 AM > > Subject: Re: [katello-devel] Rspec and/or mini-test? > > > > > > > > On Mar 11, 2013, at 2:02 PM, Lukas Zapletal wrote: > > > > > On Sat, Mar 09, 2013 at 08:43:06AM -0500, Bryan Kearney wrote: > > >> Why are we adding a new testing framework? Is it fixing a problem > > >> in > > >> the current frameworks? > > > > > > +1 > > > > > > If we are going to shift from rspec to minitest-rspec, I dont > > > really see > > > any added value, except we will get rid of few test-time > > > dependencies. > > +1 > > I like the xUnit syntax too. > > I would be ok with using just minitest as opposed to minitest:rspec > > > > > > Partha > > > > > > > > Please again, what is the pain we are trying to solve with this? I > > > was > > > under impression we don't like rspec syntax and wan't > > > straightforward > > > xunit syntax, but I can see this is not the case. > > > > > > LZ > > > > > > -- > > > Later, > > > > > > Lukas "lzap" Zapletal > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -- Later, Lukas "lzap" Zapletal #katello #systemengine From ohadlevy at redhat.com Mon Mar 11 12:31:27 2013 From: ohadlevy at redhat.com (Ohad Levy) Date: Mon, 11 Mar 2013 08:31:27 -0400 (EDT) Subject: [katello-devel] Design of SSO - screencast In-Reply-To: <2992506.mk4zYcnIj8@edna> Message-ID: <78260930.12087503.1363005087334.JavaMail.root@redhat.com> | > My main concern is that this would not be a drop in replacement for | > current | > foreman users, and we would need to maintain multiple SSO backends | > (e.g. | > what foreman currently has with Apache) or plain authentication ( | > e.g. it | > wont answer get user details ). | I'm not sure whether I get it right but this SSO application was not | meant to | be any replacement. Users would not be forced to use it at all. It | should | allow users only one thing that it's named after - they just sign in | once and | they can use other systems immediately. The only thing that's needed | from | Foreman point of view is adding support for custom OpenID provider. | | It's 39 LOC including whitelines and comments. The biggest benefit | would be | that Katello and Foreman (and maybe other systems) would not have to | implement | various authentication methods separately. It means having kerberos, | LDAP and | e.g. OpenID authentication on one place and reused by all | applications. Hence | you could remove some SSO backends you may already have in Foreman. | | Does it make sense? What should this SSO solution fulfill to meet | Foreman | requirements? The issue here, is that you would need to configure ldap twice, once for SSO app to authenticate, and the other time for foreman to query user/group information. this means you store the pw twice, and also means that i cant get rid of the ldap related code in foreman. PS. if you tend to send this mail to the public (and get feedback from foreman community), please use the foreman developers mailing list hosted at google lists. Ohad From mhulan at redhat.com Mon Mar 11 12:54:54 2013 From: mhulan at redhat.com (Marek Hulan) Date: Mon, 11 Mar 2013 13:54:54 +0100 Subject: [katello-devel] Design of SSO - screencast In-Reply-To: <78260930.12087503.1363005087334.JavaMail.root@redhat.com> References: <78260930.12087503.1363005087334.JavaMail.root@redhat.com> Message-ID: <3687262.2nHC64rWkN@edna> On Monday 11 of March 2013 08:31:27 Ohad Levy wrote: > | > My main concern is that this would not be a drop in replacement for > | > current > | > foreman users, and we would need to maintain multiple SSO backends > | > (e.g. > | > what foreman currently has with Apache) or plain authentication ( > | > e.g. it > | > wont answer get user details ). > | > | I'm not sure whether I get it right but this SSO application was not > | meant to > | be any replacement. Users would not be forced to use it at all. It > | should > | allow users only one thing that it's named after - they just sign in > | once and > | they can use other systems immediately. The only thing that's needed > | from > | Foreman point of view is adding support for custom OpenID provider. > | > | It's 39 LOC including whitelines and comments. The biggest benefit > | would be > | that Katello and Foreman (and maybe other systems) would not have to > | implement > | various authentication methods separately. It means having kerberos, > | LDAP and > | e.g. OpenID authentication on one place and reused by all > | applications. Hence > | you could remove some SSO backends you may already have in Foreman. > | > | Does it make sense? What should this SSO solution fulfill to meet > | Foreman > | requirements? > > The issue here, is that you would need to configure ldap twice, once for SSO > app to authenticate, and the other time for foreman to query user/group > information. > > this means you store the pw twice, and also means that i cant get rid of the > ldap related code in foreman. Why this can't be the same LDAP instance? It would only make sense to have one DB of users. You are right, LDAP code would have to stay in Foreman to gather information about users. Unless we implement some REST API in SSO to provide user information however this is something I'd like to avoid. It would result in adding another layer that would just translate data. > PS. if you tend to send this mail to the public (and get feedback from > foreman community), please use the foreman developers mailing list hosted > at google lists. > > Ohad -- Marek From ohadlevy at redhat.com Mon Mar 11 12:57:49 2013 From: ohadlevy at redhat.com (Ohad Levy) Date: Mon, 11 Mar 2013 08:57:49 -0400 (EDT) Subject: [katello-devel] Design of SSO - screencast In-Reply-To: <3687262.2nHC64rWkN@edna> Message-ID: <1672356466.12127575.1363006669492.JavaMail.root@redhat.com> ----- Original Message ----- | On Monday 11 of March 2013 08:31:27 Ohad Levy wrote: | > | > My main concern is that this would not be a drop in replacement | > | > for | > | > current | > | > foreman users, and we would need to maintain multiple SSO | > | > backends | > | > (e.g. | > | > what foreman currently has with Apache) or plain authentication | > | > ( | > | > e.g. it | > | > wont answer get user details ). | > | | > | I'm not sure whether I get it right but this SSO application was | > | not | > | meant to | > | be any replacement. Users would not be forced to use it at all. | > | It | > | should | > | allow users only one thing that it's named after - they just sign | > | in | > | once and | > | they can use other systems immediately. The only thing that's | > | needed | > | from | > | Foreman point of view is adding support for custom OpenID | > | provider. | > | | > | It's 39 LOC including whitelines and comments. The biggest | > | benefit | > | would be | > | that Katello and Foreman (and maybe other systems) would not have | > | to | > | implement | > | various authentication methods separately. It means having | > | kerberos, | > | LDAP and | > | e.g. OpenID authentication on one place and reused by all | > | applications. Hence | > | you could remove some SSO backends you may already have in | > | Foreman. | > | | > | Does it make sense? What should this SSO solution fulfill to meet | > | Foreman | > | requirements? | > | > The issue here, is that you would need to configure ldap twice, | > once for SSO | > app to authenticate, and the other time for foreman to query | > user/group | > information. | > | > this means you store the pw twice, and also means that i cant get | > rid of the | > ldap related code in foreman. | Why this can't be the same LDAP instance? It would only make sense to | have one | DB of users. You are right, LDAP code would have to stay in Foreman | to gather | information about users. Unless we implement some REST API in SSO to | provide | user information however this is something I'd like to avoid. It | would result | in adding another layer that would just translate data. my point is, that if you need an account to authenticate to ldap (e.g. plain users might not have bind rights, or search rights etc), you would need to store that account password twice. Ohad | | > PS. if you tend to send this mail to the public (and get feedback | > from | > foreman community), please use the foreman developers mailing list | > hosted | > at google lists. | > | > Ohad | -- | Marek | | From jsherril at redhat.com Mon Mar 11 13:29:39 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 11 Mar 2013 09:29:39 -0400 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: <513B3C6A.3070401@redhat.com> References: <513A03ED.4090601@redhat.com> <513A076A.9030309@redhat.com> <20130308155419.GD38689@redhat.com> <513B3C6A.3070401@redhat.com> Message-ID: <513DDC43.7010709@redhat.com> On 03/09/2013 08:43 AM, Bryan Kearney wrote: > On 03/08/2013 10:54 AM, Jordan OMara wrote: >> On 08/03/13 10:44 -0500, Brad Buckingham wrote: >>> >>> As for all of the existing rspec tests, my 2cents is, >>> - if a test requires updates (e.g. as app changes), it could be >>> removed from rspec and added to minitest >>> - if a developer wants to 'on the side' rewrite tests in minitest, >>> that's ok, but I wouldn't make that a focus given we have a lot of >>> features that should get priority >>> >> >> +1 >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > Why are we adding a new testing framework? Is it fixing a problem in > the current frameworks? So as part of the pulpv2 we tried to tackle improving our testing, some of the issues we desired to tackle: - Our tests are written very poorly written and are extremely slow * We manually create() many many objects before every test, in a lot of cases we are creating the org, environment, provider, product, etc... before every test. This slows down the tests dramatically. * Over the past 2 years that 'model' has not really changed, everyone keeps plugging along in the existing rspec framework we have setup, and things only get worse. - Working with the glue layer was a nightmare * In many places we stubbed glue layer calls which seems simple on the surface but due to the complex nature of our interactions and the responses these backend systems would give, it was not fun * No way to test glue layer functions against backend services - The above could not be easily rectified without re-writing the spec tests - In general we had heard a LOT of complaining about rspec. Most of the tests were written as unit tests which is not the intent, and the syntax can be confusing. After working with it for over a year, most of the people we talked to unofficially did not seem to enjoy it. This was all covered in a deep dive last fall IIRC (eric lead it) So what does minitest (and our work to use minitest) give us? - Easier testing of models with the glue layer disabled (Dont' need a backend engine, dont' use it!) - VCR testing of backend engines - Easier to read tests - Easier to write test Could we have gotten the above with rspec? Probably, but since the 'framework' we had built around the tests needed to be torn down anyways, it made more sense to start completely fresh. And since people seemed to prefer the unit style of tests, we went with that. -Justin > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mhulan at redhat.com Mon Mar 11 14:58:11 2013 From: mhulan at redhat.com (Marek Hulan) Date: Mon, 11 Mar 2013 15:58:11 +0100 Subject: [katello-devel] Design of SSO - screencast In-Reply-To: <1672356466.12127575.1363006669492.JavaMail.root@redhat.com> References: <1672356466.12127575.1363006669492.JavaMail.root@redhat.com> Message-ID: <1570143.ZRVdPhKa9t@edna> On Monday 11 of March 2013 08:57:49 you wrote: > ----- Original Message ----- > > | On Monday 11 of March 2013 08:31:27 Ohad Levy wrote: > | > | > My main concern is that this would not be a drop in replacement > | > | > for > | > | > current > | > | > foreman users, and we would need to maintain multiple SSO > | > | > backends > | > | > (e.g. > | > | > what foreman currently has with Apache) or plain authentication > | > | > ( > | > | > e.g. it > | > | > wont answer get user details ). > | > | > | > | I'm not sure whether I get it right but this SSO application was > | > | not > | > | meant to > | > | be any replacement. Users would not be forced to use it at all. > | > | It > | > | should > | > | allow users only one thing that it's named after - they just sign > | > | in > | > | once and > | > | they can use other systems immediately. The only thing that's > | > | needed > | > | from > | > | Foreman point of view is adding support for custom OpenID > | > | provider. > | > | > | > | It's 39 LOC including whitelines and comments. The biggest > | > | benefit > | > | would be > | > | that Katello and Foreman (and maybe other systems) would not have > | > | to > | > | implement > | > | various authentication methods separately. It means having > | > | kerberos, > | > | LDAP and > | > | e.g. OpenID authentication on one place and reused by all > | > | applications. Hence > | > | you could remove some SSO backends you may already have in > | > | Foreman. > | > | > | > | Does it make sense? What should this SSO solution fulfill to meet > | > | Foreman > | > | requirements? > | > > | > The issue here, is that you would need to configure ldap twice, > | > once for SSO > | > app to authenticate, and the other time for foreman to query > | > user/group > | > information. > | > > | > this means you store the pw twice, and also means that i cant get > | > rid of the > | > ldap related code in foreman. > | > | Why this can't be the same LDAP instance? It would only make sense to > | have one > | DB of users. You are right, LDAP code would have to stay in Foreman > | to gather > | information about users. Unless we implement some REST API in SSO to > | provide > | user information however this is something I'd like to avoid. It > | would result > | in adding another layer that would just translate data. > > my point is, that if you need an account to authenticate to ldap (e.g. plain > users might not have bind rights, or search rights etc), you would need to > store that account password twice. Right but those should be two separate accounts anyway. SSO app should have the lowest privileges possible however Foreman could need access to groups and maybe other stuff. -- Marek From ohadlevy at redhat.com Mon Mar 11 15:03:31 2013 From: ohadlevy at redhat.com (Ohad Levy) Date: Mon, 11 Mar 2013 11:03:31 -0400 (EDT) Subject: [katello-devel] Design of SSO - screencast In-Reply-To: <1570143.ZRVdPhKa9t@edna> Message-ID: <1085923638.12287848.1363014211561.JavaMail.root@redhat.com> ----- Original Message ----- | On Monday 11 of March 2013 08:57:49 you wrote: | > ----- Original Message ----- | > | > | On Monday 11 of March 2013 08:31:27 Ohad Levy wrote: | > | > | > My main concern is that this would not be a drop in | > | > | > replacement | > | > | > for | > | > | > current | > | > | > foreman users, and we would need to maintain multiple SSO | > | > | > backends | > | > | > (e.g. | > | > | > what foreman currently has with Apache) or plain | > | > | > authentication | > | > | > ( | > | > | > e.g. it | > | > | > wont answer get user details ). | > | > | | > | > | I'm not sure whether I get it right but this SSO application | > | > | was | > | > | not | > | > | meant to | > | > | be any replacement. Users would not be forced to use it at | > | > | all. | > | > | It | > | > | should | > | > | allow users only one thing that it's named after - they just | > | > | sign | > | > | in | > | > | once and | > | > | they can use other systems immediately. The only thing that's | > | > | needed | > | > | from | > | > | Foreman point of view is adding support for custom OpenID | > | > | provider. | > | > | | > | > | It's 39 LOC including whitelines and comments. The biggest | > | > | benefit | > | > | would be | > | > | that Katello and Foreman (and maybe other systems) would not | > | > | have | > | > | to | > | > | implement | > | > | various authentication methods separately. It means having | > | > | kerberos, | > | > | LDAP and | > | > | e.g. OpenID authentication on one place and reused by all | > | > | applications. Hence | > | > | you could remove some SSO backends you may already have in | > | > | Foreman. | > | > | | > | > | Does it make sense? What should this SSO solution fulfill to | > | > | meet | > | > | Foreman | > | > | requirements? | > | > | > | > The issue here, is that you would need to configure ldap twice, | > | > once for SSO | > | > app to authenticate, and the other time for foreman to query | > | > user/group | > | > information. | > | > | > | > this means you store the pw twice, and also means that i cant | > | > get | > | > rid of the | > | > ldap related code in foreman. | > | | > | Why this can't be the same LDAP instance? It would only make | > | sense to | > | have one | > | DB of users. You are right, LDAP code would have to stay in | > | Foreman | > | to gather | > | information about users. Unless we implement some REST API in SSO | > | to | > | provide | > | user information however this is something I'd like to avoid. It | > | would result | > | in adding another layer that would just translate data. | > | > my point is, that if you need an account to authenticate to ldap | > (e.g. plain | > users might not have bind rights, or search rights etc), you would | > need to | > store that account password twice. | Right but those should be two separate accounts anyway. SSO app | should have | the lowest privileges possible however Foreman could need access to | groups and | maybe other stuff. I'm not sure thats a valid argument, in any case, you do end up maintaining to sets of code (per provider * Num of Apps using SSO) and also storing the credentials multiple times on different systems in an unencrypted form. I would rather see a more complete solution, where all user based queries are done via that service. Ohad From bkearney at redhat.com Mon Mar 11 15:19:06 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 11 Mar 2013 11:19:06 -0400 Subject: [katello-devel] API V2 format changes In-Reply-To: <5139D1A5.5020502@redhat.com> References: <5138C465.7080807@redhat.com> <5139D1A5.5020502@redhat.com> Message-ID: <513DF5EA.8070407@redhat.com> On 03/08/2013 06:55 AM, Dmitri Dolguikh wrote: > On 07/03/13 04:46 PM, Martin Bacovsky wrote: >> We (Tomas and Martin) are working on API redesign and cleanup. The >> motivation for this is that the practices are not consistent in >> current API which makes UX not pleasant and is causing difficulties >> while creating CLI. In the future it could be possible to autogenerate >> python bindings for Katello and/or parts of the CLI. >> >> Current state >> * nesting of elements is not consistent >> * when use of as_json the representation of entities is >> distributed over the code >> * some results render as text instead of JSON >> >> Our goals: >> * make the transition as simple as possible >> * use RABL for JSON output definition >> * make responses consistent >> * unify error handling >> * make it easy to change the output behaviour from one place >> >> There are some decision that needs to be done. We are looking for >> opinions on following things: >> >> Support messages in 2XX responses? e.g. 'message: "Environment was >> successfully deleted"' > > I think messages are redundant: the client knows the resource it's > accessing, the operation, and can figure out the result based on the > status code. For standard responses, I would agree. FOr errors.. somce context might be nice -- bk From ohadlevy at redhat.com Mon Mar 11 15:34:46 2013 From: ohadlevy at redhat.com (Ohad Levy) Date: Mon, 11 Mar 2013 11:34:46 -0400 (EDT) Subject: [katello-devel] API V2 format changes In-Reply-To: <513DF5EA.8070407@redhat.com> Message-ID: <1889679787.12321344.1363016086944.JavaMail.root@redhat.com> ----- Original Message ----- | On 03/08/2013 06:55 AM, Dmitri Dolguikh wrote: | > On 07/03/13 04:46 PM, Martin Bacovsky wrote: | >> We (Tomas and Martin) are working on API redesign and cleanup. The | >> motivation for this is that the practices are not consistent in | >> current API which makes UX not pleasant and is causing | >> difficulties | >> while creating CLI. In the future it could be possible to | >> autogenerate | >> python bindings for Katello and/or parts of the CLI. | >> | >> Current state | >> * nesting of elements is not consistent | >> * when use of as_json the representation of entities is | >> distributed over the code | >> * some results render as text instead of JSON | >> | >> Our goals: | >> * make the transition as simple as possible | >> * use RABL for JSON output definition | >> * make responses consistent | >> * unify error handling | >> * make it easy to change the output behaviour from one place | >> | >> There are some decision that needs to be done. We are looking for | >> opinions on following things: | >> | >> Support messages in 2XX responses? e.g. 'message: "Environment | >> was | >> successfully deleted"' | > | > I think messages are redundant: the client knows the resource it's | > accessing, the operation, and can figure out the result based on | > the | > status code. | | For standard responses, I would agree. FOr errors.. somce context | might | be nice I think it make sense to introduce error codes as well, maybe this could help with some localization issues, and could also be referenced in documentation? | | -- bk | | _______________________________________________ | katello-devel mailing list | katello-devel at redhat.com | https://www.redhat.com/mailman/listinfo/katello-devel | From daviddavis at redhat.com Mon Mar 11 18:30:27 2013 From: daviddavis at redhat.com (David Davis) Date: Mon, 11 Mar 2013 14:30:27 -0400 (EDT) Subject: [katello-devel] Coverage report In-Reply-To: <1556226327.18211194.1363025058074.JavaMail.root@redhat.com> Message-ID: <1554651353.18227453.1363026627921.JavaMail.root@redhat.com> I took a short break from Content Search today and got the katello-coverage job in Jenkins running again. It's now running with simplecov and Ruby 1.9.3. It checks test coverage against both our minitests and rspec tests. You can access the coverage by going to the katello-coverage job, finding the latest build, and clicking on the "Coverage Report" link. It's scheduled to run every night at 10pm. See this link for an example of the coverage report: http://hudson.rhq.lab.eng.bos.redhat.com:8080/hudson/view/katello/job/katello-coverage/9/Coverage_Report/ David From lzap at redhat.com Tue Mar 12 13:17:04 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 12 Mar 2013 14:17:04 +0100 Subject: [katello-devel] Katello on Torquebox talk Message-ID: <20130312131704.GD1733@lzapx.brq.redhat.com> It's now online. Audio is not good and I'd expect less me and more slides, but it's usable: https://www.youtube.com/watch?v=xecVyZNGFps 45 minutes, enjoy. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Tue Mar 12 13:44:04 2013 From: daviddavis at redhat.com (David Davis) Date: Tue, 12 Mar 2013 09:44:04 -0400 (EDT) Subject: [katello-devel] Katello on Torquebox talk In-Reply-To: <20130312131704.GD1733@lzapx.brq.redhat.com> Message-ID: <1413357170.18652165.1363095844952.JavaMail.root@redhat.com> Thanks. I think your picture of the Katello team predates me. David ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Tuesday, March 12, 2013 9:17:04 AM > Subject: [katello-devel] Katello on Torquebox talk > > It's now online. Audio is not good and I'd expect less me and more > slides, but it's usable: > > https://www.youtube.com/watch?v=xecVyZNGFps > > 45 minutes, enjoy. > > LZ > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From dcleal at redhat.com Tue Mar 12 13:57:26 2013 From: dcleal at redhat.com (Dominic Cleal) Date: Tue, 12 Mar 2013 13:57:26 +0000 Subject: [katello-devel] Fwd: [foreman-dev] Deep dives In-Reply-To: <513F2EE4.20002@redhat.com> References: <513F2EE4.20002@redhat.com> Message-ID: <513F3446.5000703@redhat.com> If you guys have any feedback on topics, it's also appreciated! -------- Original Message -------- Subject: [foreman-dev] Deep dives Date: Tue, 12 Mar 2013 13:34:28 +0000 From: Dominic Cleal Reply-To: foreman-dev at googlegroups.com To: foreman-dev CC: foreman-users Hi all, As you may know, we have been trying to hold semi-regular "deep dive" sessions on Google+ Hangouts on Tuesday afternoons (UTC). The idea is for a developer to concentrate on a single feature of Foreman, explains how it works and passes on the knowledge. We're running a bit short on inspiration, despite there being lots of features in Foreman, so would love some input on what *you'd* like to hear more about. Please add ideas and +1 topics you'd like to this wikip age, or just reply to this thread. http://projects.theforeman.org/projects/foreman/wiki/Upcoming_Deep_Dives For those who hadn't heard about the sessions, you'll find them announced on the Foreman Google+ community: https://plus.google.com/communities/106976851375995577697 And previous records are up here: http://projects.theforeman.org/wiki/foreman/Development_Resources Cheers! -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From daviddavis at redhat.com Tue Mar 12 15:05:54 2013 From: daviddavis at redhat.com (David Davis) Date: Tue, 12 Mar 2013 11:05:54 -0400 (EDT) Subject: [katello-devel] ZenTest Message-ID: <330378008.18732499.1363100754170.JavaMail.root@redhat.com> Hi, We've had a couple problems with ZenTest this past month and I was just curious if anyone was actually using it. If someone is, we can keep it. Otherwise it might be worth removing. Thanks. David From lzap at redhat.com Tue Mar 12 15:06:16 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 12 Mar 2013 16:06:16 +0100 Subject: [katello-devel] State of R19R and Katello In-Reply-To: <20130308120204.GF1730@lzapx.brq.redhat.com> References: <20130308120204.GF1730@lzapx.brq.redhat.com> Message-ID: <20130312150615.GG1733@lzapx.brq.redhat.com> So Katello now starts on SCL RHEL6 stack and also does work! You can start it using the commands bellow. Even thin is ready, so you can modify the startup script to use SCL for thin and try it with Apache httpd. While Mirek is working on Foreman SCL migration, I want to modify our SPEC file to use SCL dependencies. LZ On Fri, Mar 08, 2013 at 01:02:04PM +0100, Lukas Zapletal wrote: > Ok, > > first of all I am **tired** of writing ruby193-rubygem after this week. > Therefore R19R = Ruby 1.9.3 Rails stack (SCL). > > So, yesterday I finally reach the point when Katello actually starts > starting (uh) and fails due to old version of haml. Currently I am > building some nokogiri rubygem dependencies and this is the last Katello > dependency that prevents it from starting. > > It is good progress, it means we have all the dependencies that are > required for the runtime (without katello-devel* packages). At this > point, more folks are able to start testing Katello on R19R. > > If you want to try Katello on R19R stack today, you need to ping me (I > will generate fresh repo for you), then you need to comment out > "anemone" rubygem (nokogiri not yet built - hard one) and then you need > to do this: > > # yum -y install ruby193* > # cd /usr/share/katello > # RAILS_ENV=production scl enable ruby193 "rails s" > > Btw if you try that you will see haml error - I am still building new > rubygem-haml which unfortunately needs bunch of new dependencies (with > native extensions of course). Feel free to hack with it. > > In the thirdparty repo, we have two new scripts: > > import-fedora - pulls a package from fedora 18 git, unpacks, clears .git > directory, adds to thirdparty, tags, adds to koji and submits to koji. > > import-ruby193-fedora - the same but it will do SCL conversion and > blacklist the package for non-RHEL6 platforms > > I made these scripts so we can quickly adopt rubygems from Fedora 18 > branch (we can't use master for some gems because there are new macros > we dont have yet). > > Oh FYI to speedup the process I have turned off automatic repogeneration > which slows down Koji a lot. I will turn it on again 5 PM CET. If you > need nightly today, ping me and I will generate it for you. > > I think I hate writing R19R too on Czech keyboard layout :-) > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From bkearney at redhat.com Tue Mar 12 15:31:29 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 12 Mar 2013 11:31:29 -0400 Subject: [katello-devel] State of R19R and Katello In-Reply-To: <20130312150615.GG1733@lzapx.brq.redhat.com> References: <20130308120204.GF1730@lzapx.brq.redhat.com> <20130312150615.GG1733@lzapx.brq.redhat.com> Message-ID: <513F4A51.4020603@redhat.com> On 03/12/2013 11:06 AM, Lukas Zapletal wrote: > So Katello now starts on SCL RHEL6 stack and also does work! > > You can start it using the commands bellow. > > Even thin is ready, so you can modify the startup script to use SCL for > thin and try it with Apache httpd. > > While Mirek is working on Foreman SCL migration, I want to modify our > SPEC file to use SCL dependencies. > > LZ great! -- bk From inecas at redhat.com Tue Mar 12 15:43:26 2013 From: inecas at redhat.com (Ivan Necas) Date: Tue, 12 Mar 2013 11:43:26 -0400 (EDT) Subject: [katello-devel] ZenTest In-Reply-To: <330378008.18732499.1363100754170.JavaMail.root@redhat.com> Message-ID: <1803297217.17368145.1363103006719.JavaMail.root@redhat.com> ----- Original Message ----- > Hi, > > We've had a couple problems with ZenTest this past month and I was > just curious if anyone was actually using it. If someone is, we can > keep it. Otherwise it might be worth removing. +1 for removing it. If the tests itself don't require ZenTest, people that use it can just keep it in their bundler.d/Gemfile.local.rb file (which we could add to .gitignore). Maybe even more gems are worth moving from our official dev stack (I'm looking at you: newrelic_rpm, ruby-prof etc. :) -- Ivan > > Thanks. > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From daviddavis at redhat.com Tue Mar 12 15:52:23 2013 From: daviddavis at redhat.com (David Davis) Date: Tue, 12 Mar 2013 11:52:23 -0400 (EDT) Subject: [katello-devel] ZenTest In-Reply-To: <1803297217.17368145.1363103006719.JavaMail.root@redhat.com> Message-ID: <1802232171.18775267.1363103543383.JavaMail.root@redhat.com> There's already a gitignore entry for bundler.d/local*.rb in src/.gitignore. I'll take a look at these other gems too. David ----- Original Message ----- > From: "Ivan Necas" > To: "katello-devel" > Sent: Tuesday, March 12, 2013 11:43:26 AM > Subject: Re: [katello-devel] ZenTest > > > > ----- Original Message ----- > > Hi, > > > > We've had a couple problems with ZenTest this past month and I was > > just curious if anyone was actually using it. If someone is, we can > > keep it. Otherwise it might be worth removing. > > +1 for removing it. If the tests itself don't require ZenTest, people > that > use it can just keep it in their bundler.d/Gemfile.local.rb file > (which we could > add to .gitignore). Maybe even more gems are worth moving from our > official dev stack > (I'm looking at you: newrelic_rpm, ruby-prof etc. :) > > -- Ivan > > > > > Thanks. > > > > David > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From inecas at redhat.com Tue Mar 12 15:58:16 2013 From: inecas at redhat.com (Ivan Necas) Date: Tue, 12 Mar 2013 11:58:16 -0400 (EDT) Subject: [katello-devel] ZenTest In-Reply-To: <1802232171.18775267.1363103543383.JavaMail.root@redhat.com> Message-ID: <1771799784.17379847.1363103896658.JavaMail.root@redhat.com> ----- Original Message ----- > There's already a gitignore entry for bundler.d/local*.rb in > src/.gitignore. Right, I must have misspelled it when searching. -- Ivan > > I'll take a look at these other gems too. > > David > > ----- Original Message ----- > > From: "Ivan Necas" > > To: "katello-devel" > > Sent: Tuesday, March 12, 2013 11:43:26 AM > > Subject: Re: [katello-devel] ZenTest > > > > > > > > ----- Original Message ----- > > > Hi, > > > > > > We've had a couple problems with ZenTest this past month and I > > > was > > > just curious if anyone was actually using it. If someone is, we > > > can > > > keep it. Otherwise it might be worth removing. > > > > +1 for removing it. If the tests itself don't require ZenTest, > > people > > that > > use it can just keep it in their bundler.d/Gemfile.local.rb file > > (which we could > > add to .gitignore). Maybe even more gems are worth moving from our > > official dev stack > > (I'm looking at you: newrelic_rpm, ruby-prof etc. :) > > > > -- Ivan > > > > > > > > Thanks. > > > > > > David > > > > > > _______________________________________________ > > > katello-devel mailing list > > > katello-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > From daviddavis at redhat.com Tue Mar 12 17:04:35 2013 From: daviddavis at redhat.com (David Davis) Date: Tue, 12 Mar 2013 13:04:35 -0400 (EDT) Subject: [katello-devel] ZenTest In-Reply-To: <1771799784.17379847.1363103896658.JavaMail.root@redhat.com> Message-ID: <696383570.18825163.1363107875847.JavaMail.root@redhat.com> To sum up, is anyone using any of these gems? ruby-prof newrelic_rpm webrat ZenTest autotest-rails Thanks. David ----- Original Message ----- > From: "Ivan Necas" > To: "katello-devel" > Sent: Tuesday, March 12, 2013 11:58:16 AM > Subject: Re: [katello-devel] ZenTest > > > > ----- Original Message ----- > > There's already a gitignore entry for bundler.d/local*.rb in > > src/.gitignore. > > Right, I must have misspelled it when searching. > > -- Ivan > > > > > I'll take a look at these other gems too. > > > > David > > > > ----- Original Message ----- > > > From: "Ivan Necas" > > > To: "katello-devel" > > > Sent: Tuesday, March 12, 2013 11:43:26 AM > > > Subject: Re: [katello-devel] ZenTest > > > > > > > > > > > > ----- Original Message ----- > > > > Hi, > > > > > > > > We've had a couple problems with ZenTest this past month and I > > > > was > > > > just curious if anyone was actually using it. If someone is, we > > > > can > > > > keep it. Otherwise it might be worth removing. > > > > > > +1 for removing it. If the tests itself don't require ZenTest, > > > people > > > that > > > use it can just keep it in their bundler.d/Gemfile.local.rb file > > > (which we could > > > add to .gitignore). Maybe even more gems are worth moving from > > > our > > > official dev stack > > > (I'm looking at you: newrelic_rpm, ruby-prof etc. :) > > > > > > -- Ivan > > > > > > > > > > > Thanks. > > > > > > > > David > > > > > > > > _______________________________________________ > > > > katello-devel mailing list > > > > katello-devel at redhat.com > > > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > > > > > _______________________________________________ > > > katello-devel mailing list > > > katello-devel at redhat.com > > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From daviddavis at redhat.com Tue Mar 12 20:28:46 2013 From: daviddavis at redhat.com (David Davis) Date: Tue, 12 Mar 2013 16:28:46 -0400 (EDT) Subject: [katello-devel] Fixing Travis In-Reply-To: <494936128.19052152.1363119786929.JavaMail.root@redhat.com> Message-ID: <197815925.19053793.1363120126861.JavaMail.root@redhat.com> Over the weekend our tests in TravisCI started failing. The reason was because the tools rubygems and bundler were updated to 2.0 and 1.3 respectively. The first issue was that ZenTest 4.8.x requires rubygems ~> 1.8. I'm working on maybe removing it or if people are using it, upgrading it to 4.9. The other issue (and here's where I need feedback) is that parallel_tests don't work with bundler 1.3 [1] and unfortunately, each Travis box comes preinstalled with rvm, rubygems, and bundler (and it's not possible to specify versions for these tools in the Travis config). Thus, we have two options: either temporarily disable parallel_tests in Travis [2] or try to manually remove rubygems/bundler and then install the versions we need [3]. Please let me know which solution you'd prefer. Thanks. [1] https://github.com/grosser/parallel_tests/issues/185 [2] https://github.com/Katello/katello/pull/1740 [3] https://github.com/Katello/katello/pull/1739 David From inecas at redhat.com Wed Mar 13 07:11:46 2013 From: inecas at redhat.com (Ivan Necas) Date: Wed, 13 Mar 2013 03:11:46 -0400 (EDT) Subject: [katello-devel] Fixing Travis In-Reply-To: <197815925.19053793.1363120126861.JavaMail.root@redhat.com> Message-ID: <1750496052.17727790.1363158706154.JavaMail.root@redhat.com> ----- Original Message ----- > Over the weekend our tests in TravisCI started failing. The reason > was because the tools rubygems and bundler were updated to 2.0 and > 1.3 respectively. The first issue was that ZenTest 4.8.x requires > rubygems ~> 1.8. I'm working on maybe removing it or if people are > using it, upgrading it to 4.9. > > The other issue (and here's where I need feedback) is that > parallel_tests don't work with bundler 1.3 [1] and unfortunately, > each Travis box comes preinstalled with rvm, rubygems, and bundler > (and it's not possible to specify versions for these tools in the > Travis config). Thus, we have two options: either temporarily > disable parallel_tests in Travis [2] or try to manually remove > rubygems/bundler and then install the versions we need [3]. Depends on how hard it is to remove reubygems/bundler and install our preferred version. If it's hard and requires solid amount of hacking, I'm voting for turning parallel_tests off and perhaps help the upstream with the fix. -- Ivan > Please let me know which solution you'd prefer. > > Thanks. > > [1] https://github.com/grosser/parallel_tests/issues/185 > [2] https://github.com/Katello/katello/pull/1740 > [3] https://github.com/Katello/katello/pull/1739 > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From pchalupa at redhat.com Wed Mar 13 08:00:05 2013 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 13 Mar 2013 09:00:05 +0100 Subject: [katello-devel] Fixing Travis In-Reply-To: <1750496052.17727790.1363158706154.JavaMail.root@redhat.com> References: <1750496052.17727790.1363158706154.JavaMail.root@redhat.com> Message-ID: <51403205.3040600@redhat.com> On 13.03.13 8:11, Ivan Necas wrote: > > > ----- Original Message ----- >> Over the weekend our tests in TravisCI started failing. The reason >> was because the tools rubygems and bundler were updated to 2.0 and >> 1.3 respectively. The first issue was that ZenTest 4.8.x requires >> rubygems ~> 1.8. I'm working on maybe removing it or if people are >> using it, upgrading it to 4.9. +1 for removing zentest (and autotest-rails which depends on zentest), I did not find it in any script, I think it can be removed safely. If needed a developer can use bundler.d/local.rb. >> >> The other issue (and here's where I need feedback) is that >> parallel_tests don't work with bundler 1.3 [1] and unfortunately, >> each Travis box comes preinstalled with rvm, rubygems, and bundler >> (and it's not possible to specify versions for these tools in the >> Travis config). Thus, we have two options: either temporarily >> disable parallel_tests in Travis [2] or try to manually remove >> rubygems/bundler and then install the versions we need [3]. > > Depends on how hard it is to remove reubygems/bundler and install our preferred > version. If it's hard and requires solid amount of hacking, I'm voting for turning > parallel_tests off and perhaps help the upstream with the fix. +1 for switching off temporarily, we need Travis working, there are pull-requests waiting. > > -- Ivan > >> Please let me know which solution you'd prefer. >> >> Thanks. >> >> [1] https://github.com/grosser/parallel_tests/issues/185 >> [2] https://github.com/Katello/katello/pull/1740 >> [3] https://github.com/Katello/katello/pull/1739 >> >> David >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From pchalupa at redhat.com Wed Mar 13 10:06:11 2013 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 13 Mar 2013 11:06:11 +0100 Subject: [katello-devel] Rspec and/or mini-test? In-Reply-To: References: <513A03ED.4090601@redhat.com> <513A076A.9030309@redhat.com> <20130308155419.GD38689@redhat.com> <513B3C6A.3070401@redhat.com> <20130311083237.GB1760@lzapx.brq.redhat.com> Message-ID: <51404F93.1060401@redhat.com> On 11.03.13 10:44, Partha Aji wrote: > > > On Mar 11, 2013, at 2:02 PM, Lukas Zapletal wrote: > >> On Sat, Mar 09, 2013 at 08:43:06AM -0500, Bryan Kearney wrote: >>> Why are we adding a new testing framework? Is it fixing a problem in >>> the current frameworks? >> >> +1 >> >> If we are going to shift from rspec to minitest-rspec, I dont really see >> any added value, except we will get rid of few test-time dependencies. > +1 > I like the xUnit syntax too. > I would be ok with using just minitest as opposed to minitest:rspec I would not limit us to use only MiniTest::Unit::TestCase. MiniTest::Spec are only a thin extension of MiniTest::Unit::TestCase. It maps must_* to assertions, examples to test methods and description blocks to TestCase classes. You can actually use whatever you want, see https://gist.github.com/pitr-ch/dacd2081cc21092c7d2d and it all ends up defined as test methods. +1 for minitest, both forms unit and spec. > > Partha > >> >> Please again, what is the pain we are trying to solve with this? I was >> under impression we don't like rspec syntax and wan't straightforward >> xunit syntax, but I can see this is not the case. >> >> LZ >> >> -- >> Later, >> >> Lukas "lzap" Zapletal > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From bbuckingham at redhat.com Wed Mar 13 11:52:11 2013 From: bbuckingham at redhat.com (Brad Buckingham) Date: Wed, 13 Mar 2013 07:52:11 -0400 Subject: [katello-devel] ZenTest In-Reply-To: <696383570.18825163.1363107875847.JavaMail.root@redhat.com> References: <696383570.18825163.1363107875847.JavaMail.root@redhat.com> Message-ID: <5140686B.2090104@redhat.com> Replying to the email thread since there was a PR opened to removed newrelic/logical-insight. I'm not aware of anyone actively using these; however, I believe they were added as part of a sprint task a long time ago because folks felt the project needed a way to do some basic profiing. If they are removed, we should update the wiki which describes their use on the project ( https://fedorahosted.org/katello/wiki/WebProfiling ) and replace it with what is the recommended approach. thanks, Brad On 03/12/2013 01:04 PM, David Davis wrote: > To sum up, is anyone using any of these gems? > > ruby-prof > newrelic_rpm > webrat > ZenTest > autotest-rails > > Thanks. > > David > > ----- Original Message ----- >> From: "Ivan Necas" >> To: "katello-devel" >> Sent: Tuesday, March 12, 2013 11:58:16 AM >> Subject: Re: [katello-devel] ZenTest >> >> >> >> ----- Original Message ----- >>> There's already a gitignore entry for bundler.d/local*.rb in >>> src/.gitignore. >> Right, I must have misspelled it when searching. >> >> -- Ivan >> >>> I'll take a look at these other gems too. >>> >>> David >>> >>> ----- Original Message ----- >>>> From: "Ivan Necas" >>>> To: "katello-devel" >>>> Sent: Tuesday, March 12, 2013 11:43:26 AM >>>> Subject: Re: [katello-devel] ZenTest >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> Hi, >>>>> >>>>> We've had a couple problems with ZenTest this past month and I >>>>> was >>>>> just curious if anyone was actually using it. If someone is, we >>>>> can >>>>> keep it. Otherwise it might be worth removing. >>>> +1 for removing it. If the tests itself don't require ZenTest, >>>> people >>>> that >>>> use it can just keep it in their bundler.d/Gemfile.local.rb file >>>> (which we could >>>> add to .gitignore). Maybe even more gems are worth moving from >>>> our >>>> official dev stack >>>> (I'm looking at you: newrelic_rpm, ruby-prof etc. :) >>>> >>>> -- Ivan >>>> >>>>> Thanks. >>>>> >>>>> David >>>>> >>>>> _______________________________________________ >>>>> katello-devel mailing list >>>>> katello-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>>> >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From inecas at redhat.com Wed Mar 13 13:18:35 2013 From: inecas at redhat.com (Ivan Necas) Date: Wed, 13 Mar 2013 09:18:35 -0400 (EDT) Subject: [katello-devel] The importance of foreign keys Message-ID: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> Hey, I know this topic appeared here several times but still it doesn't seem to be considered important. Here is an issue that I've hit today [1]: see it's description for more details. This kind of issues is really dangerous because there is generally a time span between the error that uses sees and the moment when the cause happens. (in this case promoting a changeset vs. deleting an environment). We already hit this kind of issues in the past and it's not fun debugging it, especially on the customer side. Therefore, I would like to open this topic again and ask for reconsideration of the priority and ideally make introducing of foreign keys for associations in our db one of the high-priority tasks for next sprint. [1] - https://github.com/Katello/katello/pull/1743 -- Ivan From pchalupa at redhat.com Wed Mar 13 13:37:43 2013 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 13 Mar 2013 14:37:43 +0100 Subject: [katello-devel] The importance of foreign keys In-Reply-To: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> References: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> Message-ID: <51408127.3040803@redhat.com> On 13.03.13 14:18, Ivan Necas wrote: > Hey, > > I know this topic appeared here several times but still it doesn't seem > to be considered important. Here is an issue that I've hit today [1]: see > it's description for more details. > > This kind of issues is really dangerous because there is generally a time > span between the error that uses sees and the moment when the cause happens. > (in this case promoting a changeset vs. deleting an environment). We already > hit this kind of issues in the past and it's not fun debugging it, especially > on the customer side. > > Therefore, I would like to open this topic again and ask for reconsideration > of the priority and ideally make introducing of foreign keys for associations > in our db one of the high-priority tasks for next sprint. This is important. +1 for next sprint. > [1] - https://github.com/Katello/katello/pull/1743 > > -- Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From lzap at redhat.com Wed Mar 13 13:44:43 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 13 Mar 2013 14:44:43 +0100 Subject: [katello-devel] Katello cli tests almost green Message-ID: <20130313134443.GC1735@lzapx.brq.redhat.com> Hey guys, Katello nightly is in better condition due to fix that Dmitri found and delivered yesterday (weird loading issue). So we are green except: Config Templates (all red, permission issues) Foreman::ConfigTemplate is invalid: You do not have permission to create this template Katello Agent (some scheduled actions fail) Provider Import (all fails) Archive failed signature check Systems (some fails) Could not find System If you recently work on these, please check cli tests. https://fedorahosted.org/katello/wiki/TestingHowto#Systemtests -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Mar 13 13:56:37 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 13 Mar 2013 14:56:37 +0100 Subject: [katello-devel] ZenTest In-Reply-To: <1803297217.17368145.1363103006719.JavaMail.root@redhat.com> References: <330378008.18732499.1363100754170.JavaMail.root@redhat.com> <1803297217.17368145.1363103006719.JavaMail.root@redhat.com> Message-ID: <20130313135637.GD1735@lzapx.brq.redhat.com> On Tue, Mar 12, 2013 at 11:43:26AM -0400, Ivan Necas wrote: > use it can just keep it in their bundler.d/Gemfile.local.rb file (which we could > add to .gitignore). Maybe even more gems are worth moving from our official dev stack +1 We should add it there for sure. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Mar 13 13:57:21 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 13 Mar 2013 14:57:21 +0100 Subject: [katello-devel] ZenTest In-Reply-To: <1802232171.18775267.1363103543383.JavaMail.root@redhat.com> References: <1803297217.17368145.1363103006719.JavaMail.root@redhat.com> <1802232171.18775267.1363103543383.JavaMail.root@redhat.com> Message-ID: <20130313135721.GE1735@lzapx.brq.redhat.com> On Tue, Mar 12, 2013 at 11:52:23AM -0400, David Davis wrote: > There's already a gitignore entry for bundler.d/local*.rb in src/.gitignore. > > I'll take a look at these other gems too. Oh! I thought I have seen one. So it is here. Btw maybe we should consider merging the two gitignore files into one... LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Mar 13 13:58:27 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 13 Mar 2013 14:58:27 +0100 Subject: [katello-devel] ZenTest In-Reply-To: <5140686B.2090104@redhat.com> References: <696383570.18825163.1363107875847.JavaMail.root@redhat.com> <5140686B.2090104@redhat.com> Message-ID: <20130313135827.GF1735@lzapx.brq.redhat.com> I am all for removing because I *think* they are slowering things down a lot. Folks can add them to the bundle.d/local* files ... LZ On Wed, Mar 13, 2013 at 07:52:11AM -0400, Brad Buckingham wrote: > Replying to the email thread since there was a PR opened to removed > newrelic/logical-insight. > > I'm not aware of anyone actively using these; however, I believe > they were added as part of a sprint task a long time ago because > folks felt the project needed a way to do some basic profiing. > If they are removed, we should update the wiki which describes their > use on the project ( > https://fedorahosted.org/katello/wiki/WebProfiling ) and replace it > with what is the recommended approach. > > thanks, > Brad > > On 03/12/2013 01:04 PM, David Davis wrote: > >To sum up, is anyone using any of these gems? > > > >ruby-prof > >newrelic_rpm > >webrat > >ZenTest > >autotest-rails > > > >Thanks. > > > >David > > > >----- Original Message ----- > >>From: "Ivan Necas" > >>To: "katello-devel" > >>Sent: Tuesday, March 12, 2013 11:58:16 AM > >>Subject: Re: [katello-devel] ZenTest > >> > >> > >> > >>----- Original Message ----- > >>>There's already a gitignore entry for bundler.d/local*.rb in > >>>src/.gitignore. > >>Right, I must have misspelled it when searching. > >> > >>-- Ivan > >> > >>>I'll take a look at these other gems too. > >>> > >>>David > >>> > >>>----- Original Message ----- > >>>>From: "Ivan Necas" > >>>>To: "katello-devel" > >>>>Sent: Tuesday, March 12, 2013 11:43:26 AM > >>>>Subject: Re: [katello-devel] ZenTest > >>>> > >>>> > >>>> > >>>>----- Original Message ----- > >>>>>Hi, > >>>>> > >>>>>We've had a couple problems with ZenTest this past month and I > >>>>>was > >>>>>just curious if anyone was actually using it. If someone is, we > >>>>>can > >>>>>keep it. Otherwise it might be worth removing. > >>>>+1 for removing it. If the tests itself don't require ZenTest, > >>>>people > >>>>that > >>>>use it can just keep it in their bundler.d/Gemfile.local.rb file > >>>>(which we could > >>>>add to .gitignore). Maybe even more gems are worth moving from > >>>>our > >>>>official dev stack > >>>>(I'm looking at you: newrelic_rpm, ruby-prof etc. :) > >>>> > >>>>-- Ivan > >>>> > >>>>>Thanks. > >>>>> > >>>>>David > >>>>> > >>>>>_______________________________________________ > >>>>>katello-devel mailing list > >>>>>katello-devel at redhat.com > >>>>>https://www.redhat.com/mailman/listinfo/katello-devel > >>>>> > >>>>_______________________________________________ > >>>>katello-devel mailing list > >>>>katello-devel at redhat.com > >>>>https://www.redhat.com/mailman/listinfo/katello-devel > >>>> > >>_______________________________________________ > >>katello-devel mailing list > >>katello-devel at redhat.com > >>https://www.redhat.com/mailman/listinfo/katello-devel > >> > >_______________________________________________ > >katello-devel mailing list > >katello-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Wed Mar 13 14:03:38 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 13 Mar 2013 15:03:38 +0100 Subject: [katello-devel] The importance of foreign keys In-Reply-To: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> References: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> Message-ID: <20130313140338.GG1735@lzapx.brq.redhat.com> I also think it's worth a proof of concept. I really don't know why RoR community resist foreign keys, but apparently defining constraints on the database level is much more easier than keeping this in the codebase. +1 LZ On Wed, Mar 13, 2013 at 09:18:35AM -0400, Ivan Necas wrote: > Hey, > > I know this topic appeared here several times but still it doesn't seem > to be considered important. Here is an issue that I've hit today [1]: see > it's description for more details. > > This kind of issues is really dangerous because there is generally a time > span between the error that uses sees and the moment when the cause happens. > (in this case promoting a changeset vs. deleting an environment). We already > hit this kind of issues in the past and it's not fun debugging it, especially > on the customer side. > > Therefore, I would like to open this topic again and ask for reconsideration > of the priority and ideally make introducing of foreign keys for associations > in our db one of the high-priority tasks for next sprint. > > [1] - https://github.com/Katello/katello/pull/1743 > > -- Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Wed Mar 13 14:21:16 2013 From: daviddavis at redhat.com (David Davis) Date: Wed, 13 Mar 2013 10:21:16 -0400 (EDT) Subject: [katello-devel] ZenTest In-Reply-To: <20130313135721.GE1735@lzapx.brq.redhat.com> Message-ID: <1140155847.19500697.1363184476897.JavaMail.root@redhat.com> +1 David ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, March 13, 2013 9:57:21 AM > Subject: Re: [katello-devel] ZenTest > > On Tue, Mar 12, 2013 at 11:52:23AM -0400, David Davis wrote: > > There's already a gitignore entry for bundler.d/local*.rb in > > src/.gitignore. > > > > I'll take a look at these other gems too. > > Oh! I thought I have seen one. So it is here. > > Btw maybe we should consider merging the two gitignore files into > one... > > LZ > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From daviddavis at redhat.com Wed Mar 13 14:26:38 2013 From: daviddavis at redhat.com (David Davis) Date: Wed, 13 Mar 2013 10:26:38 -0400 (EDT) Subject: [katello-devel] ZenTest In-Reply-To: <20130313135827.GF1735@lzapx.brq.redhat.com> Message-ID: <2138930158.19504119.1363184798382.JavaMail.root@redhat.com> So I did some research into newrelic and logical-insight. First of all, neither works by just following the web profiling wiki page. I was able to get newrelic working after about an hour of hacking. logical-insight on the other hand, I can't get to work and it looks like it's going to be a lost cause since it hasn't been maintained in almost a year and it doesn't support Ruby 1.9 and/or Rails 3.2. I think newrelic would be worth keeping but Petr had a suggestion to turn it on/off using katello.yml. I think this is a good idea as long as we default it to "off". My recommendation would be: 1 - Get newrelic working and update the wiki page. 2 - Have a configuration variable for newrelic. Default to off. 3 - Remove logical-insight from the project completely. There's not much config for logical-insight anyway so no huge loss there. David ----- Original Message ----- > From: "Lukas Zapletal" > To: katello-devel at redhat.com > Sent: Wednesday, March 13, 2013 9:58:27 AM > Subject: Re: [katello-devel] ZenTest > > I am all for removing because I *think* they are slowering things > down a > lot. > > Folks can add them to the bundle.d/local* files ... > > LZ > > On Wed, Mar 13, 2013 at 07:52:11AM -0400, Brad Buckingham wrote: > > Replying to the email thread since there was a PR opened to removed > > newrelic/logical-insight. > > > > I'm not aware of anyone actively using these; however, I believe > > they were added as part of a sprint task a long time ago because > > folks felt the project needed a way to do some basic profiing. > > If they are removed, we should update the wiki which describes > > their > > use on the project ( > > https://fedorahosted.org/katello/wiki/WebProfiling ) and replace it > > with what is the recommended approach. > > > > thanks, > > Brad > > > > On 03/12/2013 01:04 PM, David Davis wrote: > > >To sum up, is anyone using any of these gems? > > > > > >ruby-prof > > >newrelic_rpm > > >webrat > > >ZenTest > > >autotest-rails > > > > > >Thanks. > > > > > >David > > > > > >----- Original Message ----- > > >>From: "Ivan Necas" > > >>To: "katello-devel" > > >>Sent: Tuesday, March 12, 2013 11:58:16 AM > > >>Subject: Re: [katello-devel] ZenTest > > >> > > >> > > >> > > >>----- Original Message ----- > > >>>There's already a gitignore entry for bundler.d/local*.rb in > > >>>src/.gitignore. > > >>Right, I must have misspelled it when searching. > > >> > > >>-- Ivan > > >> > > >>>I'll take a look at these other gems too. > > >>> > > >>>David > > >>> > > >>>----- Original Message ----- > > >>>>From: "Ivan Necas" > > >>>>To: "katello-devel" > > >>>>Sent: Tuesday, March 12, 2013 11:43:26 AM > > >>>>Subject: Re: [katello-devel] ZenTest > > >>>> > > >>>> > > >>>> > > >>>>----- Original Message ----- > > >>>>>Hi, > > >>>>> > > >>>>>We've had a couple problems with ZenTest this past month and I > > >>>>>was > > >>>>>just curious if anyone was actually using it. If someone is, > > >>>>>we > > >>>>>can > > >>>>>keep it. Otherwise it might be worth removing. > > >>>>+1 for removing it. If the tests itself don't require ZenTest, > > >>>>people > > >>>>that > > >>>>use it can just keep it in their bundler.d/Gemfile.local.rb > > >>>>file > > >>>>(which we could > > >>>>add to .gitignore). Maybe even more gems are worth moving from > > >>>>our > > >>>>official dev stack > > >>>>(I'm looking at you: newrelic_rpm, ruby-prof etc. :) > > >>>> > > >>>>-- Ivan > > >>>> > > >>>>>Thanks. > > >>>>> > > >>>>>David > > >>>>> > > >>>>>_______________________________________________ > > >>>>>katello-devel mailing list > > >>>>>katello-devel at redhat.com > > >>>>>https://www.redhat.com/mailman/listinfo/katello-devel > > >>>>> > > >>>>_______________________________________________ > > >>>>katello-devel mailing list > > >>>>katello-devel at redhat.com > > >>>>https://www.redhat.com/mailman/listinfo/katello-devel > > >>>> > > >>_______________________________________________ > > >>katello-devel mailing list > > >>katello-devel at redhat.com > > >>https://www.redhat.com/mailman/listinfo/katello-devel > > >> > > >_______________________________________________ > > >katello-devel mailing list > > >katello-devel at redhat.com > > >https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From mmccune at redhat.com Wed Mar 13 14:34:06 2013 From: mmccune at redhat.com (Mike McCune) Date: Wed, 13 Mar 2013 07:34:06 -0700 Subject: [katello-devel] ZenTest In-Reply-To: <2138930158.19504119.1363184798382.JavaMail.root@redhat.com> References: <2138930158.19504119.1363184798382.JavaMail.root@redhat.com> Message-ID: <51408E5E.4010600@redhat.com> On 03/13/2013 07:26 AM, David Davis wrote: > So I did some research into newrelic and logical-insight. First of all, neither works by just following the web profiling wiki page. I was able to get newrelic working after about an hour of hacking. logical-insight on the other hand, I can't get to work and it looks like it's going to be a lost cause since it hasn't been maintained in almost a year and it doesn't support Ruby 1.9 and/or Rails 3.2. > > I think newrelic would be worth keeping but Petr had a suggestion to turn it on/off using katello.yml. I think this is a good idea as long as we default it to "off". > > My recommendation would be: > > 1 - Get newrelic working and update the wiki page. > 2 - Have a configuration variable for newrelic. Default to off. > 3 - Remove logical-insight from the project completely. There's not much config for logical-insight anyway so no huge loss there. > > David +1 as long as item (1) isn't that hard From daviddavis at redhat.com Wed Mar 13 14:53:08 2013 From: daviddavis at redhat.com (David Davis) Date: Wed, 13 Mar 2013 10:53:08 -0400 (EDT) Subject: [katello-devel] ZenTest In-Reply-To: <51408E5E.4010600@redhat.com> Message-ID: <1742004250.19550445.1363186388645.JavaMail.root@redhat.com> I've already completed all three items and opened a pull request. Please review it and let me know what you all think. Thanks! David ----- Original Message ----- > From: "Mike McCune" > To: "David Davis" > Cc: "Lukas Zapletal" , katello-devel at redhat.com > Sent: Wednesday, March 13, 2013 10:34:06 AM > Subject: Re: [katello-devel] ZenTest > > On 03/13/2013 07:26 AM, David Davis wrote: > > So I did some research into newrelic and logical-insight. First of > > all, neither works by just following the web profiling wiki page. > > I was able to get newrelic working after about an hour of hacking. > > logical-insight on the other hand, I can't get to work and it > > looks like it's going to be a lost cause since it hasn't been > > maintained in almost a year and it doesn't support Ruby 1.9 and/or > > Rails 3.2. > > > > I think newrelic would be worth keeping but Petr had a suggestion > > to turn it on/off using katello.yml. I think this is a good idea > > as long as we default it to "off". > > > > My recommendation would be: > > > > 1 - Get newrelic working and update the wiki page. > > 2 - Have a configuration variable for newrelic. Default to off. > > 3 - Remove logical-insight from the project completely. There's not > > much config for logical-insight anyway so no huge loss there. > > > > David > > +1 as long as item (1) isn't that hard > > From mbacovsk at redhat.com Wed Mar 13 15:28:19 2013 From: mbacovsk at redhat.com (Martin Bacovsky) Date: Wed, 13 Mar 2013 16:28:19 +0100 Subject: [katello-devel] The importance of foreign keys In-Reply-To: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> References: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> Message-ID: <51409B13.80709@redhat.com> On 03/13/2013 02:18 PM, Ivan Necas wrote: > Hey, > > I know this topic appeared here several times but still it doesn't seem > to be considered important. Here is an issue that I've hit today [1]: see > it's description for more details. > > This kind of issues is really dangerous because there is generally a time > span between the error that uses sees and the moment when the cause happens. > (in this case promoting a changeset vs. deleting an environment). We already > hit this kind of issues in the past and it's not fun debugging it, especially > on the customer side. > > Therefore, I would like to open this topic again and ask for reconsideration > of the priority and ideally make introducing of foreign keys for associations > in our db one of the high-priority tasks for next sprint. > > [1] - https://github.com/Katello/katello/pull/1743 > > -- Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel +1 for letting postgres do its job. Aeolus team did the same a few weeks ago, so we can ask there for tips and inspiration... Martin From mmccune at redhat.com Wed Mar 13 16:28:07 2013 From: mmccune at redhat.com (Mike McCune) Date: Wed, 13 Mar 2013 09:28:07 -0700 Subject: [katello-devel] The importance of foreign keys In-Reply-To: <51409B13.80709@redhat.com> References: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> <51409B13.80709@redhat.com> Message-ID: <5140A917.6060702@redhat.com> On 03/13/2013 08:28 AM, Martin Bacovsky wrote: > On 03/13/2013 02:18 PM, Ivan Necas wrote: >> Hey, >> >> I know this topic appeared here several times but still it doesn't seem >> to be considered important. Here is an issue that I've hit today [1]: see >> it's description for more details. >> >> This kind of issues is really dangerous because there is generally a time >> span between the error that uses sees and the moment when the cause happens. >> (in this case promoting a changeset vs. deleting an environment). We already >> hit this kind of issues in the past and it's not fun debugging it, especially >> on the customer side. >> >> Therefore, I would like to open this topic again and ask for reconsideration >> of the priority and ideally make introducing of foreign keys for associations >> in our db one of the high-priority tasks for next sprint. >> >> [1] - https://github.com/Katello/katello/pull/1743 >> >> -- Ivan >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > +1 for letting postgres do its job. Aeolus team did the same a few weeks > ago, so we can ask there for tips and inspiration... > huge +1 no brainer Mike From pchalupa at redhat.com Wed Mar 13 16:39:19 2013 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 13 Mar 2013 17:39:19 +0100 Subject: [katello-devel] ZenTest In-Reply-To: <20130313135721.GE1735@lzapx.brq.redhat.com> References: <1803297217.17368145.1363103006719.JavaMail.root@redhat.com> <1802232171.18775267.1363103543383.JavaMail.root@redhat.com> <20130313135721.GE1735@lzapx.brq.redhat.com> Message-ID: <5140ABB7.1050700@redhat.com> On 13.03.13 14:57, Lukas Zapletal wrote: > On Tue, Mar 12, 2013 at 11:52:23AM -0400, David Davis wrote: >> There's already a gitignore entry for bundler.d/local*.rb in src/.gitignore. >> >> I'll take a look at these other gems too. > > Oh! I thought I have seen one. So it is here. > > Btw maybe we should consider merging the two gitignore files into one... +1 > > LZ > From dmitri at redhat.com Wed Mar 13 16:49:14 2013 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Wed, 13 Mar 2013 16:49:14 +0000 Subject: [katello-devel] The importance of foreign keys In-Reply-To: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> References: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> Message-ID: <5140AE0A.2020800@redhat.com> On 2013-03-13 1:18 PM, Ivan Necas wrote: > Hey, > > I know this topic appeared here several times but still it doesn't seem > to be considered important. Here is an issue that I've hit today [1]: see > it's description for more details. > > This kind of issues is really dangerous because there is generally a time > span between the error that uses sees and the moment when the cause happens. > (in this case promoting a changeset vs. deleting an environment). We already > hit this kind of issues in the past and it's not fun debugging it, especially > on the customer side. > > Therefore, I would like to open this topic again and ask for reconsideration > of the priority and ideally make introducing of foreign keys for associations > in our db one of the high-priority tasks for next sprint. > > [1] - https://github.com/Katello/katello/pull/1743 > > -- Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Agreed, but I would also stress the need for tests around this. -d -------------- next part -------------- An HTML attachment was scrubbed... URL: From tstrachota at redhat.com Thu Mar 14 09:53:02 2013 From: tstrachota at redhat.com (Tomas Strachota) Date: Thu, 14 Mar 2013 10:53:02 +0100 Subject: [katello-devel] The importance of foreign keys In-Reply-To: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> References: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> Message-ID: <51419DFE.7070401@redhat.com> On 03/13/2013 02:18 PM, Ivan Necas wrote: > Hey, > > I know this topic appeared here several times but still it doesn't seem > to be considered important. Here is an issue that I've hit today [1]: see > it's description for more details. > > This kind of issues is really dangerous because there is generally a time > span between the error that uses sees and the moment when the cause happens. > (in this case promoting a changeset vs. deleting an environment). We already > hit this kind of issues in the past and it's not fun debugging it, especially > on the customer side. > > Therefore, I would like to open this topic again and ask for reconsideration > of the priority and ideally make introducing of foreign keys for associations > in our db one of the high-priority tasks for next sprint. > > [1] - https://github.com/Katello/katello/pull/1743 > > -- Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > big +1 T. From msuchy at redhat.com Thu Mar 14 14:33:36 2013 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Thu, 14 Mar 2013 15:33:36 +0100 Subject: [katello-devel] The importance of foreign keys In-Reply-To: <51419DFE.7070401@redhat.com> References: <1596303213.17908929.1363180715931.JavaMail.root@redhat.com> <51419DFE.7070401@redhat.com> Message-ID: <5141DFC0.3000801@redhat.com> On 03/14/2013 10:53 AM, Tomas Strachota wrote: > big +1 n+1 -- Miroslav Suchy Red Hat Systems Management Engineering From kybaker at redhat.com Fri Mar 15 19:17:33 2013 From: kybaker at redhat.com (Kyle Baker) Date: Fri, 15 Mar 2013 15:17:33 -0400 (EDT) Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements In-Reply-To: <1673049368.1645571.1363374916917.JavaMail.root@redhat.com> Message-ID: <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> The design rational as well as high fidelity mock-ups are available on the Katello wiki - https://fedorahosted.org/katello/wiki/Navigation%20Enhancements Kyle Baker --- UX Team Desk 978 392 3116 IRC kylebaker From kybaker at redhat.com Fri Mar 15 21:36:09 2013 From: kybaker at redhat.com (Kyle Baker) Date: Fri, 15 Mar 2013 17:36:09 -0400 (EDT) Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements In-Reply-To: <861702548.15487692.1363380736554.JavaMail.root@redhat.com> Message-ID: <1770696370.1711505.1363383369775.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Kyle Baker" > > To: "katello-devel" > > Sent: Friday, March 15, 2013 3:17:33 PM > > Subject: [katello-devel] Navigation, Organization Switcher, and > > Utilities Design Enhancements > > > > The design rational as well as high fidelity mock-ups are available > > on the Katello wiki - > > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > > > Kyle Baker > > *bleep*ing awesome! So glad we have a UX team (and UI coding > magicians)! +1 > > One thing I mentioned to Eric yesterday was that perhaps we use a > menu style like the customer portal? (See attachment) I like the > idea of being able to perhaps jump to two different styles of the > same page (eg. "Systems - Subscription Status" and "Systems - > Foreman Status"). Yeah you bring up a great point. My original intention when creating the designs was to do very much like what the customer portal has done with respect to the second and third level. When actually doing the mockups the volume of content was really overwhelming - picture double as much content in the menu as the attached picture. The fly-out menus made the most sense for accommodating the volume and making the tool not feel as complex as it is. I think in the future it would be great to do some sort of a hybrid, enhancing the menus to include some of those options maybe even include some user customization with icons and such. I would like to treat this as a separate design exercise as it has the potential to be powerful enough to deserve its own cycle. This will occur sooner rather than later as Foreman utilizes a similar idea using filters as navigation. This will prove to be a big gap in consistency between the two applications. Kyle From thomasmckay at redhat.com Fri Mar 15 20:52:16 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 15 Mar 2013 16:52:16 -0400 (EDT) Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements In-Reply-To: <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> Message-ID: <861702548.15487692.1363380736554.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Kyle Baker" > To: "katello-devel" > Sent: Friday, March 15, 2013 3:17:33 PM > Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements > > The design rational as well as high fidelity mock-ups are available > on the Katello wiki - > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > Kyle Baker *bleep*ing awesome! So glad we have a UX team (and UI coding magicians)! One thing I mentioned to Eric yesterday was that perhaps we use a menu style like the customer portal? (See attachment) I like the idea of being able to perhaps jump to two different styles of the same page (eg. "Systems - Subscription Status" and "Systems - Foreman Status"). -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-Overview - Red Hat Customer Portal - Google Chrome.png Type: image/png Size: 163964 bytes Desc: not available URL: From bkearney at redhat.com Fri Mar 15 22:00:07 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 15 Mar 2013 18:00:07 -0400 Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements In-Reply-To: <1770696370.1711505.1363383369775.JavaMail.root@redhat.com> References: <1770696370.1711505.1363383369775.JavaMail.root@redhat.com> Message-ID: <514399E7.1070108@redhat.com> On 03/15/2013 05:36 PM, Kyle Baker wrote: > > ----- Original Message ----- >> >> >> ----- Original Message ----- >>> From: "Kyle Baker" >>> To: "katello-devel" >>> Sent: Friday, March 15, 2013 3:17:33 PM >>> Subject: [katello-devel] Navigation, Organization Switcher, and >>> Utilities Design Enhancements >>> >>> The design rational as well as high fidelity mock-ups are available >>> on the Katello wiki - >>> https://fedorahosted.org/katello/wiki/Navigation%20Enhancements >>> >>> Kyle Baker >> >> *bleep*ing awesome! So glad we have a UX team (and UI coding >> magicians)! > > +1 > >> >> One thing I mentioned to Eric yesterday was that perhaps we use a >> menu style like the customer portal? (See attachment) I like the >> idea of being able to perhaps jump to two different styles of the >> same page (eg. "Systems - Subscription Status" and "Systems - >> Foreman Status"). > > Yeah you bring up a great point. My original intention when creating the designs was to do very much like what the customer portal has done with respect to the second and third level. When actually doing the mockups the volume of content was really overwhelming - picture double as much content in the menu as the attached picture. The fly-out menus made the most sense for accommodating the volume and making the tool not feel as complex as it is. I think in the future it would be great to do some sort of a hybrid, enhancing the menus to include some of those options maybe even include some user customization with icons and such. I would like to treat this as a separate design exercise as it has the potential to be powerful enough to deserve its own cycle. This will occur sooner rather than later as Foreman utilizes a similar idea using filters as navigation. This will prove to be a big gap in consistency between the two applications. I like it kyle.. looks good! -- bk From jsherril at redhat.com Fri Mar 15 22:33:48 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Fri, 15 Mar 2013 18:33:48 -0400 Subject: [katello-devel] Cross fedora version upgrades Message-ID: <5143A1CC.8060709@redhat.com> Hi All, With the upcoming Katello 1.3 release we are only support RHEL 6 & Fedora 18, which means this is the first katello release that does not continue support across a single Fedora version (Previously fedora 16). Katello 1.2 was released with upgrade instructions, but they did not cover upgrading from Fedora 16 to Fedora 17 (so i am going to assume it was not supported or tested). So keep in mind today that we really do not have an official policy on upgrading across fedora versions. Due to the volatile nature of Fedora upgrades (especially going from fedora 16 to fedora 18 which uses two different upgrade mechanisms), I am proposing to only support upgrades to from Katello 1.2 to 1.3 on RHEL 6. What are people's thoughts on that? Katello 1.3 is somewhat special in that katello 1.2 and 1.3 do not share a fedora version in common, but going forward what are thoughts around either: a) Not supporting upgrades on fedora at all, only supported on RHEL 6 and CentOS 6. b) Not supporting upgrades from/to different versions of fedora (i.e. Katello 1.X to 1.Y is supported on Fedora N, but not from N to N+1) c) Only supporting upgrades from/to different versions of fedora via backup/import of data and certs. Keep in mind that no matter what we choose, we can always re-evaluate our policy due to user requests. To me testing two additional upgrade scenarios is not worth the time unless people actually use these upgrade paths. My Vote is for a) (and here's why). If a user is using katello and wanting to upgrade from one version to another across many months, they are likely to want long term stability. Upgrading your operating system to new major versions ever 6-12 months does not give you long term stability. Most users that are interested in running a katello server in production will not use Fedora simply due to the quick release cycle, they will instead use RHEL or CentOS. which is where I think we need to target our resources. So my vote would be to: - Only support upgrades on RHEL and CentOS - Support CentOS with each release and make sure it works (There are reports that it does not work currently) - Harden our backup/restore guide and utilities Thoughts? -Justin From daviddavis at redhat.com Sun Mar 17 17:47:36 2013 From: daviddavis at redhat.com (David Davis) Date: Sun, 17 Mar 2013 13:47:36 -0400 (EDT) Subject: [katello-devel] parallel_tests Message-ID: <476508369.21040862.1363542456056.JavaMail.root@redhat.com> I submitted a pull request to fix parallel_tests for bundler 1.3: https://github.com/grosser/parallel_tests/pull/187 For those who haven't noticed, we disabled parallel_tests in TravisCI because Travis upgraded to bundler 1.3 which doesn't currently work with bundler 1.3. Travis now takes about 30+ minutes our test suite but after this PR gets merged we can move back to parallel_tests. Thanks. David From lzap at redhat.com Mon Mar 18 10:07:58 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 18 Mar 2013 11:07:58 +0100 Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements In-Reply-To: <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> References: <1673049368.1645571.1363374916917.JavaMail.root@redhat.com> <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> Message-ID: <20130318100758.GF1659@lzapx.brq.redhat.com> It is looking good, I like we are making use of full page width, it looks cleaner, org switcher is on the better position. Improvement. LZ On Fri, Mar 15, 2013 at 03:17:33PM -0400, Kyle Baker wrote: > The design rational as well as high fidelity mock-ups are available on the Katello wiki - https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > Kyle Baker > --- > UX Team > Desk 978 392 3116 > IRC kylebaker > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Mon Mar 18 10:17:34 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 18 Mar 2013 11:17:34 +0100 Subject: [katello-devel] Cross fedora version upgrades In-Reply-To: <5143A1CC.8060709@redhat.com> References: <5143A1CC.8060709@redhat.com> Message-ID: <20130318101734.GG1659@lzapx.brq.redhat.com> On Fri, Mar 15, 2013 at 06:33:48PM -0400, Justin Sherrill wrote: > Due to the volatile nature of Fedora upgrades (especially going from > fedora 16 to fedora 18 which uses two different upgrade mechanisms), > I am proposing to only support upgrades to from Katello 1.2 to 1.3 > on RHEL 6. > > What are people's thoughts on that? When you say support, what do you mean in particular? Because our upgrade scripts are somehow generic, they should work on both. I'd rather prefer to say "we will not test this on Fedoras", but still we should be able to help users running Katello on Fedoras, because not all community users do want to run Katello for "production" setups as you describe bellow. There are some users who want to hack it maybe. > a) Not supporting upgrades on fedora at all, only supported on RHEL > 6 and CentOS 6. > b) Not supporting upgrades from/to different versions of fedora > (i.e. Katello 1.X to 1.Y is supported on Fedora N, but not from N to > N+1) > c) Only supporting upgrades from/to different versions of fedora via > backup/import of data and certs. Well I see one benefit in testing upgrades on Fedoras - we can discover future problems. I can imagine if RHEL7 will use systemd we can expect some headaches in this area and testing upgrades on Fedoras could help us to fix them earlier. Fedoras have new technologies we can expect in upcoming RHEL releases. > Thoughts? What is your motivation to push on dropping upgrade support for Fedoras? Do we have any issues with it? I think we already do have beaker tests for upgrades, it is not any extra work to run them on Fedoras as well as on RHEL6. We can even run them on a daily basis (upgrade latest stable to nightly on all platforms). I would rather keep testing upgrades on Fedoras and recommending users to use RHEL6 or clones if they want to run in production mode with ability to upgrade. But I would not say that "we will not support Fedoras" - I think if someone asks on the chanell, we will do our best to help her or him anyway. I think we are good in this and we need to keep the pace. -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Mon Mar 18 10:22:37 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 18 Mar 2013 11:22:37 +0100 Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements In-Reply-To: <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> References: <1673049368.1645571.1363374916917.JavaMail.root@redhat.com> <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> Message-ID: <20130318102237.GI1659@lzapx.brq.redhat.com> Maybe one comment - I don't like when a down-rolling menu (not sure if this term is right) hides when I leave it with a mouse for fraction of a second. I need to go up again to roll it down. On the last shot on the wiki you have Content -> Sync Management -> Sync Plans. Would it be possible to make menu "bolder"? I mean bigger padding around the menu, so it will be more difficult to "miss it"? Or if this is doable via JavaScript - we could only hide it on a mouse click (not when the mouse leaves the area). JS gurus, opinions? LZ On Fri, Mar 15, 2013 at 03:17:33PM -0400, Kyle Baker wrote: > The design rational as well as high fidelity mock-ups are available on the Katello wiki - https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > Kyle Baker > --- > UX Team > Desk 978 392 3116 > IRC kylebaker > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Mon Mar 18 11:37:02 2013 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 18 Mar 2013 12:37:02 +0100 Subject: [katello-devel] Cross fedora version upgrades In-Reply-To: <5143A1CC.8060709@redhat.com> References: <5143A1CC.8060709@redhat.com> Message-ID: <5146FC5E.8040000@redhat.com> On 03/15/2013 11:33 PM, Justin Sherrill wrote: > Hi All, > > With the upcoming Katello 1.3 release we are only support RHEL 6 & > Fedora 18, which means this is the first katello release that does not > continue support across a single Fedora version (Previously fedora > 16). Katello 1.2 was released with upgrade instructions, but they did > not cover upgrading from Fedora 16 to Fedora 17 (so i am going to assume > it was not supported or tested). So keep in mind today that we really > do not have an official policy on upgrading across fedora versions. > > Due to the volatile nature of Fedora upgrades (especially going from > fedora 16 to fedora 18 which uses two different upgrade mechanisms), I > am proposing to only support upgrades to from Katello 1.2 to 1.3 on RHEL 6. > > What are people's thoughts on that? > > > Katello 1.3 is somewhat special in that katello 1.2 and 1.3 do not share > a fedora version in common, but going forward what are thoughts around > either: > > a) Not supporting upgrades on fedora at all, only supported on RHEL 6 > and CentOS 6. > b) Not supporting upgrades from/to different versions of fedora (i.e. > Katello 1.X to 1.Y is supported on Fedora N, but not from N to N+1) > c) Only supporting upgrades from/to different versions of fedora via > backup/import of data and certs. We are not supporting anything :) Yes we have to support upgrades on RHEL6. I would suggest to not explicitly test CentOS unless there is direct report that it differ from RHEL6 - i.e. that something is broken on Centos while it work on RHEL. I would like to have keep at least one Fedora version in common in future. And threat this upgrade as exception. And upgrade from Katello 1.2 to 1.3 support using backup/restore. And try to promise that in future we will do our best to have one version in common. -- Miroslav Suchy Red Hat Systems Management Engineering From thomasmckay at redhat.com Mon Mar 18 12:01:09 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 18 Mar 2013 08:01:09 -0400 (EDT) Subject: [katello-devel] loosening name restrictions for objects In-Reply-To: <1171330090.15934439.1363607702670.JavaMail.root@redhat.com> Message-ID: <1056994913.15936519.1363608069715.JavaMail.root@redhat.com> Currently, many objects use the KatelloNameFormatValidator which restricts names to "cannot contain characters other than alpha numerals, space, '_', '-'". I'd like to lessen these restrictions to just "cannot contain characters >, <, or /" wherever possible. Proposed changes: src/app/lib/validators/rolename_validator.rb src/app/models/permission.rb src/app/models/sync_plan.rb src/app/models/kt_environment.rb src/app/models/provider.rb src/app/models/content_view_definition.rb src/app/models/content_view.rb src/app/models/gpg_key.rb src/app/models/system_group.rb src/app/models/product.rb src/app/models/activation_key.rb Leave unchanged: src/app/lib/validators/username_validator.rb From bkearney at redhat.com Mon Mar 18 12:03:27 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 18 Mar 2013 08:03:27 -0400 Subject: [katello-devel] loosening name restrictions for objects In-Reply-To: <1056994913.15936519.1363608069715.JavaMail.root@redhat.com> References: <1056994913.15936519.1363608069715.JavaMail.root@redhat.com> Message-ID: <5147028F.6040008@redhat.com> On 03/18/2013 08:01 AM, Tom McKay wrote: > Currently, many objects use the KatelloNameFormatValidator which restricts names to "cannot contain characters other than alpha numerals, space, '_', '-'". I'd like to lessen these restrictions to just "cannot contain characters >, <, or /" wherever possible. > > Proposed changes: > src/app/lib/validators/rolename_validator.rb > src/app/models/permission.rb > src/app/models/sync_plan.rb > src/app/models/kt_environment.rb > src/app/models/provider.rb > src/app/models/content_view_definition.rb > src/app/models/content_view.rb > src/app/models/gpg_key.rb > src/app/models/system_group.rb > src/app/models/product.rb > src/app/models/activation_key.rb > > Leave unchanged: > src/app/lib/validators/username_validator.rb > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > +1 -- bk From jweiss at redhat.com Mon Mar 18 12:14:09 2013 From: jweiss at redhat.com (Jeff Weiss) Date: Mon, 18 Mar 2013 08:14:09 -0400 Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements In-Reply-To: <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> References: <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> Message-ID: <87vc8oj46m.fsf@blinky.jweiss.com> +1 much better! Kyle Baker writes: > The design rational as well as high fidelity mock-ups are available on the Katello wiki - https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > Kyle Baker > --- > UX Team > Desk 978 392 3116 > IRC kylebaker > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Jeff Weiss Principal Quality Assurance Engineer jweiss at redhat.com (919)886-6533 From lzap at redhat.com Mon Mar 18 13:05:40 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 18 Mar 2013 14:05:40 +0100 Subject: [katello-devel] loosening name restrictions for objects In-Reply-To: <5147028F.6040008@redhat.com> References: <1056994913.15936519.1363608069715.JavaMail.root@redhat.com> <5147028F.6040008@redhat.com> Message-ID: <20130318130540.GN1659@lzapx.brq.redhat.com> But can you please add a _system_ test that will check these? Not an unit test, we need a system test that performs this on a real Candlepin instance. We had a regression when Candlepin changed (tightened) format of a field and we was not aware of this. You can use CLI smoke tests for this as we (devs) do not have any own tests. Or you can negotiate this with QA dept :-) +1 On Mon, Mar 18, 2013 at 08:03:27AM -0400, Bryan Kearney wrote: > On 03/18/2013 08:01 AM, Tom McKay wrote: > >Currently, many objects use the KatelloNameFormatValidator which restricts names to "cannot contain characters other than alpha numerals, space, '_', '-'". I'd like to lessen these restrictions to just "cannot contain characters >, <, or /" wherever possible. > > > >Proposed changes: > >src/app/lib/validators/rolename_validator.rb > >src/app/models/permission.rb > >src/app/models/sync_plan.rb > >src/app/models/kt_environment.rb > >src/app/models/provider.rb > >src/app/models/content_view_definition.rb > >src/app/models/content_view.rb > >src/app/models/gpg_key.rb > >src/app/models/system_group.rb > >src/app/models/product.rb > >src/app/models/activation_key.rb > > > >Leave unchanged: > >src/app/lib/validators/username_validator.rb > > > >_______________________________________________ > >katello-devel mailing list > >katello-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/katello-devel > > > +1 > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From jsherril at redhat.com Mon Mar 18 13:47:25 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 18 Mar 2013 09:47:25 -0400 Subject: [katello-devel] Cross fedora version upgrades In-Reply-To: <20130318101734.GG1659@lzapx.brq.redhat.com> References: <5143A1CC.8060709@redhat.com> <20130318101734.GG1659@lzapx.brq.redhat.com> Message-ID: <51471AED.5050901@redhat.com> On 03/18/2013 06:17 AM, Lukas Zapletal wrote: > On Fri, Mar 15, 2013 at 06:33:48PM -0400, Justin Sherrill wrote: >> Due to the volatile nature of Fedora upgrades (especially going from >> fedora 16 to fedora 18 which uses two different upgrade mechanisms), >> I am proposing to only support upgrades to from Katello 1.2 to 1.3 >> on RHEL 6. >> >> What are people's thoughts on that? > When you say support, what do you mean in particular? Test, help users with, and fix bugs with. > > Because our upgrade scripts are somehow generic, they should work on > both. > > I'd rather prefer to say "we will not test this on Fedoras", but still > we should be able to help users running Katello on Fedoras, because not > all community users do want to run Katello for "production" setups as > you describe bellow. There are some users who want to hack it maybe. Do they plan to upgrade across fedora versions? Get stuck on older katello versions? Agreed, the users can try it for themselves and we can say it might work, just that we do not support/test it. > >> a) Not supporting upgrades on fedora at all, only supported on RHEL >> 6 and CentOS 6. >> b) Not supporting upgrades from/to different versions of fedora >> (i.e. Katello 1.X to 1.Y is supported on Fedora N, but not from N to >> N+1) >> c) Only supporting upgrades from/to different versions of fedora via >> backup/import of data and certs. > Well I see one benefit in testing upgrades on Fedoras - we can discover > future problems. I can imagine if RHEL7 will use systemd we can expect > some headaches in this area and testing upgrades on Fedoras could help > us to fix them earlier. Fedoras have new technologies we can expect in > upcoming RHEL releases. Across the same version of fedora or across different versions of fedora? I don't think supporting across different versions will teach us much, across the same version, possibly. >> Thoughts? > What is your motivation to push on dropping upgrade support for Fedoras? > Do we have any issues with it? The main concern (as release nanny of Katello 1.3), was we have not in the past supported (tested, documented) upgrades across fedora releases. For 1.3, however if this is the case there would not be any supported upgrade path on fedora. I was trying to determine if that is acceptable, and to nail down a policy going forward. > I think we already do have beaker tests for upgrades, it is not any > extra work to run them on Fedoras as well as on RHEL6. We can even run > them on a daily basis (upgrade latest stable to nightly on all > platforms). Not across fedora versions I'm guessing. Is this also testing that everything is actually functional after the upgrade? (i.e. system registration, rpm downloading all works?) > > I would rather keep testing upgrades on Fedoras and recommending users > to use RHEL6 or clones if they want to run in production mode with > ability to upgrade. But I would not say that "we will not support > Fedoras" - I think if someone asks on the chanell, we will do our best > to help her or him anyway. I think we are good in this and we need to > keep the pace. If we're putting the work into testing upgrades on Fedora, why recommend they use something else? -Justin From jsherril at redhat.com Mon Mar 18 14:11:18 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 18 Mar 2013 10:11:18 -0400 Subject: [katello-devel] Cross fedora version upgrades In-Reply-To: <5146FC5E.8040000@redhat.com> References: <5143A1CC.8060709@redhat.com> <5146FC5E.8040000@redhat.com> Message-ID: <51472086.7070607@redhat.com> On 03/18/2013 07:37 AM, Miroslav Such? wrote: > On 03/15/2013 11:33 PM, Justin Sherrill wrote: >> Hi All, >> >> With the upcoming Katello 1.3 release we are only support RHEL 6 & >> Fedora 18, which means this is the first katello release that does not >> continue support across a single Fedora version (Previously fedora >> 16). Katello 1.2 was released with upgrade instructions, but they did >> not cover upgrading from Fedora 16 to Fedora 17 (so i am going to assume >> it was not supported or tested). So keep in mind today that we really >> do not have an official policy on upgrading across fedora versions. >> >> Due to the volatile nature of Fedora upgrades (especially going from >> fedora 16 to fedora 18 which uses two different upgrade mechanisms), I >> am proposing to only support upgrades to from Katello 1.2 to 1.3 on >> RHEL 6. >> >> What are people's thoughts on that? >> >> >> Katello 1.3 is somewhat special in that katello 1.2 and 1.3 do not share >> a fedora version in common, but going forward what are thoughts around >> either: >> >> a) Not supporting upgrades on fedora at all, only supported on RHEL 6 >> and CentOS 6. >> b) Not supporting upgrades from/to different versions of fedora (i.e. >> Katello 1.X to 1.Y is supported on Fedora N, but not from N to N+1) >> c) Only supporting upgrades from/to different versions of fedora via >> backup/import of data and certs. > > > We are not supporting anything :) > > Oh we aren't supporting anything? Why do we continue to release software? fix bugs? have an irc channel? Have mailing lists? Lets shut it all down!! If we do not plan to support the software we ship in the community then should shut it down now and concede that we will never succeed. You might have a different definition of what support means, but for an open source project it means the following: - Backport major bug fixes to minor releases - Fix security releases in major and minor releases - Help users with issues through reasonable channels (irc, mailing list) We haven't really done the 1st item because we really don't have many users yet to report major issues. We haven't done the 2nd item because we haven't really had any reported security vulnerabilities against our code. In a recent security vulnerability, our internal security group asked if the issue was in a released version of katello and they were very concerned if it was (it was not). Think about any popular open source project, they all do the above three items. There is no reason we shouldn't as well. I think you may misunderstand the meaning of 'support' within an open source software community. YES we do support something, if we don't then we we should never plan on having any users. > Yes we have to support upgrades on RHEL6. I would suggest to not > explicitly test CentOS unless there is direct report that it differ > from RHEL6 - i.e. that something is broken on Centos while it work on > RHEL. There is a direct report, and i don't think its too hard to test a simple install for each katello release. We could then list this as a supported platform. > > I would like to have keep at least one Fedora version in common in > future. And threat this upgrade as exception. > And upgrade from Katello 1.2 to 1.3 support using backup/restore. And > try to promise that in future we will do our best to have one version > in common. Why? I outlined a case for not doing so, that to me makes perfect logical sense. I don't want us to do things for the sake of doing things when no one is going to use them. So at least provide some reasoning? I was hoping a user would reply and say "I would use this", or "I wouldn't use this", but so far they have not. If they do not then why support & test it? -Justin From jsherril at redhat.com Mon Mar 18 14:19:02 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 18 Mar 2013 10:19:02 -0400 Subject: [katello-devel] loosening name restrictions for objects In-Reply-To: <20130318130540.GN1659@lzapx.brq.redhat.com> References: <1056994913.15936519.1363608069715.JavaMail.root@redhat.com> <5147028F.6040008@redhat.com> <20130318130540.GN1659@lzapx.brq.redhat.com> Message-ID: <51472256.5040805@redhat.com> On 03/18/2013 09:05 AM, Lukas Zapletal wrote: > But can you please add a _system_ test that will check these? > > Not an unit test, we need a system test that performs this on a real > Candlepin instance. We had a regression when Candlepin changed > (tightened) format of a field and we was not aware of this. Alternatively you could write a minitest test using vcr to test on real backend systems. -Justin > > You can use CLI smoke tests for this as we (devs) do not have any own > tests. Or you can negotiate this with QA dept :-) > > +1 > > On Mon, Mar 18, 2013 at 08:03:27AM -0400, Bryan Kearney wrote: >> On 03/18/2013 08:01 AM, Tom McKay wrote: >>> Currently, many objects use the KatelloNameFormatValidator which restricts names to "cannot contain characters other than alpha numerals, space, '_', '-'". I'd like to lessen these restrictions to just "cannot contain characters>,<, or /" wherever possible. >>> >>> Proposed changes: >>> src/app/lib/validators/rolename_validator.rb >>> src/app/models/permission.rb >>> src/app/models/sync_plan.rb >>> src/app/models/kt_environment.rb >>> src/app/models/provider.rb >>> src/app/models/content_view_definition.rb >>> src/app/models/content_view.rb >>> src/app/models/gpg_key.rb >>> src/app/models/system_group.rb >>> src/app/models/product.rb >>> src/app/models/activation_key.rb >>> >>> Leave unchanged: >>> src/app/lib/validators/username_validator.rb >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> +1 >> >> -- bk >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Mon Mar 18 14:41:23 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 18 Mar 2013 15:41:23 +0100 Subject: [katello-devel] Cross fedora version upgrades In-Reply-To: <51472086.7070607@redhat.com> References: <5143A1CC.8060709@redhat.com> <5146FC5E.8040000@redhat.com> <51472086.7070607@redhat.com> Message-ID: <20130318144123.GP1659@lzapx.brq.redhat.com> Guys I think we are discussing "future issue". Why not to keep the current state and if we encounter any upgrade issues, let's solve it. Also - moving int. LZ On Mon, Mar 18, 2013 at 10:11:18AM -0400, Justin Sherrill wrote: > On 03/18/2013 07:37 AM, Miroslav Such? wrote: > >On 03/15/2013 11:33 PM, Justin Sherrill wrote: > >>Hi All, > >> > >>With the upcoming Katello 1.3 release we are only support RHEL 6 & > >>Fedora 18, which means this is the first katello release that does not > >>continue support across a single Fedora version (Previously fedora > >>16). Katello 1.2 was released with upgrade instructions, but they did > >>not cover upgrading from Fedora 16 to Fedora 17 (so i am going to assume > >>it was not supported or tested). So keep in mind today that we really > >>do not have an official policy on upgrading across fedora versions. > >> > >>Due to the volatile nature of Fedora upgrades (especially going from > >>fedora 16 to fedora 18 which uses two different upgrade mechanisms), I > >>am proposing to only support upgrades to from Katello 1.2 to 1.3 > >>on RHEL 6. > >> > >>What are people's thoughts on that? > >> > >> > >>Katello 1.3 is somewhat special in that katello 1.2 and 1.3 do not share > >>a fedora version in common, but going forward what are thoughts around > >>either: > >> > >>a) Not supporting upgrades on fedora at all, only supported on RHEL 6 > >>and CentOS 6. > >>b) Not supporting upgrades from/to different versions of fedora (i.e. > >>Katello 1.X to 1.Y is supported on Fedora N, but not from N to N+1) > >>c) Only supporting upgrades from/to different versions of fedora via > >>backup/import of data and certs. > > > > > > We are not supporting anything :) > > > > > > Oh we aren't supporting anything? Why do we continue to release > software? fix bugs? have an irc channel? Have mailing lists? Lets > shut it all down!! > > > > If we do not plan to support the software we ship in the > community then should shut it down now and concede that we will > never succeed. You might have a different definition of what > support means, but for an open source project it means the > following: > > - Backport major bug fixes to minor releases > - Fix security releases in major and minor releases > - Help users with issues through reasonable channels (irc, mailing list) > > We haven't really done the 1st item because we really don't have > many users yet to report major issues. We haven't done the 2nd item > because we haven't really had any reported security vulnerabilities > against our code. In a recent security vulnerability, our internal > security group asked if the issue was in a released version of > katello and they were very concerned if it was (it was not). > > Think about any popular open source project, they all do the above > three items. There is no reason we shouldn't as well. > > > > I think you may misunderstand the meaning of 'support' within an > open source software community. YES we do support something, if we > don't then we we should never plan on having any users. > > > >Yes we have to support upgrades on RHEL6. I would suggest to not > >explicitly test CentOS unless there is direct report that it > >differ from RHEL6 - i.e. that something is broken on Centos while > >it work on RHEL. > There is a direct report, and i don't think its too hard to test a > simple install for each katello release. We could then list this as > a supported platform. > > > > >I would like to have keep at least one Fedora version in common in > >future. And threat this upgrade as exception. > >And upgrade from Katello 1.2 to 1.3 support using backup/restore. > >And try to promise that in future we will do our best to have one > >version in common. > > Why? I outlined a case for not doing so, that to me makes perfect > logical sense. I don't want us to do things for the sake of doing > things when no one is going to use them. So at least provide some > reasoning? I was hoping a user would reply and say "I would use > this", or "I wouldn't use this", but so far they have not. If they > do not then why support & test it? > > -Justin > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From thomasmckay at redhat.com Mon Mar 18 14:46:10 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 18 Mar 2013 10:46:10 -0400 (EDT) Subject: [katello-devel] loosening name restrictions for objects In-Reply-To: <51472256.5040805@redhat.com> Message-ID: <196293270.16013311.1363617970397.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Justin Sherrill" > To: katello-devel at redhat.com > Sent: Monday, March 18, 2013 10:19:02 AM > Subject: Re: [katello-devel] loosening name restrictions for objects > > On 03/18/2013 09:05 AM, Lukas Zapletal wrote: > > But can you please add a _system_ test that will check these? > > > > Not an unit test, we need a system test that performs this on a > > real > > Candlepin instance. We had a regression when Candlepin changed > > (tightened) format of a field and we was not aware of this. > Alternatively you could write a minitest test using vcr to test on > real > backend systems. > > -Justin Yes, I will add minitest w/ vcr for this. > > > > > You can use CLI smoke tests for this as we (devs) do not have any > > own > > tests. Or you can negotiate this with QA dept :-) > > > > +1 > > > > On Mon, Mar 18, 2013 at 08:03:27AM -0400, Bryan Kearney wrote: > >> On 03/18/2013 08:01 AM, Tom McKay wrote: > >>> Currently, many objects use the KatelloNameFormatValidator which > >>> restricts names to "cannot contain characters other than alpha > >>> numerals, space, '_', '-'". I'd like to lessen these > >>> restrictions to just "cannot contain characters>,<, or /" > >>> wherever possible. > >>> > >>> Proposed changes: > >>> src/app/lib/validators/rolename_validator.rb > >>> src/app/models/permission.rb > >>> src/app/models/sync_plan.rb > >>> src/app/models/kt_environment.rb > >>> src/app/models/provider.rb > >>> src/app/models/content_view_definition.rb > >>> src/app/models/content_view.rb > >>> src/app/models/gpg_key.rb > >>> src/app/models/system_group.rb > >>> src/app/models/product.rb > >>> src/app/models/activation_key.rb > >>> > >>> Leave unchanged: > >>> src/app/lib/validators/username_validator.rb > >>> > >>> _______________________________________________ > >>> katello-devel mailing list > >>> katello-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/katello-devel > >>> > >> +1 > >> > >> -- bk > >> > >> _______________________________________________ > >> katello-devel mailing list > >> katello-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From msuchy at redhat.com Mon Mar 18 15:07:45 2013 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Mon, 18 Mar 2013 16:07:45 +0100 Subject: [katello-devel] Cross fedora version upgrades In-Reply-To: <51472086.7070607@redhat.com> References: <5143A1CC.8060709@redhat.com> <5146FC5E.8040000@redhat.com> <51472086.7070607@redhat.com> Message-ID: <51472DC1.5090203@redhat.com> On 03/18/2013 03:11 PM, Justin Sherrill wrote: > I don't want us to do things for the sake of doing things when no one is > going to use them. I think people use Katello on Fedora. But of course I have no proof for that :) -- Miroslav Suchy Red Hat Systems Management Engineering From mmccune at redhat.com Mon Mar 18 15:12:55 2013 From: mmccune at redhat.com (Mike McCune) Date: Mon, 18 Mar 2013 08:12:55 -0700 Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements In-Reply-To: <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> References: <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> Message-ID: <51472EF7.8000601@redhat.com> On 03/15/2013 12:17 PM, Kyle Baker wrote: > The design rational as well as high fidelity mock-ups are available on the Katello wiki - https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > thanks for the fresh perspective on Katello's nav, some comments: * We lose the ability to see where you are in the 2nd level nav now, so if you are in 'Content' you have no idea where within Content that you are. How it is now: http://mmccune.fedorapeople.org/scratch/katello-nav1.png but with your redesign, as with Foreman you lose your 2nd level nav when you are within any given page. I think the 2nd level nav is valuable and prefer we don't go back to a nav structure that doesn't indicate where you are within the site. * This doesn't address one of the main issues we had with the Settings (site wide) pages: You don't have any context in the nav when you are viewing a Settings page. The nav remains un-highlighted. The current setup we have with the strange "Back" button does try to address this, although in a very ineffective way, you do know *where* you are within the settings pages. Perhaps I'm getting too hung up on this issue and all we ever really need to indicate in the navigation is where you are only at the top level (1st level nav highlighting only)... * It looks like you took Foreman's navigation style and applied it to Katello, negating Alchemy, which Foreman just worked to integrate into their UI? The sticking point for me is that I think of a navigation widget as a way to make it easy to know where you are now and also what else is available near by. So perhaps instead of doing the vertical drop lists for each 1st level nav we still offer a 2nd level nav that is 'sticky' when you are in a page but adopt the full-width navigation style you are offering here. I'm still not entirely sure how to solve the crux of the issue around providing context when you are in a Settings page and continuing to support the stick 1st and 2nd level navigation widget. Mike -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650-254-4248 From ericdhelms at gmail.com Mon Mar 18 15:28:25 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Mon, 18 Mar 2013 11:28:25 -0400 Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements In-Reply-To: <51472EF7.8000601@redhat.com> References: <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> <51472EF7.8000601@redhat.com> Message-ID: On Mon, Mar 18, 2013 at 11:12 AM, Mike McCune wrote: > On 03/15/2013 12:17 PM, Kyle Baker wrote: > >> The design rational as well as high fidelity mock-ups are available on >> the Katello wiki - https://fedorahosted.org/**katello/wiki/Navigation%** >> 20Enhancements >> >> > thanks for the fresh perspective on Katello's nav, some comments: > > * We lose the ability to see where you are in the 2nd level nav now, so if > you are in 'Content' you have no idea where within Content that you are. > How it is now: > > http://mmccune.fedorapeople.**org/scratch/katello-nav1.png > > but with your redesign, as with Foreman you lose your 2nd level nav when > you are within any given page. I think the 2nd level nav is valuable and > prefer we don't go back to a nav structure that doesn't indicate where you > are within the site. > > * This doesn't address one of the main issues we had with the Settings > (site wide) pages: > > You don't have any context in the nav when you are viewing a Settings > page. The nav remains un-highlighted. The current setup we have with the > strange "Back" button does try to address this, although in a very > ineffective way, you do know *where* you are within the settings pages. > Perhaps I'm getting too hung up on this issue and all we ever really need > to indicate in the navigation is where you are only at the top level (1st > level nav highlighting only)... > Looking back at this high fidelity mocks, there appear to be a few states of the nav missing that were in some initial wireframes. For example, when on the settings page , that menu item would be highlighted just like the rest. There was an idea of doing the same style sub-nav we have now but anchored underneath the header. As well as pop-up notifications becoming a similarly anchored entity that appear below the header. The questions I think becomes: - are we just stacking too much in the header at that point? - is there a simpler way to reflect where you are currently? Maybe indicating within the active tab the sub-tab. - most applications I can think of that display your current sub-navigation position use a left hand menu, should we think about that as an addition? > * It looks like you took Foreman's navigation style and applied it to > Katello, negating Alchemy, which Foreman just worked to integrate into > their UI? I can at least speak to this point in so much that some of the changes here reflect a number of conversations and design discussions that we have been working towards in Alchemy. The priority always got pushed back by other work, but the slimmer, more reactive header has been a goal and whatever the final work presented here would be translated over to Alchemy. > > > The sticking point for me is that I think of a navigation widget as a way > to make it easy to know where you are now and also what else is available > near by. > > So perhaps instead of doing the vertical drop lists for each 1st level nav > we still offer a 2nd level nav that is 'sticky' when you are in a page but > adopt the full-width navigation style you are offering here. > > I'm still not entirely sure how to solve the crux of the issue around > providing context when you are in a Settings page and continuing to support > the stick 1st and 2nd level navigation widget. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkearney at redhat.com Mon Mar 18 15:54:10 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 18 Mar 2013 11:54:10 -0400 Subject: [katello-devel] Cross fedora version upgrades In-Reply-To: <51471AED.5050901@redhat.com> References: <5143A1CC.8060709@redhat.com> <20130318101734.GG1659@lzapx.brq.redhat.com> <51471AED.5050901@redhat.com> Message-ID: <514738A2.6030302@redhat.com> On 03/18/2013 09:47 AM, Justin Sherrill wrote: > On 03/18/2013 06:17 AM, Lukas Zapletal wrote: >> On Fri, Mar 15, 2013 at 06:33:48PM -0400, Justin Sherrill wrote: >>> Due to the volatile nature of Fedora upgrades (especially going from >>> fedora 16 to fedora 18 which uses two different upgrade mechanisms), >>> I am proposing to only support upgrades to from Katello 1.2 to 1.3 >>> on RHEL 6. >>> >>> What are people's thoughts on that? >> When you say support, what do you mean in particular? > Test, help users with, and fix bugs with. > >> >> Because our upgrade scripts are somehow generic, they should work on >> both. >> >> I'd rather prefer to say "we will not test this on Fedoras", but still >> we should be able to help users running Katello on Fedoras, because not >> all community users do want to run Katello for "production" setups as >> you describe bellow. There are some users who want to hack it maybe. > > Do they plan to upgrade across fedora versions? Get stuck on older > katello versions? Agreed, the users can try it for themselves and we > can say it might work, just that we do not support/test it. > >> >>> a) Not supporting upgrades on fedora at all, only supported on RHEL >>> 6 and CentOS 6. >>> b) Not supporting upgrades from/to different versions of fedora >>> (i.e. Katello 1.X to 1.Y is supported on Fedora N, but not from N to >>> N+1) >>> c) Only supporting upgrades from/to different versions of fedora via >>> backup/import of data and certs. >> Well I see one benefit in testing upgrades on Fedoras - we can discover >> future problems. I can imagine if RHEL7 will use systemd we can expect >> some headaches in this area and testing upgrades on Fedoras could help >> us to fix them earlier. Fedoras have new technologies we can expect in >> upcoming RHEL releases. > Across the same version of fedora or across different versions of > fedora? I don't think supporting across different versions will teach > us much, across the same version, possibly. > >>> Thoughts? >> What is your motivation to push on dropping upgrade support for Fedoras? >> Do we have any issues with it? > The main concern (as release nanny of Katello 1.3), was we have not in > the past supported (tested, documented) upgrades across fedora > releases. For 1.3, however if this is the case there would not be any > supported upgrade path on fedora. I was trying to determine if that is > acceptable, and to nail down a policy going forward. > >> I think we already do have beaker tests for upgrades, it is not any >> extra work to run them on Fedoras as well as on RHEL6. We can even run >> them on a daily basis (upgrade latest stable to nightly on all >> platforms). > Not across fedora versions I'm guessing. Is this also testing that > everything is actually functional after the upgrade? (i.e. system > registration, rpm downloading all works?) >> >> I would rather keep testing upgrades on Fedoras and recommending users >> to use RHEL6 or clones if they want to run in production mode with >> ability to upgrade. But I would not say that "we will not support >> Fedoras" - I think if someone asks on the chanell, we will do our best >> to help her or him anyway. I think we are good in this and we need to >> keep the pace. > If we're putting the work into testing upgrades on Fedora, why recommend > they use something else? > > I am fine with saying we will help out, but have not tested it internally. -- bk From jsherril at redhat.com Mon Mar 18 16:32:33 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 18 Mar 2013 12:32:33 -0400 Subject: [katello-devel] Cross fedora version upgrades In-Reply-To: <51472DC1.5090203@redhat.com> References: <5143A1CC.8060709@redhat.com> <5146FC5E.8040000@redhat.com> <51472086.7070607@redhat.com> <51472DC1.5090203@redhat.com> Message-ID: <514741A1.4060508@redhat.com> On 03/18/2013 11:07 AM, Miroslav Such? wrote: > On 03/18/2013 03:11 PM, Justin Sherrill wrote: >> I don't want us to do things for the sake of doing things when no one is >> going to use them. > > I think people use Katello on Fedora. But of course I have no proof > for that :) > Oh I am sure they do to, the question is, would they want to run their production instance that should last several years across different katello versions on fedora. Would you do that? I certainly wouldn't. -Justin From mmccune at redhat.com Mon Mar 18 17:08:08 2013 From: mmccune at redhat.com (Mike McCune) Date: Mon, 18 Mar 2013 10:08:08 -0700 Subject: [katello-devel] Navigation, Organization Switcher, and Utilities Design Enhancements In-Reply-To: References: <1043423361.1646240.1363375053790.JavaMail.root@redhat.com> <51472EF7.8000601@redhat.com> Message-ID: <514749F8.4070100@redhat.com> On 03/18/2013 08:28 AM, Eric D Helms wrote: > > > > On Mon, Mar 18, 2013 at 11:12 AM, Mike McCune > wrote: > > On 03/15/2013 12:17 PM, Kyle Baker wrote: > > The design rational as well as high fidelity mock-ups are > available on the Katello wiki - > https://fedorahosted.org/__katello/wiki/Navigation%__20Enhancements > > > > thanks for the fresh perspective on Katello's nav, some comments: > > * We lose the ability to see where you are in the 2nd level nav now, > so if you are in 'Content' you have no idea where within Content > that you are. How it is now: > > http://mmccune.fedorapeople.__org/scratch/katello-nav1.png > > > but with your redesign, as with Foreman you lose your 2nd level nav > when you are within any given page. I think the 2nd level nav is > valuable and prefer we don't go back to a nav structure that doesn't > indicate where you are within the site. > > * This doesn't address one of the main issues we had with the > Settings (site wide) pages: > > You don't have any context in the nav when you are viewing a > Settings page. The nav remains un-highlighted. The current setup > we have with the strange "Back" button does try to address this, > although in a very ineffective way, you do know *where* you are > within the settings pages. Perhaps I'm getting too hung up on this > issue and all we ever really need to indicate in the navigation is > where you are only at the top level (1st level nav highlighting only)... > > > Looking back at this high fidelity mocks, there appear to be a few > states of the nav missing that were in some initial wireframes. For > example, when on the settings page , that menu item would be highlighted > just like the rest. There was an idea of doing the same style sub-nav > we have now but anchored underneath the header. As well as pop-up > notifications becoming a similarly anchored entity that appear below the > header. The questions I think becomes: > > - are we just stacking too much in the header at that point? > - is there a simpler way to reflect where you are currently? Maybe > indicating within the active tab the sub-tab. > - most applications I can think of that display your current > sub-navigation position use a left hand menu, should we think about that > as an addition? > > good to hear that the mocks were missing a piece I pointed out above. Perhaps a left/right nav would be better instead of taking up the vertical space required for our current 2nd level nav. > * It looks like you took Foreman's navigation style and applied it > to Katello, negating Alchemy, which Foreman just worked to integrate > into their UI? > > > I can at least speak to this point in so much that some of the changes > here reflect a number of conversations and design discussions that we > have been working towards in Alchemy. The priority always got pushed > back by other work, but the slimmer, more reactive header has been a > goal and whatever the final work presented here would be translated over > to Alchemy. cool, good to hear. Mike From lzap at redhat.com Mon Mar 18 18:41:17 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 18 Mar 2013 19:41:17 +0100 Subject: [katello-devel] loosening name restrictions for objects In-Reply-To: <51472256.5040805@redhat.com> References: <1056994913.15936519.1363608069715.JavaMail.root@redhat.com> <5147028F.6040008@redhat.com> <20130318130540.GN1659@lzapx.brq.redhat.com> <51472256.5040805@redhat.com> Message-ID: <20130318184117.GA25140@lzapx.brq.redhat.com> On Mon, Mar 18, 2013 at 10:19:02AM -0400, Justin Sherrill wrote: > Alternatively you could write a minitest test using vcr to test on > real backend systems. By the way, do we run them regularly to see regressions? LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From jsherril at redhat.com Mon Mar 18 18:46:14 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 18 Mar 2013 14:46:14 -0400 Subject: [katello-devel] loosening name restrictions for objects In-Reply-To: <20130318184117.GA25140@lzapx.brq.redhat.com> References: <1056994913.15936519.1363608069715.JavaMail.root@redhat.com> <5147028F.6040008@redhat.com> <20130318130540.GN1659@lzapx.brq.redhat.com> <51472256.5040805@redhat.com> <20130318184117.GA25140@lzapx.brq.redhat.com> Message-ID: <514760F6.6070500@redhat.com> On 03/18/2013 02:41 PM, Lukas Zapletal wrote: > On Mon, Mar 18, 2013 at 10:19:02AM -0400, Justin Sherrill wrote: >> Alternatively you could write a minitest test using vcr to test on >> real backend systems. > By the way, do we run them regularly to see regressions? > > LZ > Anytime we import a new version of pulp into koji for nightly builds we run the vcr tests against the new version of pulp. We first run the runcible tests in all (live) mode, and then we run the katello tests in all mode. It greatly helps finding issues both on our side and new bugs that have popped up. We do need to make sure to do that against candlepin, since we have vcr tests now. So that should be a requirement before importing a new version into nightly. -Justin From lzap at redhat.com Mon Mar 18 19:37:01 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Mon, 18 Mar 2013 20:37:01 +0100 Subject: [katello-devel] loosening name restrictions for objects In-Reply-To: <514760F6.6070500@redhat.com> References: <1056994913.15936519.1363608069715.JavaMail.root@redhat.com> <5147028F.6040008@redhat.com> <20130318130540.GN1659@lzapx.brq.redhat.com> <51472256.5040805@redhat.com> <20130318184117.GA25140@lzapx.brq.redhat.com> <514760F6.6070500@redhat.com> Message-ID: <20130318193700.GB25140@lzapx.brq.redhat.com> Is this test runnable from an RPM installation? If so, we can create a Beaker job to do this every day... LZ On Mon, Mar 18, 2013 at 02:46:14PM -0400, Justin Sherrill wrote: > On 03/18/2013 02:41 PM, Lukas Zapletal wrote: > >On Mon, Mar 18, 2013 at 10:19:02AM -0400, Justin Sherrill wrote: > >>Alternatively you could write a minitest test using vcr to test on > >>real backend systems. > >By the way, do we run them regularly to see regressions? > > > >LZ > > > Anytime we import a new version of pulp into koji for nightly builds > we run the vcr tests against the new version of pulp. We first run > the runcible tests in all (live) mode, and then we run the katello > tests in all mode. It greatly helps finding issues both on our side > and new bugs that have popped up. > > We do need to make sure to do that against candlepin, since we have > vcr tests now. So that should be a requirement before importing a > new version into nightly. > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From jsherril at redhat.com Mon Mar 18 19:41:57 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 18 Mar 2013 15:41:57 -0400 Subject: [katello-devel] loosening name restrictions for objects In-Reply-To: <20130318193700.GB25140@lzapx.brq.redhat.com> References: <1056994913.15936519.1363608069715.JavaMail.root@redhat.com> <5147028F.6040008@redhat.com> <20130318130540.GN1659@lzapx.brq.redhat.com> <51472256.5040805@redhat.com> <20130318184117.GA25140@lzapx.brq.redhat.com> <514760F6.6070500@redhat.com> <20130318193700.GB25140@lzapx.brq.redhat.com> Message-ID: <51476E05.4090408@redhat.com> On 03/18/2013 03:37 PM, Lukas Zapletal wrote: > Is this test runnable from an RPM installation? > > If so, we can create a Beaker job to do this every day... It should be, I just have not tried. yum install katello-devel-tests rake minitest mode=all I believe. -Justin > LZ > > On Mon, Mar 18, 2013 at 02:46:14PM -0400, Justin Sherrill wrote: >> On 03/18/2013 02:41 PM, Lukas Zapletal wrote: >>> On Mon, Mar 18, 2013 at 10:19:02AM -0400, Justin Sherrill wrote: >>>> Alternatively you could write a minitest test using vcr to test on >>>> real backend systems. >>> By the way, do we run them regularly to see regressions? >>> >>> LZ >>> >> Anytime we import a new version of pulp into koji for nightly builds >> we run the vcr tests against the new version of pulp. We first run >> the runcible tests in all (live) mode, and then we run the katello >> tests in all mode. It greatly helps finding issues both on our side >> and new bugs that have popped up. >> >> We do need to make sure to do that against candlepin, since we have >> vcr tests now. So that should be a requirement before importing a >> new version into nightly. >> >> -Justin >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Tue Mar 19 11:46:22 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 19 Mar 2013 12:46:22 +0100 Subject: [katello-devel] Current state of RHEL6 Nightly Message-ID: <20130319114622.GE1769@lzapx.brq.redhat.com> Hey, as you may noticed, I have been working on getting SCL packages into RHEL6 nightly and migrating our package on SCL Ruby 1.9 stack. This was finished this morning, the current nightly does install on SCL stack and bring packages prefixed with ruby193 now. The katello and katello-jobs services now uses ruby 1.9 as well as other scripts from /usr/share/katello/script. The migration is not finished tho. Mirek is still working on Foreman, therefore expect an installation error during katello-configure. Even when Mirek finishes his work, SCL support in RHEL6 will not be perfect. There will be things that will still run on ruby 1.8 (and thus not working) - I can picture katello-upgrade for example. If you hit any issue (a script is trying to start with /usr/bin/ruby which will not be required soon), you need to change shebang. See katello.spec for that. Also I noticed Justin is preparing the 1.3 release and I made this mistake of merging this SCL effort into the master. I would like to ask Justin and Mirek what is the best plan now in regard to this release - do we have enough time to complete Foreman SCL migration and release 1.3 or should we maybe turn SCL off for a while, release 1.3 and then turn it back on? Opinions? Comments? -- Later, Lukas "lzap" Zapletal #katello #systemengine From lzap at redhat.com Tue Mar 19 14:00:42 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 19 Mar 2013 15:00:42 +0100 Subject: [katello-devel] Current state of RHEL6 Nightly In-Reply-To: <20130319114622.GE1769@lzapx.brq.redhat.com> References: <20130319114622.GE1769@lzapx.brq.redhat.com> Message-ID: <20130319140042.GF1769@lzapx.brq.redhat.com> Ok I am working towards turning SCL off for RHEL6 now, I will push a PR shortly. We will wait until Mirek finishes with Foreman, hopefully this week. I thought I will also need to migrate katello-upgrade to SCL, but it was decided to not to convert katello-configure (and katello-upgrade is part of katello-configure). It still runs atop of Ruby 1.8 and Puppet from EPEL. The question is if we want to migrate that to SCL stack too. The issue here is Puppet - we would need to migrate Puppet to SCL too. I am not sure if that does not bring issues (e.g. clients running puppet with 1.8 from EPEL vs server running Katello/Foreman/Puppet on 1.9 Ruby). Opinions? Ohad? LZ On Tue, Mar 19, 2013 at 12:46:22PM +0100, Lukas Zapletal wrote: > Hey, > > as you may noticed, I have been working on getting SCL packages into > RHEL6 nightly and migrating our package on SCL Ruby 1.9 stack. This was > finished this morning, the current nightly does install on SCL stack and > bring packages prefixed with ruby193 now. > > The katello and katello-jobs services now uses ruby 1.9 as well as other > scripts from /usr/share/katello/script. The migration is not finished > tho. Mirek is still working on Foreman, therefore expect an installation > error during katello-configure. > > Even when Mirek finishes his work, SCL support in RHEL6 will not be > perfect. There will be things that will still run on ruby 1.8 (and thus > not working) - I can picture katello-upgrade for example. If you hit any > issue (a script is trying to start with /usr/bin/ruby which will not be > required soon), you need to change shebang. See katello.spec for that. > > Also I noticed Justin is preparing the 1.3 release and I made this > mistake of merging this SCL effort into the master. I would like to ask > Justin and Mirek what is the best plan now in regard to this release - > do we have enough time to complete Foreman SCL migration and release 1.3 > or should we maybe turn SCL off for a while, release 1.3 and then turn > it back on? > > Opinions? Comments? > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From dcleal at redhat.com Tue Mar 19 14:07:53 2013 From: dcleal at redhat.com (Dominic Cleal) Date: Tue, 19 Mar 2013 14:07:53 +0000 Subject: [katello-devel] Current state of RHEL6 Nightly In-Reply-To: <20130319140042.GF1769@lzapx.brq.redhat.com> References: <20130319114622.GE1769@lzapx.brq.redhat.com> <20130319140042.GF1769@lzapx.brq.redhat.com> Message-ID: <51487139.2020305@redhat.com> On 19/03/13 14:00, Lukas Zapletal wrote: > Ok I am working towards turning SCL off for RHEL6 now, I will push a PR > shortly. We will wait until Mirek finishes with Foreman, hopefully this > week. > > I thought I will also need to migrate katello-upgrade to SCL, but it was > decided to not to convert katello-configure (and katello-upgrade is part > of katello-configure). It still runs atop of Ruby 1.8 and Puppet from > EPEL. > > The question is if we want to migrate that to SCL stack too. The issue > here is Puppet - we would need to migrate Puppet to SCL too. I am not > sure if that does not bring issues (e.g. clients running puppet with 1.8 > from EPEL vs server running Katello/Foreman/Puppet on 1.9 Ruby). There is the following report of an incompatibility when mixing Ruby versions with Puppet, but I don't know if it would affect us: http://projects.puppetlabs.com/issues/9084 Some of the report refers to 1.9.2 (which isn't supported w/Puppet), but there are references to 1.9.3. -- Dominic Cleal Red Hat Engineering From msuchy at redhat.com Thu Mar 21 13:35:00 2013 From: msuchy at redhat.com (=?ISO-8859-2?Q?Miroslav_Such=FD?=) Date: Thu, 21 Mar 2013 14:35:00 +0100 Subject: [katello-devel] Puppet 2.7 or Puppet 3.1 for RHEL6 Message-ID: <514B0C84.9090607@redhat.com> I find that Foreman use in code: require 'puppet' which means that I have to package puppet for ruby193. And if I will make change, the question is how big change should I do? Currently rhel6 have puppet 2.6. I can build either puppet 2.7, 3.0 or 3.1. Here is list of backward incompatible changes: http://docs.puppetlabs.com/puppet/3/reference/whats_new.html#backwards-incompatible-changes-in-3x Since we will in near future support only Fedora 18 + RHEL6 with SC and Fedora 18 use puppet 3.1, I think we should use puppet 3.1. Raise your voice please if you have objections or comments. -- Miroslav Suchy Red Hat Systems Management Engineering From sam at kottlerdevelopment.com Thu Mar 21 13:59:08 2013 From: sam at kottlerdevelopment.com (Sam Kottler) Date: Thu, 21 Mar 2013 09:59:08 -0400 Subject: [katello-devel] Puppet 2.7 or Puppet 3.1 for RHEL6 In-Reply-To: <514B0C84.9090607@redhat.com> References: <514B0C84.9090607@redhat.com> Message-ID: <514B122C.1070201@kottlerdevelopment.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/21/2013 09:35 AM, Miroslav Such? wrote: > I find that Foreman use in code: require 'puppet' which means that > I have to package puppet for ruby193. And if I will make change, > the question is how big change should I do? Currently rhel6 have > puppet 2.6. I can build either puppet 2.7, 3.0 or 3.1. Here is list > of backward incompatible changes: > http://docs.puppetlabs.com/puppet/3/reference/whats_new.html#backwards-incompatible-changes-in-3x > > > > Since we will in near future support only Fedora 18 + RHEL6 with SC > and Fedora 18 use puppet 3.1, I think we should use puppet 3.1. +1. There are a lot of bugs for running under 1.9.3 that are fixed in 3.0+. > > Raise your voice please if you have objections or comments. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRSxIsAAoJEISlqUbIp1ilu4AH/RecP6lbfKsJVU+efW050+Rp Nbhp+JiofSjxVNuZZ2teJ6ULkUAFNOtJ0DQoO7CbxCe547ICqOSAt8Y4/C0Mu3fK YLFO8tXGIHGPhl4qqx+FqNh34EEce96/CorOzBX7jehD88Frn/u0MQ0m67JB3y3k X3yW39/Xcx5PWDx2swm3UC6hFIQpl3TBlYorvjDltVJoHHCGdPNUOzCSk8PCC5OL waxh75I3Y/633k+fc1YAEZ9VDHCkWFrOC9KCNBLAHKBmjHmxNHYl0b540N35JYnk 7V/XxTdqTNPen3QKt3NIGl6dbJ1JgkIZayTgurCiuORNJXoEyRZE4UEY3Jo3gzU= =Z8LA -----END PGP SIGNATURE----- From dcleal at redhat.com Thu Mar 21 14:21:39 2013 From: dcleal at redhat.com (Dominic Cleal) Date: Thu, 21 Mar 2013 14:21:39 +0000 Subject: [katello-devel] Puppet 2.7 or Puppet 3.1 for RHEL6 In-Reply-To: <514B122C.1070201@kottlerdevelopment.com> References: <514B0C84.9090607@redhat.com> <514B122C.1070201@kottlerdevelopment.com> Message-ID: <514B1773.3090304@redhat.com> On 21/03/13 13:59, Sam Kottler wrote: > On 03/21/2013 09:35 AM, Miroslav Such? wrote: >> I find that Foreman use in code: require 'puppet' which means that >> I have to package puppet for ruby193. And if I will make change, >> the question is how big change should I do? Currently rhel6 have >> puppet 2.6. I can build either puppet 2.7, 3.0 or 3.1. Here is list >> of backward incompatible changes: >> http://docs.puppetlabs.com/puppet/3/reference/whats_new.html#backwards-incompatible-changes-in-3x > > > >> Since we will in near future support only Fedora 18 + RHEL6 with SC >> and Fedora 18 use puppet 3.1, I think we should use puppet 3.1. > > +1. There are a lot of bugs for running under 1.9.3 that are fixed in > 3.0+. Indeed +1. Puppet 3 follows semver too, so it'll be much easier to rebase throughout the 3.x series without worrying about compatibility-breaking changes. 2.6's support in the community has mostly vanished and continued security support is doubtful. -- Dominic Cleal Red Hat Engineering From ericdhelms at gmail.com Thu Mar 21 16:00:36 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Thu, 21 Mar 2013 12:00:36 -0400 Subject: [katello-devel] Nutupane Branch from Deep Dive Message-ID: A few people asked that I point them to the branch that the nutupane work is happening in to inspect and look at the code closer. The branch is: https://github.com/ehelms/katello/tree/system-index-elasticsearch The files of particular interest are: app/views/systems/index_nutupane.haml public/javascripts/systems/systems.controller.js The component repository on the Alchemy side is here: https://github.com/ui-alchemy/alchemy-tables - Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkearney at redhat.com Thu Mar 21 16:51:59 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 21 Mar 2013 12:51:59 -0400 Subject: [katello-devel] Puppet 2.7 or Puppet 3.1 for RHEL6 In-Reply-To: <514B1773.3090304@redhat.com> References: <514B0C84.9090607@redhat.com> <514B122C.1070201@kottlerdevelopment.com> <514B1773.3090304@redhat.com> Message-ID: <514B3AAF.50102@redhat.com> On 03/21/2013 10:21 AM, Dominic Cleal wrote: > On 21/03/13 13:59, Sam Kottler wrote: >> On 03/21/2013 09:35 AM, Miroslav Such? wrote: >>> I find that Foreman use in code: require 'puppet' which means that >>> I have to package puppet for ruby193. And if I will make change, >>> the question is how big change should I do? Currently rhel6 have >>> puppet 2.6. I can build either puppet 2.7, 3.0 or 3.1. Here is list >>> of backward incompatible changes: >>> http://docs.puppetlabs.com/puppet/3/reference/whats_new.html#backwards-incompatible-changes-in-3x >> >> >> >>> Since we will in near future support only Fedora 18 + RHEL6 with SC >>> and Fedora 18 use puppet 3.1, I think we should use puppet 3.1. >> >> +1. There are a lot of bugs for running under 1.9.3 that are fixed in >> 3.0+. > > Indeed +1. Puppet 3 follows semver too, so it'll be much easier to > rebase throughout the 3.x series without worrying about > compatibility-breaking changes. > > 2.6's support in the community has mostly vanished and continued > security support is doubtful. > +1 to the latest which is in Fedora. -- bk From sam at kottlerdevelopment.com Thu Mar 21 18:43:43 2013 From: sam at kottlerdevelopment.com (Sam Kottler) Date: Thu, 21 Mar 2013 14:43:43 -0400 Subject: [katello-devel] Puppet 2.7 or Puppet 3.1 for RHEL6 In-Reply-To: <514B3AAF.50102@redhat.com> References: <514B0C84.9090607@redhat.com> <514B122C.1070201@kottlerdevelopment.com> <514B1773.3090304@redhat.com> <514B3AAF.50102@redhat.com> Message-ID: <514B54DF.9020205@kottlerdevelopment.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/21/2013 12:51 PM, Bryan Kearney wrote: > On 03/21/2013 10:21 AM, Dominic Cleal wrote: >> On 21/03/13 13:59, Sam Kottler wrote: >>> On 03/21/2013 09:35 AM, Miroslav Such? wrote: >>>> I find that Foreman use in code: require 'puppet' which means >>>> that I have to package puppet for ruby193. And if I will make >>>> change, the question is how big change should I do? Currently >>>> rhel6 have puppet 2.6. I can build either puppet 2.7, 3.0 or >>>> 3.1. Here is list of backward incompatible changes: >>>> http://docs.puppetlabs.com/puppet/3/reference/whats_new.html#backwards-incompatible-changes-in-3x >>>> >>> >>> >>> >>>> >>>> Since we will in near future support only Fedora 18 + RHEL6 with SC >>>> and Fedora 18 use puppet 3.1, I think we should use puppet >>>> 3.1. >>> >>> +1. There are a lot of bugs for running under 1.9.3 that are >>> fixed in 3.0+. >> >> Indeed +1. Puppet 3 follows semver too, so it'll be much easier >> to rebase throughout the 3.x series without worrying about >> compatibility-breaking changes. >> >> 2.6's support in the community has mostly vanished and continued >> security support is doubtful. >> > +1 to the latest which is in Fedora. Michael Stahnke and are working on getting 3.1 into rawhide, but 3.0.2 is in updates-testing right now. I think it's safe to work under the assumption that 3.1 will be in updates-testing pretty soon and then subsequently move to updates. > > -- bk > > _______________________________________________ katello-devel > mailing list katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRS1TfAAoJEISlqUbIp1ilJJUIAJVsJQGT2RYTZKwoCvz9ZIuG N8VMsp7eObQltveGCi2mbECIDPsiV7cF1MpZ75YaFg93NHO93Rnd3i+sNwWW5swu Gfk+1pnhQGDDMIImM8WN/WWTGgdpV6ZEVzoCxYN8QBVUFTDkVRKF//XD4hjmBw1b wtXmC6SfNTR287BzE1MevE1zfNkRgIn9UZk9sRKdoHrOTZ6I0UDniHRJErnPModA DleQXHsxifIEVUXSI9vp9OXnk1AbfnWGKQskTGFqj8nAcL1Vheo0131+JVEdEjBm 4VEmimaoU2g9cuZiX5d3+lRynGzp2f1JUAxscVLXodHp1/Bf+6+pymljOcN6OrU= =gFvQ -----END PGP SIGNATURE----- From dcleal at redhat.com Fri Mar 22 08:33:03 2013 From: dcleal at redhat.com (Dominic Cleal) Date: Fri, 22 Mar 2013 08:33:03 +0000 Subject: [katello-devel] Puppet 2.7 or Puppet 3.1 for RHEL6 In-Reply-To: <514B54DF.9020205@kottlerdevelopment.com> References: <514B0C84.9090607@redhat.com> <514B122C.1070201@kottlerdevelopment.com> <514B1773.3090304@redhat.com> <514B3AAF.50102@redhat.com> <514B54DF.9020205@kottlerdevelopment.com> Message-ID: <514C173F.5080500@redhat.com> On 21/03/13 18:43, Sam Kottler wrote: > On 03/21/2013 12:51 PM, Bryan Kearney wrote: >> +1 to the latest which is in Fedora. > > Michael Stahnke and are working on getting 3.1 into rawhide, but 3.0.2 > is in updates-testing right now. I think it's safe to work under the > assumption that 3.1 will be in updates-testing pretty soon and then > subsequently move to updates. Yeah, there are niggling bugs for us too affecting Foreman deployments on 3.0, so 3.1 would be a better choice. -- Dominic Cleal Red Hat Engineering From daviddavis at redhat.com Mon Mar 25 13:13:40 2013 From: daviddavis at redhat.com (David Davis) Date: Mon, 25 Mar 2013 09:13:40 -0400 (EDT) Subject: [katello-devel] Check out pull requests locally Message-ID: <387962867.24317850.1364217220332.JavaMail.root@redhat.com> I've been using hub pretty much exclusively for its ability to check out pull requests so that I can test PRs before acking them. But thanks to this gist that somebody posted, it turns out you don't have to use hub to do that. You can checkout PRs just using git. https://gist.github.com/piscisaureus/3342247 David From inecas at redhat.com Mon Mar 25 13:18:30 2013 From: inecas at redhat.com (Ivan Necas) Date: Mon, 25 Mar 2013 09:18:30 -0400 (EDT) Subject: [katello-devel] Check out pull requests locally In-Reply-To: <387962867.24317850.1364217220332.JavaMail.root@redhat.com> Message-ID: <1446793899.23377289.1364217510967.JavaMail.root@redhat.com> ----- Original Message ----- > I've been using hub pretty much exclusively for its ability to check > out pull requests so that I can test PRs before acking them. But > thanks to this gist that somebody posted, it turns out you don't > have to use hub to do that. You can checkout PRs just using git. > > https://gist.github.com/piscisaureus/3342247 Nice one. Sometimes, I want to test a PR directly in production environment on code from RPMs. What I do is: cd /usr/share/katello curl https://github.com/Katello/katello/pull/1234.patch | patch -p2 -- Ivan > > David > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From msuchy at redhat.com Tue Mar 26 09:14:25 2013 From: msuchy at redhat.com (=?ISO-8859-2?Q?Miroslav_Such=FD?=) Date: Tue, 26 Mar 2013 10:14:25 +0100 Subject: [katello-devel] OpenSCAP Remediation Message-ID: <515166F1.10403@redhat.com> FYI - interresting: http://isimluk.livejournal.com/3573.html -- Miroslav Suchy Red Hat Systems Management Engineering From bkearney at redhat.com Tue Mar 26 11:02:09 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 26 Mar 2013 07:02:09 -0400 Subject: [katello-devel] OpenSCAP Remediation In-Reply-To: <515166F1.10403@redhat.com> References: <515166F1.10403@redhat.com> Message-ID: <51518031.10100@redhat.com> On 03/26/2013 05:14 AM, Miroslav Such? wrote: > FYI - interresting: > http://isimluk.livejournal.com/3573.html are these oval files delivered via RPM, or some other fashion? It would be interesting to see if these can be managed similar to puppet modules. -- bk From bkearney at redhat.com Tue Mar 26 11:11:22 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 26 Mar 2013 07:11:22 -0400 Subject: [katello-devel] Batch Jobs? Message-ID: <5151825A.4020302@redhat.com> What is the current thinking around batch jobs? Is this cron which calls into a REST call, or build a built in scheduling engine? Examples I can think of include: * manifest update * duplicate checking * orphan checking * syncing -- bk From lzap at redhat.com Tue Mar 26 13:41:27 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 26 Mar 2013 14:41:27 +0100 Subject: [katello-devel] OpenSCAP Remediation In-Reply-To: <51518031.10100@redhat.com> References: <515166F1.10403@redhat.com> <51518031.10100@redhat.com> Message-ID: <20130326134127.GA13024@lzapx.brq.redhat.com> On Tue, Mar 26, 2013 at 07:02:09AM -0400, Bryan Kearney wrote: > On 03/26/2013 05:14 AM, Miroslav Such? wrote: > >FYI - interresting: > >http://isimluk.livejournal.com/3573.html > are these oval files delivered via RPM, or some other fashion? It > would be interesting to see if these can be managed similar to > puppet modules. Yeah I would rather see OpenSCAP + Puppet integration. OpenSCAP definition would contain information how to apply (or check) the defined configuration and it would call Puppet to do the job and drift management. LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From jsherril at redhat.com Tue Mar 26 14:39:47 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 26 Mar 2013 10:39:47 -0400 Subject: [katello-devel] purpose of --katello-configuration-files-only on katello-configure Message-ID: <5151B333.2020107@redhat.com> Hey Petr (or anyone else who can chime in), I have noticed that we added this functionality to katello configure to update ONLY katello config files for the upgrade process. Is there any reason we don't want to upgrade all config files that we are concerned with (pulp, candlepin, foreman, elasticsearch). For 1.3 we do need to run through the pulp config files because they have all changed, and this is not currently being done. I can see obvious reasons to run through all config files, as there might be other changes in other config files. What was the reason to just do the katello ones? Thanks, -Justin From cperry at redhat.com Tue Mar 26 14:40:49 2013 From: cperry at redhat.com (Cliff Perry) Date: Tue, 26 Mar 2013 14:40:49 +0000 Subject: [katello-devel] Batch Jobs? In-Reply-To: <5151825A.4020302@redhat.com> References: <5151825A.4020302@redhat.com> Message-ID: <5151B371.2070208@redhat.com> On 26/03/13 11:11, Bryan Kearney wrote: > What is the current thinking around batch jobs? Is this cron which calls > into a REST call, or build a built in scheduling engine? not using the OS cron daemon should be solution, IMHO. Something like quartz. - Just because it makes the app more portable vs tied to the OS and potentially being broken future Fedora's, such as if they dramatically change cron for say systemd - or some such. :) Cliff > > Examples I can think of include: > * manifest update > * duplicate checking > * orphan checking > * syncing > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Clifford Perry Manager, Satellite Engineering Red Hat, Inc. http://www.redhat.com/ RHCA / RHCE# 805007680128201 From thomasmckay at redhat.com Tue Mar 26 14:44:30 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 26 Mar 2013 10:44:30 -0400 (EDT) Subject: [katello-devel] Batch Jobs? In-Reply-To: <5151B371.2070208@redhat.com> Message-ID: <1702945572.19303087.1364309070955.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Cliff Perry" > To: "Bryan Kearney" > Cc: "katello-devel" > Sent: Tuesday, March 26, 2013 10:40:49 AM > Subject: Re: [katello-devel] Batch Jobs? > > On 26/03/13 11:11, Bryan Kearney wrote: > > What is the current thinking around batch jobs? Is this cron which > > calls > > into a REST call, or build a built in scheduling engine? > > not using the OS cron daemon should be solution, IMHO. Something like > quartz. > - Just because it makes the app more portable vs tied to the OS and > potentially being broken future Fedora's, such as if they > dramatically > change cron for say systemd - or some such. :) > > Cliff > > > > > > Examples I can think of include: > > * manifest update > > * duplicate checking > > * orphan checking > > * syncing > > > > -- bk > > How are repo sync plans done now? From jsherril at redhat.com Tue Mar 26 14:51:57 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 26 Mar 2013 10:51:57 -0400 Subject: [katello-devel] Batch Jobs? In-Reply-To: <1702945572.19303087.1364309070955.JavaMail.root@redhat.com> References: <1702945572.19303087.1364309070955.JavaMail.root@redhat.com> Message-ID: <5151B60D.7090601@redhat.com> On 03/26/2013 10:44 AM, Tom McKay wrote: > > ----- Original Message ----- >> From: "Cliff Perry" >> To: "Bryan Kearney" >> Cc: "katello-devel" >> Sent: Tuesday, March 26, 2013 10:40:49 AM >> Subject: Re: [katello-devel] Batch Jobs? >> >> On 26/03/13 11:11, Bryan Kearney wrote: >>> What is the current thinking around batch jobs? Is this cron which >>> calls >>> into a REST call, or build a built in scheduling engine? >> not using the OS cron daemon should be solution, IMHO. Something like >> quartz. >> - Just because it makes the app more portable vs tied to the OS and >> potentially being broken future Fedora's, such as if they >> dramatically >> change cron for say systemd - or some such. :) >> >> Cliff And you have auth concerns, tying up other things from happening potentially, editing of cron files if you want user-scheduled tasks. >> >> >>> Examples I can think of include: >>> * manifest update >>> * duplicate checking >>> * orphan checking >>> * syncing >>> >>> -- bk >>> > > How are repo sync plans done now? Pulp has built in scheduling with its own (ISO approved!) date/schedule format. We just tell pulp what the schedule is and it does its thing. -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From jsherril at redhat.com Tue Mar 26 15:00:24 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 26 Mar 2013 11:00:24 -0400 Subject: [katello-devel] purpose of --katello-configuration-files-only on katello-configure In-Reply-To: <5151B333.2020107@redhat.com> References: <5151B333.2020107@redhat.com> Message-ID: <5151B808.5040409@redhat.com> On 03/26/2013 10:39 AM, Justin Sherrill wrote: > Hey Petr (or anyone else who can chime in), > > I have noticed that we added this functionality to katello configure > to update ONLY katello config files for the upgrade process. Is there > any reason we don't want to upgrade all config files that we are > concerned with (pulp, candlepin, foreman, elasticsearch). For 1.3 > we do need to run through the pulp config files because they have all > changed, and this is not currently being done. I can see obvious > reasons to run through all config files, as there might be other > changes in other config files. What was the reason to just do the > katello ones? > Oh right so the full katello-configure get run later in the process, but after the db-migrate. I'm curious why not go ahead and run katello-configure fully at that point (before the db:migrate). I'll play around with it. -Justin > Thanks, > > -Justin > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From msuchy at redhat.com Tue Mar 26 15:27:12 2013 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Tue, 26 Mar 2013 16:27:12 +0100 Subject: [katello-devel] OpenSCAP Remediation In-Reply-To: <51518031.10100@redhat.com> References: <515166F1.10403@redhat.com> <51518031.10100@redhat.com> Message-ID: <5151BE50.2050309@redhat.com> On 03/26/2013 12:02 PM, Bryan Kearney wrote: > are these oval files delivered via RPM, or some other fashion? It would > be interesting to see if these can be managed similar to puppet modules. Oval checks are packaged in openscap package: http://koji.fedoraproject.org/koji/rpminfo?fileStart=50&rpmID=3844692&fileOrder=name&buildrootOrder=-id&buildrootStart=0#filelist And of course you can create your own rule and package it yourself if you need to. -- Miroslav Suchy Red Hat Systems Management Engineering From msuchy at redhat.com Tue Mar 26 16:22:28 2013 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Tue, 26 Mar 2013 17:22:28 +0100 Subject: [katello-devel] Current state of RHEL6 Nightly In-Reply-To: <20130319140042.GF1769@lzapx.brq.redhat.com> References: <20130319114622.GE1769@lzapx.brq.redhat.com> <20130319140042.GF1769@lzapx.brq.redhat.com> Message-ID: <5151CB44.8040401@redhat.com> On 03/19/2013 03:00 PM, Lukas Zapletal wrote: > The question is if we want to migrate that to SCL stack too. The issue > here is Puppet - we would need to migrate Puppet to SCL too. I am not > sure if that does not bring issues (e.g. clients running puppet with 1.8 > from EPEL vs server running Katello/Foreman/Puppet on 1.9 Ruby). OK. So I have all foreman deps built for SC. Foreman start, but the login screen gives 500 because of: https://github.com/theforeman/foreman/pull/467#issuecomment-15449354 Can someone check the code (with that PR applied) and replace that occurrence of 'update_page'? It is only one. But this is beyond my expertise. -- Miroslav Suchy Red Hat Systems Management Engineering From mmccune at redhat.com Tue Mar 26 16:23:32 2013 From: mmccune at redhat.com (Mike McCune) Date: Tue, 26 Mar 2013 09:23:32 -0700 Subject: [katello-devel] Batch Jobs? In-Reply-To: <1702945572.19303087.1364309070955.JavaMail.root@redhat.com> References: <1702945572.19303087.1364309070955.JavaMail.root@redhat.com> Message-ID: <5151CB84.1030803@redhat.com> On 03/26/2013 07:44 AM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Cliff Perry" >> To: "Bryan Kearney" >> Cc: "katello-devel" >> Sent: Tuesday, March 26, 2013 10:40:49 AM >> Subject: Re: [katello-devel] Batch Jobs? >> >> On 26/03/13 11:11, Bryan Kearney wrote: >>> What is the current thinking around batch jobs? Is this cron which >>> calls >>> into a REST call, or build a built in scheduling engine? >> >> not using the OS cron daemon should be solution, IMHO. Something like >> quartz. >> - Just because it makes the app more portable vs tied to the OS and >> potentially being broken future Fedora's, such as if they >> dramatically >> change cron for say systemd - or some such. :) >> >> Cliff >> >> >>> >>> Examples I can think of include: >>> * manifest update >>> * duplicate checking >>> * orphan checking >>> * syncing >>> >>> -- bk >>> > > > How are repo sync plans done now? Pulp has a tasking/scheduling engine built in and it manages all that. For us, there are various gems we can include in katello-jobs? that can start to handle cron like processing: http://github.com/javan/whenever http://github.com/jmettraux/rufus-scheduler I'd like to avoid another ruby process running so whatever we do I'd like to stick to our 2 main processes, katello and katello-jobs where katello-jobs has a bit more relevancy to processing scheduled tasks (even if right now all it does is async work). Mike From bkearney at redhat.com Tue Mar 26 17:02:16 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 26 Mar 2013 13:02:16 -0400 Subject: [katello-devel] Batch Jobs? In-Reply-To: <5151CB84.1030803@redhat.com> References: <1702945572.19303087.1364309070955.JavaMail.root@redhat.com> <5151CB84.1030803@redhat.com> Message-ID: <5151D498.6070408@redhat.com> On 03/26/2013 12:23 PM, Mike McCune wrote: > On 03/26/2013 07:44 AM, Tom McKay wrote: >> >> >> ----- Original Message ----- >>> From: "Cliff Perry" >>> To: "Bryan Kearney" >>> Cc: "katello-devel" >>> Sent: Tuesday, March 26, 2013 10:40:49 AM >>> Subject: Re: [katello-devel] Batch Jobs? >>> >>> On 26/03/13 11:11, Bryan Kearney wrote: >>>> What is the current thinking around batch jobs? Is this cron which >>>> calls >>>> into a REST call, or build a built in scheduling engine? >>> >>> not using the OS cron daemon should be solution, IMHO. Something like >>> quartz. >>> - Just because it makes the app more portable vs tied to the OS and >>> potentially being broken future Fedora's, such as if they >>> dramatically >>> change cron for say systemd - or some such. :) >>> >>> Cliff >>> >>> >>>> >>>> Examples I can think of include: >>>> * manifest update >>>> * duplicate checking >>>> * orphan checking >>>> * syncing >>>> >>>> -- bk >>>> >> >> >> How are repo sync plans done now? > > Pulp has a tasking/scheduling engine built in and it manages all that. > > For us, there are various gems we can include in katello-jobs? that can > start to handle cron like processing: > > http://github.com/javan/whenever > > http://github.com/jmettraux/rufus-scheduler > > I'd like to avoid another ruby process running so whatever we do I'd > like to stick to our 2 main processes, katello and katello-jobs where > katello-jobs has a bit more relevancy to processing scheduled tasks > (even if right now all it does is async work). > Ok.. perhaps as eric said something to put on the backlog. --b k From jsherril at redhat.com Tue Mar 26 17:32:40 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 26 Mar 2013 13:32:40 -0400 Subject: [katello-devel] Batch Jobs? In-Reply-To: <5151CB84.1030803@redhat.com> References: <1702945572.19303087.1364309070955.JavaMail.root@redhat.com> <5151CB84.1030803@redhat.com> Message-ID: <5151DBB8.1060606@redhat.com> On 03/26/2013 12:23 PM, Mike McCune wrote: > On 03/26/2013 07:44 AM, Tom McKay wrote: >> >> >> ----- Original Message ----- >>> From: "Cliff Perry" >>> To: "Bryan Kearney" >>> Cc: "katello-devel" >>> Sent: Tuesday, March 26, 2013 10:40:49 AM >>> Subject: Re: [katello-devel] Batch Jobs? >>> >>> On 26/03/13 11:11, Bryan Kearney wrote: >>>> What is the current thinking around batch jobs? Is this cron which >>>> calls >>>> into a REST call, or build a built in scheduling engine? >>> >>> not using the OS cron daemon should be solution, IMHO. Something like >>> quartz. >>> - Just because it makes the app more portable vs tied to the OS and >>> potentially being broken future Fedora's, such as if they >>> dramatically >>> change cron for say systemd - or some such. :) >>> >>> Cliff >>> >>> >>>> >>>> Examples I can think of include: >>>> * manifest update >>>> * duplicate checking >>>> * orphan checking >>>> * syncing >>>> >>>> -- bk >>>> >> >> >> How are repo sync plans done now? > > Pulp has a tasking/scheduling engine built in and it manages all that. > > For us, there are various gems we can include in katello-jobs? that > can start to handle cron like processing: > > http://github.com/javan/whenever > > http://github.com/jmettraux/rufus-scheduler > > I'd like to avoid another ruby process running so whatever we do I'd > like to stick to our 2 main processes, katello and katello-jobs where > katello-jobs has a bit more relevancy to processing scheduled tasks > (even if right now all it does is async work). > +1000 .......mb of memory it would take to run one more process (or two or three) > Mike > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From ericdhelms at gmail.com Tue Mar 26 18:30:37 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Tue, 26 Mar 2013 14:30:37 -0400 Subject: [katello-devel] Batch Jobs? In-Reply-To: <5151D498.6070408@redhat.com> References: <1702945572.19303087.1364309070955.JavaMail.root@redhat.com> <5151CB84.1030803@redhat.com> <5151D498.6070408@redhat.com> Message-ID: On Tue, Mar 26, 2013 at 1:02 PM, Bryan Kearney wrote: > On 03/26/2013 12:23 PM, Mike McCune wrote: > >> On 03/26/2013 07:44 AM, Tom McKay wrote: >> >>> >>> >>> ----- Original Message ----- >>> >>>> From: "Cliff Perry" >>>> To: "Bryan Kearney" >>>> Cc: "katello-devel" >>>> > >>>> Sent: Tuesday, March 26, 2013 10:40:49 AM >>>> Subject: Re: [katello-devel] Batch Jobs? >>>> >>>> On 26/03/13 11:11, Bryan Kearney wrote: >>>> >>>>> What is the current thinking around batch jobs? Is this cron which >>>>> calls >>>>> into a REST call, or build a built in scheduling engine? >>>>> >>>> >>>> not using the OS cron daemon should be solution, IMHO. Something like >>>> quartz. >>>> - Just because it makes the app more portable vs tied to the OS and >>>> potentially being broken future Fedora's, such as if they >>>> dramatically >>>> change cron for say systemd - or some such. :) >>>> >>>> Cliff >>>> >>>> >>>> >>>>> Examples I can think of include: >>>>> * manifest update >>>>> * duplicate checking >>>>> * orphan checking >>>>> * syncing >>>>> >>>>> -- bk >>>>> >>>>> >>> >>> How are repo sync plans done now? >>> >> >> Pulp has a tasking/scheduling engine built in and it manages all that. >> >> For us, there are various gems we can include in katello-jobs? that can >> start to handle cron like processing: >> >> http://github.com/javan/**whenever >> >> http://github.com/jmettraux/**rufus-scheduler >> >> I'd like to avoid another ruby process running so whatever we do I'd >> like to stick to our 2 main processes, katello and katello-jobs where >> katello-jobs has a bit more relevancy to processing scheduled tasks >> (even if right now all it does is async work). >> >> > > Ok.. perhaps as eric said something to put on the backlog. Added with a reference to this discussion. > --b k > > > > ______________________________**_________________ > 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 jconnor at redhat.com Tue Mar 26 20:53:01 2013 From: jconnor at redhat.com (Jason Connor) Date: Tue, 26 Mar 2013 14:53:01 -0600 Subject: [katello-devel] Batch Jobs? In-Reply-To: <5151B60D.7090601@redhat.com> References: <1702945572.19303087.1364309070955.JavaMail.root@redhat.com> <5151B60D.7090601@redhat.com> Message-ID: <053A1EA3-4078-4764-B9A8-26886A54BDEF@redhat.com> On Mar 26, 2013, at 8:51 AM, Justin Sherrill wrote: >>>> Examples I can think of include: >>>> * manifest update >>>> * duplicate checking >>>> * orphan checking >>>> * syncing >>>> >>>> -- bk >>>> >> >> How are repo sync plans done now? > Pulp has built in scheduling with its own (ISO approved!) date/schedule format. We just tell pulp what the schedule is and it does its thing. > > -Justin As Justin pointed out, pulp can currently schedule repo syncs with its own internal scheduler. It can, in-fact, schedule just about anything. Adding the support for scheduling the management of orphans should be fairly straight forward. All we would need are the requirements around the management options. Jason L Connor linear on freenode #pulp http://pulpproject.org/ RHCE: 805010912355231 GPG Fingerprint: 2048R/CC4ED7C1 From ohadlevy at redhat.com Wed Mar 27 09:24:02 2013 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 27 Mar 2013 05:24:02 -0400 (EDT) Subject: [katello-devel] Batch Jobs? In-Reply-To: <5151B371.2070208@redhat.com> Message-ID: <1275182320.6963007.1364376242194.JavaMail.root@redhat.com> ----- Original Message ----- | On 26/03/13 11:11, Bryan Kearney wrote: | > What is the current thinking around batch jobs? Is this cron which | > calls | > into a REST call, or build a built in scheduling engine? | | not using the OS cron daemon should be solution, IMHO. Something like | quartz. | - Just because it makes the app more portable vs tied to the OS and | potentially being broken future Fedora's, such as if they | dramatically | change cron for say systemd - or some such. :) unless we use puppet to configure the cron job ;) then we don't care about the syntax. Ohad | | Cliff | | | > | > Examples I can think of include: | > * manifest update | > * duplicate checking | > * orphan checking | > * syncing | > | > -- bk | > | > _______________________________________________ | > katello-devel mailing list | > katello-devel at redhat.com | > https://www.redhat.com/mailman/listinfo/katello-devel | | | -- | Clifford Perry | Manager, Satellite Engineering | Red Hat, Inc. | http://www.redhat.com/ | RHCA / RHCE# 805007680128201 | | _______________________________________________ | katello-devel mailing list | katello-devel at redhat.com | https://www.redhat.com/mailman/listinfo/katello-devel | From lzap at redhat.com Wed Mar 27 13:38:02 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 27 Mar 2013 14:38:02 +0100 Subject: [katello-devel] purpose of --katello-configuration-files-only on katello-configure In-Reply-To: <5151B808.5040409@redhat.com> References: <5151B333.2020107@redhat.com> <5151B808.5040409@redhat.com> Message-ID: <20130327133802.GA3077@lzapx.brq.redhat.com> Hey Justin, so the issue was when you do full configure, Puppet will re-configure everything and it will trigger service restarts. But we do not want to restart at this point, but we do want to have katello configured so we can boot rails environment and do some migrations (like deleting all undeleted providers). LZ On Tue, Mar 26, 2013 at 11:00:24AM -0400, Justin Sherrill wrote: > On 03/26/2013 10:39 AM, Justin Sherrill wrote: > >Hey Petr (or anyone else who can chime in), > > > >I have noticed that we added this functionality to katello > >configure to update ONLY katello config files for the upgrade > >process. Is there any reason we don't want to upgrade all config > >files that we are concerned with (pulp, candlepin, foreman, > >elasticsearch). For 1.3 we do need to run through the pulp > >config files because they have all changed, and this is not > >currently being done. I can see obvious reasons to run through > >all config files, as there might be other changes in other config > >files. What was the reason to just do the katello ones? > > > Oh right so the full katello-configure get run later in the process, > but after the db-migrate. I'm curious why not go ahead and run > katello-configure fully at that point (before the db:migrate). I'll > play around with it. > > -Justin > > >Thanks, > > > >-Justin > > > >_______________________________________________ > >katello-devel mailing list > >katello-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From jsherril at redhat.com Wed Mar 27 13:57:34 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Wed, 27 Mar 2013 09:57:34 -0400 Subject: [katello-devel] purpose of --katello-configuration-files-only on katello-configure In-Reply-To: <20130327133802.GA3077@lzapx.brq.redhat.com> References: <5151B333.2020107@redhat.com> <5151B808.5040409@redhat.com> <20130327133802.GA3077@lzapx.brq.redhat.com> Message-ID: <5152FACE.1020305@redhat.com> On 03/27/2013 09:38 AM, Lukas Zapletal wrote: > Hey Justin, > > so the issue was when you do full configure, Puppet will re-configure > everything and it will trigger service restarts. But we do not want to > restart at this point, but we do want to have katello configured so we > can boot rails environment and do some migrations (like deleting all > undeleted providers). > > LZ Well, so that's the thing, is for 1.3, we actually do need config files re-deployed and services restarted (httpd), but i could see other situations where candlepin or elasticsearch need an update to a config file and a bounce. Thoughts on this? -Justin > > On Tue, Mar 26, 2013 at 11:00:24AM -0400, Justin Sherrill wrote: >> On 03/26/2013 10:39 AM, Justin Sherrill wrote: >>> Hey Petr (or anyone else who can chime in), >>> >>> I have noticed that we added this functionality to katello >>> configure to update ONLY katello config files for the upgrade >>> process. Is there any reason we don't want to upgrade all config >>> files that we are concerned with (pulp, candlepin, foreman, >>> elasticsearch). For 1.3 we do need to run through the pulp >>> config files because they have all changed, and this is not >>> currently being done. I can see obvious reasons to run through >>> all config files, as there might be other changes in other config >>> files. What was the reason to just do the katello ones? >>> >> Oh right so the full katello-configure get run later in the process, >> but after the db-migrate. I'm curious why not go ahead and run >> katello-configure fully at that point (before the db:migrate). I'll >> play around with it. >> >> -Justin >> >>> Thanks, >>> >>> -Justin >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel From lzap at redhat.com Wed Mar 27 14:24:24 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 27 Mar 2013 15:24:24 +0100 Subject: [katello-devel] purpose of --katello-configuration-files-only on katello-configure In-Reply-To: <5152FACE.1020305@redhat.com> References: <5151B333.2020107@redhat.com> <5151B808.5040409@redhat.com> <20130327133802.GA3077@lzapx.brq.redhat.com> <5152FACE.1020305@redhat.com> Message-ID: <20130327142424.GE3077@lzapx.brq.redhat.com> On Wed, Mar 27, 2013 at 09:57:34AM -0400, Justin Sherrill wrote: > Well, so that's the thing, is for 1.3, we actually do need config > files re-deployed and services restarted (httpd), but i could see > other situations where candlepin or elasticsearch need an update to > a config file and a bounce. Thoughts on this? I understand, find my mail about katello-upgrade refactoring and my complaints about that. Puppet is not the good tool for upgrading stuff. I think what you want to do is to put your upgrade script at the very end (the last command - full katello-configure - makes sure everything is configured and running). LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From daviddavis at redhat.com Wed Mar 27 15:18:13 2013 From: daviddavis at redhat.com (David Davis) Date: Wed, 27 Mar 2013 11:18:13 -0400 (EDT) Subject: [katello-devel] Parallel tests Message-ID: <979275081.25724101.1364397493963.JavaMail.root@redhat.com> I tried to re-enable parallel_tests since they've fixed the gem to work with bundler 1.3. However, now it seems to run out of disk space in Travis. Locally it runs just fine for me. I'm totally stumped. Does anyone have any ideas? https://github.com/Katello/katello/pull/1756 David From ericdhelms at gmail.com Wed Mar 27 19:48:03 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Wed, 27 Mar 2013 15:48:03 -0400 Subject: [katello-devel] Fedora 18 state In-Reply-To: References: <20130220145532.GD1742@lzapx.brq.redhat.com> <20130221110815.GG2276@lzapx.brq.redhat.com> Message-ID: Quick Update on the State of Fedora 18: As of this afternoons nightly, I was able to install our Fedora 18 nightly repositories and get a running Katello with the following caveats: - use_foreman: false must be added to the katello.yml.rb tempalte before hand - katello-configure did start services after finishing - katello-configure --user-pass throws no errors but does not appear to create or load the database - running katello-configure --reset-data=yes gets everything working - Eric On Wed, Feb 27, 2013 at 6:20 PM, Eric D Helms wrote: > > > > On Thu, Feb 21, 2013 at 2:43 PM, Eric D Helms wrote: > >> After Justin pointed out that there was a Pulp F18 build in our Koji at >> least, I decided to try an install myself this afternoon. The issue I ran >> into was with Apache and after some digging encountered the following: >> >> Error: >> [Tue Feb 19 11:50:57.055123 2013] [ssl:info] [pid 3305] AH01914: >> Configuring server dhcp129-45.rdu.redhat.com:443 for SSL protocol >> [Tue Feb 19 11:50:57.055565 2013] [ssl:warn] [pid 3305] AH01906: RSA >> server certificate is a CA certificate (BasicConstraints: CA == TRUE !?) >> [Tue Feb 19 11:50:58.002066 2013] [proxy_balancer:emerg] [pid 3305] >> (22)Invalid argument: AH01186: worker slotmem_grab failed >> >> >> After some further searching, this appears to be related to this bug: >> https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 >> >> Update: > > I manually installed the updated F18 packages that include Apache 2.4.4 > from their Koji directly just to test and that indeed fixes that particular > issue. The next two issues I saw were: > > - Foreman Errors due to Rails 3.2 (known) > - Elasticsearch not being started and thus throwing connection refused > errors during db seed. Running 'service elasticsearch restart' showed no > error messages, but elasticsearch was not running. /var/run/elasticsearch > is present. > > - Eric > > >> That bug has a fix, but is not upstream yet and I didn't see an >> indication of when we might expect it. There does not appears to be a work >> around. (Passenger time?) >> >> Eric >> >> >> On Thu, Feb 21, 2013 at 6:08 AM, Lukas Zapletal wrote: >> >>> > - Eric made our codebase to be Rails 3.0 and 3.2 compatible >>> > - I am working on getting Katello working on F18 >>> >>> According to my testing, all the dependencies are there and Katello >>> should start, but installer fails for obvious reasons. >>> >>> Adding several steps which were missing: >>> >>> - Help Candlepin guys to build for F18 >>> - Wait for Pulp guys to have a F18 build >>> - The same for Foreman guys >>> >>> > - Then I will help Thom to get Headpin rolling >>> > - Mirek is working on Rails 3.2 SCL stack for RHEL6 >>> > - Then Eric will finish his migration to 3.2 >>> >>> LZ >>> >>> -- >>> Later, >>> >>> Lukas "lzap" Zapletal >>> #katello #systemengine >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericdhelms at gmail.com Wed Mar 27 20:24:15 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Wed, 27 Mar 2013 16:24:15 -0400 Subject: [katello-devel] Development on RHEL - Rails 3.2 Message-ID: As we get closer to full Rails 3.2 migration, I wanted to know: Does anybody develop on RHEL and NOT use rvm or rbenv? -Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbuckingham at redhat.com Wed Mar 27 21:24:39 2013 From: bbuckingham at redhat.com (Brad Buckingham) Date: Wed, 27 Mar 2013 17:24:39 -0400 Subject: [katello-devel] Development on RHEL - Rails 3.2 In-Reply-To: References: Message-ID: <51536397.3040805@redhat.com> On 03/27/2013 04:24 PM, Eric D Helms wrote: > As we get closer to full Rails 3.2 migration, I wanted to know: > > Does anybody develop on RHEL and NOT use rvm or rbenv? > > > -Eric > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I've been developing on fedora VMs, but I've been thinking about moving to using RHEL because it has traditionally been more stable. That said, I use rvm on my dev configs. Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From inecas at redhat.com Thu Mar 28 09:49:09 2013 From: inecas at redhat.com (Ivan Necas) Date: Thu, 28 Mar 2013 05:49:09 -0400 (EDT) Subject: [katello-devel] Drop F16? In-Reply-To: <20130117163007.GA1685@lzapx.brq.redhat.com> Message-ID: <700583442.469255.1364464149483.JavaMail.root@redhat.com> Was there other discussion that I missed that let to this PR to be merged? From this thread I understood that we don't drop F16 until we have other Fedora working. We are pretty close now but was that the case back then? https://github.com/Katello/katello/pull/1483 -- Ivan ----- Original Message ----- > Do we have a BZ for that? If we ask Pulp guys to fix this in both V1 > and > V2 we are good to remove F16. > > LZ > > On Thu, Jan 17, 2013 at 09:49:44AM -0500, Justin Sherrill wrote: > > On 01/17/2013 09:40 AM, Miroslav Such? wrote: > > >On 01/17/2013 03:32 PM, Justin Sherrill wrote: > > >> > > >>Whats the reason selinux does not work on F17? Can we fix that? > > > > > >AVC denials on Pulp: > > > > > >Non-fatal POSTTRANS scriptlet failure in rpm package > > >pulp-selinux-server-1.1.12-1.fc17.noarch > > > > > >/sbin/restorecon: lstat(/usr/bin/pulp-admin) failed: No such > > >file or directory > > >/sbin/restorecon: lstat(/usr/bin/pulp-consumer) failed: No such > > >file or directory > > >/sbin/restorecon: lstat(/var/lib/pulp-cds) failed: No such file > > >or directory > > >/sbin/restorecon: lstat(/tmp/grinder) failed: No such file or > > >directory > > >warning: %posttrans(pulp-selinux-server-1.1.12-1.fc17.noarch) > > >scriptlet failed, exit status 1 > > > > > >I was ignoring it, because I assume that pulpv2 will be different > > >and already tested on F17. > > > > > > > > > > > Ah, if that's the problem I will make sure that it no longer is a > > problem with puplv2. If it is I am sure the pulp guys will be more > > willing to fix it than they would be with pulpv1. > > > > -Justin > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > -- > Later, > > Lukas "lzap" Zapletal > #katello #systemengine > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From msuchy at redhat.com Thu Mar 28 12:37:42 2013 From: msuchy at redhat.com (=?UTF-8?B?TWlyb3NsYXYgU3VjaMO9?=) Date: Thu, 28 Mar 2013 13:37:42 +0100 Subject: [katello-devel] Drop F16? In-Reply-To: <700583442.469255.1364464149483.JavaMail.root@redhat.com> References: <700583442.469255.1364464149483.JavaMail.root@redhat.com> Message-ID: <51543996.8020305@redhat.com> On 03/28/2013 10:49 AM, Ivan Necas wrote: > Was there other discussion that I missed that let to this PR to be merged? From this thread > I understood that we don't drop F16 until we have other Fedora working. We are pretty close > now but was that the case back then? > > https://github.com/Katello/katello/pull/1483 And additionally if you want to stop building for F16. This is not complete task. Those targets should be removed from katello-thirdparty.git candlepin pulp and all katello/foreman-* git repos. -- Miroslav Suchy Red Hat Systems Management Engineering From daviddavis at redhat.com Thu Mar 28 12:53:31 2013 From: daviddavis at redhat.com (David Davis) Date: Thu, 28 Mar 2013 08:53:31 -0400 (EDT) Subject: [katello-devel] Drop F16? In-Reply-To: <51543996.8020305@redhat.com> Message-ID: <457497830.26223032.1364475211222.JavaMail.root@redhat.com> I am still on F16. Why did no one tell me? David ----- Original Message ----- > From: "Miroslav Such?" > To: katello-devel at redhat.com > Sent: Thursday, March 28, 2013 8:37:42 AM > Subject: Re: [katello-devel] Drop F16? > > On 03/28/2013 10:49 AM, Ivan Necas wrote: > > Was there other discussion that I missed that let to this PR to be > > merged? From this thread > > I understood that we don't drop F16 until we have other Fedora > > working. We are pretty close > > now but was that the case back then? > > > > https://github.com/Katello/katello/pull/1483 > > And additionally if you want to stop building for F16. This is not > complete task. Those targets should be removed from > katello-thirdparty.git > candlepin > pulp > and all katello/foreman-* git repos. > > -- > Miroslav Suchy > Red Hat Systems Management Engineering > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From ericdhelms at gmail.com Thu Mar 28 19:01:59 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Thu, 28 Mar 2013 15:01:59 -0400 Subject: [katello-devel] Navigation Design - Better 1, Better 2 Message-ID: Howdy All, You may recall that we are working on a re-design of our header and navigation that started with - https://fedorahosted.org/katello/wiki/Navigation%20Enhancements After a few small iterations of implementation on my part, and discussion back and forth with Kyle we have narrowed in on two that we would like your feedback in choosing. These are not drastically different than what the link above presents, and the functionality with regard to scrolling (i.e. header collapsing and going with you) and dropdowns for sub-navigation remains the same. So, just like the eye doctor would ask, better 1: https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png or better 2: https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From omaciel at redhat.com Thu Mar 28 19:14:57 2013 From: omaciel at redhat.com (Og Maciel) Date: Thu, 28 Mar 2013 15:14:57 -0400 (EDT) Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: Message-ID: <346756833.62520362.1364498097989.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eric D Helms" > To: "katello-devel" > Sent: Thursday, March 28, 2013 3:01:59 PM > Subject: [katello-devel] Navigation Design - Better 1, Better 2 > So, just like the eye doctor would ask, better 1: > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png +1 btw, WOW! -- Og Maciel Supervisor, Quality Engineering Red Hat, Inc. +1.646.707.7723 irc: omaciel From daviddavis at redhat.com Thu Mar 28 19:17:14 2013 From: daviddavis at redhat.com (David Davis) Date: Thu, 28 Mar 2013 15:17:14 -0400 (EDT) Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: Message-ID: <1969921508.26494160.1364498234700.JavaMail.root@redhat.com> I like both but the first one is easier to read so I think I prefer it slightly. David ----- Original Message ----- > From: "Eric D Helms" > To: "katello-devel" > Sent: Thursday, March 28, 2013 3:01:59 PM > Subject: [katello-devel] Navigation Design - Better 1, Better 2 > > > > Howdy All, > > > You may recall that we are working on a re-design of our header and > navigation that started with - > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > > After a few small iterations of implementation on my part, and > discussion back and forth with Kyle we have narrowed in on two that > we would like your feedback in choosing. These are not drastically > different than what the link above presents, and the functionality > with regard to scrolling (i.e. header collapsing and going with you) > and dropdowns for sub-navigation remains the same. > > > So, just like the eye doctor would ask, better 1: > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png > > > > or better 2: > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png > > > > > > Thanks, > Eric > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Thu Mar 28 19:25:52 2013 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 28 Mar 2013 15:25:52 -0400 Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: <1969921508.26494160.1364498234700.JavaMail.root@redhat.com> References: <1969921508.26494160.1364498234700.JavaMail.root@redhat.com> Message-ID: <51549940.7080106@redhat.com> On 03/28/2013 03:17 PM, David Davis wrote: > I like both but the first one is easier to read so I think I prefer it slightly. > > David > > ----- Original Message ----- >> From: "Eric D Helms" >> To: "katello-devel" >> Sent: Thursday, March 28, 2013 3:01:59 PM >> Subject: [katello-devel] Navigation Design - Better 1, Better 2 >> >> >> >> Howdy All, >> >> >> You may recall that we are working on a re-design of our header and >> navigation that started with - >> https://fedorahosted.org/katello/wiki/Navigation%20Enhancements >> >> >> After a few small iterations of implementation on my part, and >> discussion back and forth with Kyle we have narrowed in on two that >> we would like your feedback in choosing. These are not drastically >> different than what the link above presents, and the functionality >> with regard to scrolling (i.e. header collapsing and going with you) >> and dropdowns for sub-navigation remains the same. >> >> >> So, just like the eye doctor would ask, better 1: >> >> >> https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png >> >> >> +1 -- bk From sthirugn at redhat.com Thu Mar 28 19:29:18 2013 From: sthirugn at redhat.com (Sureshkumar Thirugnanasambandan) Date: Thu, 28 Mar 2013 15:29:18 -0400 (EDT) Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: Message-ID: <170672199.16704789.1364498958021.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eric D Helms" > To: "katello-devel" > Sent: Thursday, March 28, 2013 3:01:59 PM > Subject: [katello-devel] Navigation Design - Better 1, Better 2 > > > > Howdy All, > > > You may recall that we are working on a re-design of our header and > navigation that started with - > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > > After a few small iterations of implementation on my part, and > discussion back and forth with Kyle we have narrowed in on two that > we would like your feedback in choosing. These are not drastically > different than what the link above presents, and the functionality > with regard to scrolling (i.e. header collapsing and going with you) > and dropdowns for sub-navigation remains the same. > > > So, just like the eye doctor would ask, better 1: > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png +1 to Better 1 > > > or better 2: > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png > > > > > > Thanks, > Eric > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Suresh Thirugnanasambandan| Sr. Quality Engineer | irc: sthirugn From bbuckingham at redhat.com Thu Mar 28 19:45:33 2013 From: bbuckingham at redhat.com (Brad Buckingham) Date: Thu, 28 Mar 2013 15:45:33 -0400 Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: <51549940.7080106@redhat.com> References: <1969921508.26494160.1364498234700.JavaMail.root@redhat.com> <51549940.7080106@redhat.com> Message-ID: <51549DDD.8090501@redhat.com> On 03/28/2013 03:25 PM, Bryan Kearney wrote: > On 03/28/2013 03:17 PM, David Davis wrote: >> I like both but the first one is easier to read so I think I prefer >> it slightly. >> >> David >> >> ----- Original Message ----- >>> From: "Eric D Helms" >>> To: "katello-devel" >>> Sent: Thursday, March 28, 2013 3:01:59 PM >>> Subject: [katello-devel] Navigation Design - Better 1, Better 2 >>> >>> >>> >>> Howdy All, >>> >>> >>> You may recall that we are working on a re-design of our header and >>> navigation that started with - >>> https://fedorahosted.org/katello/wiki/Navigation%20Enhancements >>> >>> >>> After a few small iterations of implementation on my part, and >>> discussion back and forth with Kyle we have narrowed in on two that >>> we would like your feedback in choosing. These are not drastically >>> different than what the link above presents, and the functionality >>> with regard to scrolling (i.e. header collapsing and going with you) >>> and dropdowns for sub-navigation remains the same. >>> >>> >>> So, just like the eye doctor would ask, better 1: >>> >>> >>> https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png >>> >>> >>> >>> > > +1 > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel +1 on better one, primarily because it is easier to see where you are due to the stronger color contrast From thomasmckay at redhat.com Thu Mar 28 20:05:38 2013 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 28 Mar 2013 16:05:38 -0400 (EDT) Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: Message-ID: <1185788936.20885722.1364501138277.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eric D Helms" > To: "katello-devel" > Sent: Thursday, March 28, 2013 3:01:59 PM > Subject: [katello-devel] Navigation Design - Better 1, Better 2 > > > > Howdy All, > > > You may recall that we are working on a re-design of our header and > navigation that started with - > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > > After a few small iterations of implementation on my part, and > discussion back and forth with Kyle we have narrowed in on two that > we would like your feedback in choosing. These are not drastically > different than what the link above presents, and the functionality > with regard to scrolling (i.e. header collapsing and going with you) > and dropdowns for sub-navigation remains the same. > > > So, just like the eye doctor would ask, better 1: > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png > #1 but with the org named blue like in #2 (and then let me customize color to display org name in :) > > > or better 2: > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png > > > > > > Thanks, > Eric > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Thu Mar 28 20:09:44 2013 From: mmccune at redhat.com (Mike McCune) Date: Thu, 28 Mar 2013 13:09:44 -0700 Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: References: Message-ID: <5154A388.1070105@redhat.com> On 03/28/2013 12:01 PM, Eric D Helms wrote: > Howdy All, > > You may recall that we are working on a re-design of our header and > navigation that started with - > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > After a few small iterations of implementation on my part, and > discussion back and forth with Kyle we have narrowed in on two that we > would like your feedback in choosing. These are not drastically > different than what the link above presents, and the functionality with > regard to scrolling (i.e. header collapsing and going with you) and > dropdowns for sub-navigation remains the same. > > So, just like the eye doctor would ask, better 1: > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png > > or better 2: > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png > > I like both but I'll have to pick #2. Most of our page is white and I like that the header elements (nav and logo) are a much darker color than the rest of the page in #2. I don't dislike #1 but I like that with #2 have the whole header and nav that stands out in contrast to the rest of the page. either way, they are both great thou Mike From jweiss at redhat.com Thu Mar 28 20:15:24 2013 From: jweiss at redhat.com (Jeff Weiss) Date: Thu, 28 Mar 2013 16:15:24 -0400 Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: References: Message-ID: <87ip4bi8mb.fsf@blinky.jweiss.com> Eric D Helms writes: > Howdy All, > > You may recall that we are working on a re-design of our header and > navigation that started with - > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > After a few small iterations of implementation on my part, and discussion > back and forth with Kyle we have narrowed in on two that we would like your > feedback in choosing. These are not drastically different than what the > link above presents, and the functionality with regard to scrolling (i.e. > header collapsing and going with you) and dropdowns for sub-navigation > remains the same. > > So, just like the eye doctor would ask, better 1: > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png > > or better 2: > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png > > > Thanks, > Eric > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel My vote is for #2. It more clearly shows the difference between the menu and the breadcrumb (the menu is blue and the breadcrumb is white). The new design is a big improvement. There's one minor issue I'd like to bring up and that is fixing the menu at the top of the screen even when the user scrolls down. I don't think this is worth the effort and complexity. Yes, it saves the user from pressing the "Home" key to see the menu again, but it also permanently takes up screen space. IMO it is no improvement overall, and so the easiest thing to do is leave it as a "normal" page where everything scrolls off the top or bottom. -- Jeff Weiss Principal Quality Assurance Engineer jweiss at redhat.com (919)886-6533 From ericdhelms at gmail.com Thu Mar 28 20:24:44 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Thu, 28 Mar 2013 16:24:44 -0400 Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: <87ip4bi8mb.fsf@blinky.jweiss.com> References: <87ip4bi8mb.fsf@blinky.jweiss.com> Message-ID: On Thu, Mar 28, 2013 at 4:15 PM, Jeff Weiss wrote: > Eric D Helms writes: > > > Howdy All, > > > > You may recall that we are working on a re-design of our header and > > navigation that started with - > > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > > > After a few small iterations of implementation on my part, and discussion > > back and forth with Kyle we have narrowed in on two that we would like > your > > feedback in choosing. These are not drastically different than what the > > link above presents, and the functionality with regard to scrolling (i.e. > > header collapsing and going with you) and dropdowns for sub-navigation > > remains the same. > > > > So, just like the eye doctor would ask, better 1: > > > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png > > > > or better 2: > > > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png > > > > > > Thanks, > > Eric > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > My vote is for #2. It more clearly shows the difference between the > menu and the breadcrumb (the menu is blue and the breadcrumb is white). > > The new design is a big improvement. There's one minor issue I'd like > to bring up and that is fixing the menu at the top of the screen even > when the user scrolls down. I don't think this is worth the effort and > complexity. Yes, it saves the user from pressing the "Home" key to see > the menu again, but it also permanently takes up screen space. IMO it > is no improvement overall, and so the easiest thing to do is leave it as > a "normal" page where everything scrolls off the top or bottom. > > Around the complexity and effort argument - the time to implement that is roughly 5-10 minutes. The argument around taking up screen space is I feel minor given it's only about 35 pixels high, as well as it allows quicker navigation and provides access to notifications which are going to play a bigger and less obtrusive role in the future. -- > Jeff Weiss > Principal Quality Assurance Engineer > jweiss at redhat.com > (919)886-6533 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsherril at redhat.com Thu Mar 28 21:21:39 2013 From: jsherril at redhat.com (Justin Sherrill) Date: Thu, 28 Mar 2013 17:21:39 -0400 Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: References: Message-ID: <5154B463.5030704@redhat.com> On 03/28/2013 03:01 PM, Eric D Helms wrote: > Howdy All, > > You may recall that we are working on a re-design of our header and > navigation that started with - > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > After a few small iterations of implementation on my part, and > discussion back and forth with Kyle we have narrowed in on two that we > would like your feedback in choosing. These are not drastically > different than what the link above presents, and the functionality > with regard to scrolling (i.e. header collapsing and going with you) > and dropdowns for sub-navigation remains the same. > > So, just like the eye doctor would ask, better 1: > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png > > or better 2: > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png > > > Thanks, > Eric > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I actually like #2 better. I feel like it helps separate the nav from the page better. It also feels like #1 divides up the page into 3 sections whereas #2 feels more like 2 sections which i like better. Both are better than what we have now though! -Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: From paji at redhat.com Thu Mar 28 22:35:59 2013 From: paji at redhat.com (Partha Aji) Date: Thu, 28 Mar 2013 18:35:59 -0400 (EDT) Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: <5154A388.1070105@redhat.com> Message-ID: <185395927.8065532.1364510159356.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Mike McCune" > To: "Eric D Helms" > Cc: "katello-devel" > Sent: Thursday, March 28, 2013 4:09:44 PM > Subject: Re: [katello-devel] Navigation Design - Better 1, Better 2 > > On 03/28/2013 12:01 PM, Eric D Helms wrote: > > Howdy All, > > > > You may recall that we are working on a re-design of our header and > > navigation that started with - > > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > > > After a few small iterations of implementation on my part, and > > discussion back and forth with Kyle we have narrowed in on two that > > we > > would like your feedback in choosing. These are not drastically > > different than what the link above presents, and the functionality > > with > > regard to scrolling (i.e. header collapsing and going with you) and > > dropdowns for sub-navigation remains the same. > > > > So, just like the eye doctor would ask, better 1: > > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png > > > > or better 2: > > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png > > > > > > I like both but I'll have to pick #2. Most of our page is white and > I > like that the header elements (nav and logo) are a much darker color > than the rest of the page in #2. > > I don't dislike #1 but I like that with #2 have the whole header and > nav > that stands out in contrast to the rest of the page. either way, > they > are both great thou > > Mike > I like 2 myself for the same reason... From tkolhar at redhat.com Fri Mar 29 04:46:23 2013 From: tkolhar at redhat.com (Tazim Kolhar) Date: Fri, 29 Mar 2013 00:46:23 -0400 (EDT) Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: Message-ID: <1928249623.3305688.1364532383537.JavaMail.root@redhat.com> Hi, > ----- Original Message ----- > From: "Eric D Helms" > To: "katello-devel" > Sent: Friday, March 29, 2013 12:31:59 AM > Subject: [katello-devel] Navigation Design - Better 1, Better 2 > > > > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png Thanks and Regards, Tazim. From gkhachik at redhat.com Fri Mar 29 08:16:10 2013 From: gkhachik at redhat.com (Garik Khachikyan) Date: Fri, 29 Mar 2013 09:16:10 +0100 Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: References: Message-ID: <51554DCA.7030101@redhat.com> I would say: wow! really awesome design. My choice is: Better 2. Also having an option to customize the colour theme there (like "red", light-blue, whatever) thanks Garik On 28/03/13 20:01, Eric D Helms wrote: > Howdy All, > > You may recall that we are working on a re-design of our header and > navigation that started with - > https://fedorahosted.org/katello/wiki/Navigation%20Enhancements > > After a few small iterations of implementation on my part, and > discussion back and forth with Kyle we have narrowed in on two that we > would like your feedback in choosing. These are not drastically > different than what the link above presents, and the functionality > with regard to scrolling (i.e. header collapsing and going with you) > and dropdowns for sub-navigation remains the same. > > So, just like the eye doctor would ask, better 1: > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-1.png > > or better 2: > > https://fedorahosted.org/katello/attachment/wiki/Navigation%20Enhancements/Screen-2.png > > > Thanks, > Eric > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From inecas at redhat.com Fri Mar 29 09:35:26 2013 From: inecas at redhat.com (Ivan Necas) Date: Fri, 29 Mar 2013 05:35:26 -0400 (EDT) Subject: [katello-devel] Removing Foreman specific UI in faviour of Foreman UI Message-ID: <982224699.889451.1364549726503.JavaMail.root@redhat.com> Hi, With recent movement towards exposing the Foreman UI directly instead of building the screens again in Katello, I think it makes sense remove that UI (and probably API as well) from Katello and focus our efforts to foreman-katello-engine [1] instead. Opinions? [1] - https://github.com/Katello/foreman-katello-engine -- Ivan From msuchy at redhat.com Fri Mar 29 14:24:23 2013 From: msuchy at redhat.com (Miroslav Suchy) Date: Fri, 29 Mar 2013 15:24:23 +0100 Subject: [katello-devel] Current status of Foreman on rails32 Message-ID: <5155A417.8070001@redhat.com> I successfully built Foreman with rails32 - but there is still work to do: I applied https://github.com/theforeman/foreman/pull/487 to our foreman-build and made (big thanks to inecas) some other changes - see attachment. Sam - feel free to take it and apply to foreman-rpms. With this change I was able to do scratch build: http://koji.katello.org/koji/taskinfo?taskID=28403 But with the package installed the FQDN/foreman produce: Started GET "/foreman/users/login" for 127.0.0.1 at 2013-03-29 10:04:17 -0400 Processing by UsersController#login as HTML Rendered users/login.html.erb within layouts/application (72.3ms) Operation FAILED: foreman_large.png isn't precompiled Rendered common/500.html.erb within layouts/application (3.4ms) Rendered home/_topbar.html.erb (1.3ms) Completed 500 Internal Server Error in 160ms ActionView::Template::Error (foreman.png isn't precompiled): 8: 9: 10: 11: <%=image_tag("foreman.png", :class=>"logo") %> <%= link_to "Foreman", root_path, :class => "brand logo-text" %> 12: 13:
14: app/views/home/_topbar.html.erb:11:in `_app_views_home__topbar_html_erb___4411891742568325370_65630400' app/views/layouts/application.html.erb:21:in `_app_views_layouts_application_html_erb___534119209898294087_38977780' app/controllers/application_controller.rb:291:in `generic_exception' Despite that # ls /usr/share/foreman/public/assets/ application.css application.css.gz application.js application.js.gz fontawesome-webfont.eot fontawesome-webfont.ttf fontawesome-webfont.woff jquery-ui manifest.yml noVNC spinner.gif twitter is present. Will continue with the investigation on Monday. Mirek -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-foo.patch Type: text/x-patch Size: 7817 bytes Desc: not available URL: From lzap at redhat.com Fri Mar 29 15:01:26 2013 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 29 Mar 2013 16:01:26 +0100 Subject: [katello-devel] Removing Foreman specific UI in faviour of Foreman UI In-Reply-To: <982224699.889451.1364549726503.JavaMail.root@redhat.com> References: <982224699.889451.1364549726503.JavaMail.root@redhat.com> Message-ID: <20130329150126.GG1728@lzapx.brq.redhat.com> +1 LZ On Fri, Mar 29, 2013 at 05:35:26AM -0400, Ivan Necas wrote: > Hi, > > With recent movement towards exposing the Foreman UI directly instead of building > the screens again in Katello, I think it makes sense remove that UI (and probably API > as well) from Katello and focus our efforts to foreman-katello-engine [1] instead. > > Opinions? > > [1] - https://github.com/Katello/foreman-katello-engine > > -- Ivan > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Fri Mar 29 17:57:21 2013 From: msuchy at redhat.com (Miroslav Suchy) Date: Fri, 29 Mar 2013 18:57:21 +0100 Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: <5154A388.1070105@redhat.com> References: <5154A388.1070105@redhat.com> Message-ID: <5155D601.5010208@redhat.com> On 28.3.2013 21:09, Mike McCune wrote: > I don't dislike #1 but I like that with #2 have the whole header and nav > that stands out in contrast to the rest of the page. either way, they > are both great thou ditto. I like the #2, but mostly because the second level navigation (Content >> Subscription >> RH Subscription) is darker there and therefore more readable. BTW why we use those gray on fonts? Whats wrong with pure black? Mirek From ericdhelms at gmail.com Fri Mar 29 18:41:35 2013 From: ericdhelms at gmail.com (Eric D Helms) Date: Fri, 29 Mar 2013 14:41:35 -0400 Subject: [katello-devel] Navigation Design - Better 1, Better 2 In-Reply-To: <5155D601.5010208@redhat.com> References: <5154A388.1070105@redhat.com> <5155D601.5010208@redhat.com> Message-ID: I just want to re-iterate, the breadcrumbs are in no way designed to be a navigational tool, but rather an indicator of where you are. The inclusion of them is a design response to people expressing a requirement that they know where they are within the application. All navigation will occur via the navigation bar and dropdowns. This is also why lighter fonts are used to de-emphasize the importance of these breadcrumbs in comparison to the rest of the content on the page. - Eric On Fri, Mar 29, 2013 at 1:57 PM, Miroslav Suchy wrote: > On 28.3.2013 21:09, Mike McCune wrote: > >> I don't dislike #1 but I like that with #2 have the whole header and nav >> that stands out in contrast to the rest of the page. either way, they >> are both great thou >> > > ditto. > I like the #2, but mostly because the second level navigation (Content >> > Subscription >> RH Subscription) is darker there and therefore more > readable. > > BTW why we use those gray on fonts? Whats wrong with pure black? > > Mirek > > > ______________________________**_________________ > 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: