From lzap at redhat.com Fri Jun 1 10:14:34 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 1 Jun 2012 12:14:34 +0200 Subject: [katello-devel] Katello installation issues In-Reply-To: References: Message-ID: <20120601101434.GA13692@lzapx.brq.redhat.com> Vikash, please use this workaround: https://fedorahosted.org/pipermail/katello/2012-May/000303.html LZ On Fri, Jun 01, 2012 at 09:27:34AM +1000, Vikash Gounder wrote: > Hi, > > I tried installing Katello on fedora 16 using the instructions as per > install wiki. > > this is what i got when doing katello-configure > > katello-configure > Starting Katello configuration > The top-level log file is > [/var/log/katello/katello-configure-20120601-084146/main.log] > Creating Katello database user > ############################################################ ... OK > Creating Katello database > ############################################################ ... OK > Creating Candlepin database user > ############################################################ ... OK > Candlepin setup > > Failed, please check [/var/log/katello/katello-configure/cpsetup.log] > > > and contents of cpsetup.log are: > > ########## ERROR ############ > Error running command: /usr/share/candlepin/cpdb --create -u candlepin > --database candlepin > Status code: 256 > Command output: > ########## ERROR ############ > Error running command: liquibase --driver=org.postgresql.Driver > --classpath=/usr/share/java/postgresql-jdbc.ja > r:/var/lib/tomcat6/webapps/candlepin/WEB-INF/classes/ > --changeLogFile=db/changelog/changelog-create.xml --url= > jdbc:postgresql:candlepin --username=candlepin migrate > Status code: 32512 > Command output: sh: liquibase: command not found > Creating candlepin database > Loading candlepin schema > Traceback (most recent call last): > File "/usr/share/candlepin/cpdb", line 126, in > dbsetup.create() > File "/usr/share/candlepin/cpdb", line 61, in create > self._run_liquibase("db/changelog/changelog-create.xml") > File "/usr/share/candlepin/cpdb", line 91, in _run_liquibase > self.username, > File "/usr/share/candlepin/cpdb", line 32, in run_command > error_out(command, status, output) > File "/usr/share/candlepin/cpdb", line 40, in error_out > raise Exception("Error running command") > Exception: Error running command > Traceback (most recent call last): > File "/usr/share/candlepin/cpsetup", line 221, in > main(sys.argv[1:]) > File "/usr/share/candlepin/cpsetup", line 201, in main > options.dbuser, options.db)) > File "/usr/share/candlepin/cpsetup", line 42, in run_command > raise Exception("Error running command") > Exception: Error running command > > seems like candlepin is not able to find postgresql java driver files > > would appreciate someone's help on it as it is a show stopper. > > thanks > Vikash > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From jrist at redhat.com Fri Jun 1 13:54:12 2012 From: jrist at redhat.com (Jason Rist) Date: Fri, 01 Jun 2012 07:54:12 -0600 Subject: [katello-devel] Useful Rails Console Tips Message-ID: <4FC8C984.9010003@redhat.com> http://37signals.com/svn/posts/3176-three-quick-rails-console-tips -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From inecas at redhat.com Fri Jun 1 13:58:21 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Fri, 01 Jun 2012 15:58:21 +0200 Subject: [katello-devel] Useful Rails Console Tips In-Reply-To: <4FC8C984.9010003@redhat.com> References: <4FC8C984.9010003@redhat.com> Message-ID: <4FC8CA7D.5040603@redhat.com> On 06/01/2012 03:54 PM, Jason Rist wrote: > http://37signals.com/svn/posts/3176-three-quick-rails-console-tips Talking about console: http://pry.github.com/ Very useful as irb replacement as well as debugging tool. Worth trying. -- Ivan From jrist at redhat.com Fri Jun 1 14:02:32 2012 From: jrist at redhat.com (Jason Rist) Date: Fri, 01 Jun 2012 08:02:32 -0600 Subject: [katello-devel] Recent Mega Merge (aka Pull 161) Message-ID: <4FC8CB78.7010801@redhat.com> Hey Everyone - The pull request 161 includes some changed conventions: 1.) New images that are less than 32kb go into embed folder - in the future we'd like to be able to embed images into the CSS which means literally no image loading (or extra network calls). Please put new images that are less than 32kb and declared a single time into the embed or embed/icons folder. See: http://documentcloud.github.com/jammit/#embedding for reference. 2.) If you need the spinner in your code, and you would have previously done it with =image_tag..., please use just `.spinner` - this includes the spinner CSS and image call, so you don't need to use the image tag for something that is already declared (and likely available on the page already). Thanks! Jason -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jomara at redhat.com Fri Jun 1 21:18:07 2012 From: jomara at redhat.com (Jordan OMara) Date: Fri, 1 Jun 2012 17:18:07 -0400 Subject: [katello-devel] katello-headpin returns to community build Message-ID: <20120601211807.GF6148@redhat.com> The standard builder will now release katello-headpin along with everything else. Enjoy! -- Jordan O'Mara Red Hat Engineering, Raleigh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From bkearney at redhat.com Fri Jun 1 21:20:41 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 01 Jun 2012 17:20:41 -0400 Subject: [katello-devel] katello-headpin returns to community build In-Reply-To: <20120601211807.GF6148@redhat.com> References: <20120601211807.GF6148@redhat.com> Message-ID: <4FC93229.6070508@redhat.com> On 06/01/2012 05:18 PM, Jordan OMara wrote: > The standard builder will now release katello-headpin along with > everything else. Enjoy! > w00t! what was the fix? Does tito support multiple spec files now? -- bk From jomara at redhat.com Fri Jun 1 22:00:42 2012 From: jomara at redhat.com (Jordan OMara) Date: Fri, 1 Jun 2012 18:00:42 -0400 Subject: [katello-devel] katello-headpin returns to community build In-Reply-To: <4FC93229.6070508@redhat.com> References: <20120601211807.GF6148@redhat.com> <4FC93229.6070508@redhat.com> Message-ID: <20120601220041.GG6148@redhat.com> On 01/06/12 17:20 -0400, Bryan Kearney wrote: >On 06/01/2012 05:18 PM, Jordan OMara wrote: >>The standard builder will now release katello-headpin along with >>everything else. Enjoy! >> > >w00t! > >what was the fix? Does tito support multiple spec files now? > I wish! lots of scripting -- 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 coolvixs at gmail.com Mon Jun 4 00:15:19 2012 From: coolvixs at gmail.com (Vikash Gounder) Date: Mon, 4 Jun 2012 10:15:19 +1000 Subject: [katello-devel] Katello installation issues In-Reply-To: <20120601101434.GA13692@lzapx.brq.redhat.com> References: <20120601101434.GA13692@lzapx.brq.redhat.com> Message-ID: Lukas, Thanks for that, seems like the packages on the repos has been updated to cater for the errors, after removing everything and starting from fresh resolved the issues. Thanks and appreciate all your help. on another note, i have whole bunch of centos 5 clients, are there subscription-manager packages that would allow for subscription with katello?? thanks Vikash On Fri, Jun 1, 2012 at 8:14 PM, Lukas Zapletal wrote: > Vikash, > > please use this workaround: > > https://fedorahosted.org/pipermail/katello/2012-May/000303.html > > LZ > > On Fri, Jun 01, 2012 at 09:27:34AM +1000, Vikash Gounder wrote: > > Hi, > > > > I tried installing Katello on fedora 16 using the instructions as per > > install wiki. > > > > this is what i got when doing katello-configure > > > > katello-configure > > Starting Katello configuration > > The top-level log file is > > [/var/log/katello/katello-configure-20120601-084146/main.log] > > Creating Katello database user > > ############################################################ ... OK > > Creating Katello database > > ############################################################ ... OK > > Creating Candlepin database user > > ############################################################ ... OK > > Candlepin setup > > > > Failed, please check [/var/log/katello/katello-configure/cpsetup.log] > > > > > > and contents of cpsetup.log are: > > > > ########## ERROR ############ > > Error running command: /usr/share/candlepin/cpdb --create -u candlepin > > --database candlepin > > Status code: 256 > > Command output: > > ########## ERROR ############ > > Error running command: liquibase --driver=org.postgresql.Driver > > --classpath=/usr/share/java/postgresql-jdbc.ja > > r:/var/lib/tomcat6/webapps/candlepin/WEB-INF/classes/ > > --changeLogFile=db/changelog/changelog-create.xml --url= > > jdbc:postgresql:candlepin --username=candlepin migrate > > Status code: 32512 > > Command output: sh: liquibase: command not found > > Creating candlepin database > > Loading candlepin schema > > Traceback (most recent call last): > > File "/usr/share/candlepin/cpdb", line 126, in > > dbsetup.create() > > File "/usr/share/candlepin/cpdb", line 61, in create > > self._run_liquibase("db/changelog/changelog-create.xml") > > File "/usr/share/candlepin/cpdb", line 91, in _run_liquibase > > self.username, > > File "/usr/share/candlepin/cpdb", line 32, in run_command > > error_out(command, status, output) > > File "/usr/share/candlepin/cpdb", line 40, in error_out > > raise Exception("Error running command") > > Exception: Error running command > > Traceback (most recent call last): > > File "/usr/share/candlepin/cpsetup", line 221, in > > main(sys.argv[1:]) > > File "/usr/share/candlepin/cpsetup", line 201, in main > > options.dbuser, options.db)) > > File "/usr/share/candlepin/cpsetup", line 42, in run_command > > raise Exception("Error running command") > > Exception: Error running command > > > > seems like candlepin is not able to find postgresql java driver files > > > > would appreciate someone's help on it as it is a show stopper. > > > > thanks > > Vikash > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From inecas at redhat.com Mon Jun 4 09:12:31 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Mon, 04 Jun 2012 11:12:31 +0200 Subject: [katello-devel] API versioning Message-ID: <4FCC7BFF.2000407@redhat.com> Hello, There has been a discussion about API versioning in foreman-dev [1] recently. Since we are ahead of API changes (both adding features and refactoring old calls), I would like to open this discussion for Katello as well. There are two links mentioned talking about using namespaces for that purpose [2] [3] (Github works this way as well, Twitter goes the similar way as well). So basically there would be 'katello/api/v1/?' for the old version and 'katello/api/v2/?' for the new one. This would help us with the migration phase where some users might still rely on the old API for some time and give them time to migrate to new version of the API. When the V2 API is stable, the old one would get depreciated and eventually removed. What do you thing about this approach? [1] - https://groups.google.com/group/foreman-dev/browse_thread/thread/dc7a099ab75360f4 [2] - http://freelancing-gods.com/posts/versioning_your_ap_is [3] - http://railscasts.com/episodes/350-rest-api-versioning?autoplay=true -- Ivan From ewoud+katello at kohlvanwijngaarden.nl Mon Jun 4 09:46:01 2012 From: ewoud+katello at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Mon, 4 Jun 2012 11:46:01 +0200 Subject: [katello-devel] API versioning In-Reply-To: <4FCC7BFF.2000407@redhat.com> References: <4FCC7BFF.2000407@redhat.com> Message-ID: <20120604094601.GB28861@bogey.xentower.nl> On Mon, Jun 04, 2012 at 11:12:31AM +0200, Ivan Ne?as wrote: > There has been a discussion about API versioning in foreman-dev [1] > recently. Since we are ahead of API changes (both adding features > and refactoring old calls), I would like to open this discussion for > Katello as well. There are two links mentioned talking about using > namespaces for that purpose [2] [3] (Github works this way as well, > Twitter goes the similar way as well). > > So basically there would be 'katello/api/v1/?' for the old version > and 'katello/api/v2/?' for the new one. This would help us with the > migration phase where some users might still rely on the old API for > some time and give them time to migrate to new version of the API. > When the V2 API is stable, the old one would get depreciated and > eventually removed. > > What do you thing about this approach? A while back I had a similar discussion with Geert (CC'ed) about API versioning, but I don't see a chapter about it in his book[1]. I think his opinion was to avoid explicit versions in the URL if possible. That said, I'm not (yet) familiar with the Katello API so maybe it's unavoidable. [1]: http://readthedocs.org/docs/restful-api-design/en/latest/ From pchalupa at redhat.com Tue Jun 5 15:51:39 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 05 Jun 2012 17:51:39 +0200 Subject: [katello-devel] Another reason for manifest-import to be asynchronous In-Reply-To: <4FBF97AD.8000106@redhat.com> References: <4FBE2D0B.5080201@redhat.com> <4FBF81F3.9060301@redhat.com> <4FBF83C9.3090602@redhat.com> <4FBF8E96.50704@redhat.com> <4FBF97AD.8000106@redhat.com> Message-ID: <4FCE2B0B.5060908@redhat.com> I've implemented the delayed repository creation for manifest import. stageSamTest20Nov2011.zip 943.4s 15.7min with repository creation 419.5s 6.9min with delayed repository creation stageSamTestSimple20Nov2011.zip 208.0s 3.4min with repository creation 116.4s 1.9min with delayed repository creation It's faster but I think it's still too slow for synchronous action. +1 to make it asynchronous. If manifest import is asynchronous I will suggest not to merge these changes, because: - It makes code more complicated and fragile, until now repositories always had its repository in pulp. I still have some bugs in cli-tests to hunt. - I think, it will not deliver much value for users if import is asynchronous. What do you think? Petr On 25.05.12 16:31, Mike McCune wrote: > On 05/25/2012 06:52 AM, Brad Buckingham wrote: >> On 05/25/2012 09:06 AM, Ivan Ne?as wrote: >>> On 05/25/2012 02:58 PM, Bryan Kearney wrote: >>>> On 05/24/2012 08:43 AM, Ivan Ne?as wrote: >>>>> Hi, >>>>> >>>>> I've been working on z stream bug >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=823890, the solution >>>>> (https://github.com/Katello/katello/pull/144) is to remote the >>>>> products >>>>> (including repositories) that were removed from the newly-imported >>>>> manifest. This slows down of the manifest import - time is needed for >>>>> removing the repositories which is not big problem for unsynchronized >>>>> repos, but there might be significant change for repositories already >>>>> synchronized. >>>>> >>>>> I would like to get more ideas on this. Is this the right time to move >>>>> manifest import to asynchronous state. >>>>> >>>>> Also removing repositories (not only in this case) causes records >>>>> about >>>>> their promotions in changeset to vanish. We probably need other >>>>> (softer) >>>>> mechanism for removing repositories that still leaves some marks that >>>>> the repository was there once. >>>>> >>>> The user can really not do much else while the import is going on. >>>> But.. i would be happy to add this to the backlog if the team wants to. >>> Yeah, but it's always a bit risky to let longer running tasks being >>> synchronous: in case of connection time-out the user is not properly >>> reported about the finish of the request. >>> >>> -- Ivan >> I am +1 for making it async, given that it is a really long running >> task. If we do that, we'll need to make sure the UI is updated so that >> users are able to determine that an import is in progress, if they >> navigate away from and back to the import page. >> >> That said, I thought there was some mention in the process of import >> changing in the future which would make it much faster. (e.g. Not >> importing repos that aren't going to be enabled). > > yes, if we go this route and skip the pulp repo creation during import > the actual transaction time is quite fast. On a manifest I edited to > only contain one repo the manifest imports in 2-3 seconds. > > If we remove the pulp repo creation, the need to make this task async is > much lessened but may still be helpful in the case that Lukas mentions > above where we need to go and delete repositories that are no longer in > the manifest. > > The priority of work should be: > > 1) take out pulp repo creation during manifest import > > 2) then decide if we should make it async > > Mike > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From mmccune at redhat.com Tue Jun 5 16:21:57 2012 From: mmccune at redhat.com (Mike McCune) Date: Tue, 05 Jun 2012 09:21:57 -0700 Subject: [katello-devel] Another reason for manifest-import to be asynchronous In-Reply-To: <4FCE2B0B.5060908@redhat.com> References: <4FBE2D0B.5080201@redhat.com> <4FBF81F3.9060301@redhat.com> <4FBF83C9.3090602@redhat.com> <4FBF8E96.50704@redhat.com> <4FBF97AD.8000106@redhat.com> <4FCE2B0B.5060908@redhat.com> Message-ID: <4FCE3225.6090604@redhat.com> odd that it still takes so much time. What is the bulk of the time now that repository creation is delayed? On 06/05/2012 08:51 AM, Petr Chalupa wrote: > I've implemented the delayed repository creation for manifest import. > > stageSamTest20Nov2011.zip > 943.4s 15.7min with repository creation > 419.5s 6.9min with delayed repository creation > > stageSamTestSimple20Nov2011.zip > 208.0s 3.4min with repository creation > 116.4s 1.9min with delayed repository creation > > It's faster but I think it's still too slow for synchronous action. > +1 to make it asynchronous. > > If manifest import is asynchronous I will suggest not to merge these > changes, because: > - It makes code more complicated and fragile, until now repositories > always had its repository in pulp. I still have some bugs in cli-tests > to hunt. > - I think, it will not deliver much value for users if import is > asynchronous. > > What do you think? > > Petr > > On 25.05.12 16:31, Mike McCune wrote: >> On 05/25/2012 06:52 AM, Brad Buckingham wrote: >>> On 05/25/2012 09:06 AM, Ivan Ne?as wrote: >>>> On 05/25/2012 02:58 PM, Bryan Kearney wrote: >>>>> On 05/24/2012 08:43 AM, Ivan Ne?as wrote: >>>>>> Hi, >>>>>> >>>>>> I've been working on z stream bug >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=823890, the solution >>>>>> (https://github.com/Katello/katello/pull/144) is to remote the >>>>>> products >>>>>> (including repositories) that were removed from the newly-imported >>>>>> manifest. This slows down of the manifest import - time is needed for >>>>>> removing the repositories which is not big problem for unsynchronized >>>>>> repos, but there might be significant change for repositories already >>>>>> synchronized. >>>>>> >>>>>> I would like to get more ideas on this. Is this the right time to move >>>>>> manifest import to asynchronous state. >>>>>> >>>>>> Also removing repositories (not only in this case) causes records >>>>>> about >>>>>> their promotions in changeset to vanish. We probably need other >>>>>> (softer) >>>>>> mechanism for removing repositories that still leaves some marks that >>>>>> the repository was there once. >>>>>> >>>>> The user can really not do much else while the import is going on. >>>>> But.. i would be happy to add this to the backlog if the team wants to. >>>> Yeah, but it's always a bit risky to let longer running tasks being >>>> synchronous: in case of connection time-out the user is not properly >>>> reported about the finish of the request. >>>> >>>> -- Ivan >>> I am +1 for making it async, given that it is a really long running >>> task. If we do that, we'll need to make sure the UI is updated so that >>> users are able to determine that an import is in progress, if they >>> navigate away from and back to the import page. >>> >>> That said, I thought there was some mention in the process of import >>> changing in the future which would make it much faster. (e.g. Not >>> importing repos that aren't going to be enabled). >> >> yes, if we go this route and skip the pulp repo creation during import >> the actual transaction time is quite fast. On a manifest I edited to >> only contain one repo the manifest imports in 2-3 seconds. >> >> If we remove the pulp repo creation, the need to make this task async is >> much lessened but may still be helpful in the case that Lukas mentions >> above where we need to go and delete repositories that are no longer in >> the manifest. >> >> The priority of work should be: >> >> 1) take out pulp repo creation during manifest import >> >> 2) then decide if we should make it async >> >> Mike >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From thomasmckay at redhat.com Tue Jun 5 19:49:11 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 05 Jun 2012 15:49:11 -0400 (EDT) Subject: [katello-devel] incorporating community translations through transifex into katello In-Reply-To: <10a53da7-16dc-4461-a8e2-b4a7d89b8ae8@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <91da6e76-3d78-4c83-a7c2-73a8bd0bbbd0@zmail16.collab.prod.int.phx2.redhat.com> All, Og Maciel and I are going to begin figuring out how we can leverage the wider translation community for katello. If you have an interest in this topic, please let us know and we'll gladly include you. We'll send out updates as things progress and will certainly talk about any results in the sprint reviews. My intention is not to count this project as part of sprint loading, though, and consider it more of a "it's the right thing to do" project (ie. We're part of the community!). Tom From jrist at redhat.com Tue Jun 5 19:54:51 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 05 Jun 2012 13:54:51 -0600 Subject: [katello-devel] incorporating community translations through transifex into katello In-Reply-To: <91da6e76-3d78-4c83-a7c2-73a8bd0bbbd0@zmail16.collab.prod.int.phx2.redhat.com> References: <10a53da7-16dc-4461-a8e2-b4a7d89b8ae8@zmail16.collab.prod.int.phx2.redhat.com> <91da6e76-3d78-4c83-a7c2-73a8bd0bbbd0@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4FCE640B.30805@redhat.com> On Tue 05 Jun 2012 01:49:11 PM MDT, Tom McKay wrote: > All, > > Og Maciel and I are going to begin figuring out how we can leverage the wider translation community for katello. If you have an interest in this topic, please let us know and we'll gladly include you. We'll send out updates as things progress and will certainly talk about any results in the sprint reviews. My intention is not to count this project as part of sprint loading, though, and consider it more of a "it's the right thing to do" project (ie. We're part of the community!). > > Tom > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I am interested. I'm curious about our future RTL integration (if that is desired) and how that might work from the translation and UI side. -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bkearney at redhat.com Tue Jun 5 19:55:35 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 05 Jun 2012 15:55:35 -0400 Subject: [katello-devel] Another reason for manifest-import to be asynchronous In-Reply-To: <4FCE3225.6090604@redhat.com> References: <4FBE2D0B.5080201@redhat.com> <4FBF81F3.9060301@redhat.com> <4FBF83C9.3090602@redhat.com> <4FBF8E96.50704@redhat.com> <4FBF97AD.8000106@redhat.com> <4FCE2B0B.5060908@redhat.com> <4FCE3225.6090604@redhat.com> Message-ID: <4FCE6437.7060206@redhat.com> On 06/05/2012 12:21 PM, Mike McCune wrote: > odd that it still takes so much time. What is the bulk of the time now > that repository creation is delayed? Agree.. that is great improvement.. but any idea where the remainder of the time is? -- bk From thomasmckay at redhat.com Tue Jun 5 20:08:27 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 05 Jun 2012 16:08:27 -0400 (EDT) Subject: [katello-devel] restructured navigation questions In-Reply-To: Message-ID: Attached screenshot of proposed new menu navigation. 1. There isn't a landing menu item for Subscriptions under Subscriptions, just Activation Keys and Import History. While I understand that clicking the second level navigation, Subscriptions, brings you to the default landing page, shouldn't that default still be in the third level nav? 2. Currently we have Content Providers with sub nav of Red Hat and Custom; is Subscriptions meant to incorporate both? 3. The current flow for Custom Provider is to create the provider, create products, and then finally add repos; what is the suggested new flow? -------------- next part -------------- A non-text attachment was scrubbed... Name: navigation.png Type: image/png Size: 43463 bytes Desc: not available URL: From bkearney at redhat.com Tue Jun 5 20:18:17 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 05 Jun 2012 16:18:17 -0400 Subject: [katello-devel] restructured navigation questions In-Reply-To: References: Message-ID: <4FCE6989.7030306@redhat.com> On 06/05/2012 04:08 PM, Tom McKay wrote: > Attached screenshot of proposed new menu navigation. > > 1. There isn't a landing menu item for Subscriptions under Subscriptions, just Activation Keys and Import History. While I understand that clicking the second level navigation, Subscriptions, brings you to the default landing page, shouldn't that default still be in the third level nav? Wouldnt the cool subscription nav be that. -- bk From jrist at redhat.com Tue Jun 5 21:34:17 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 05 Jun 2012 15:34:17 -0600 Subject: [katello-devel] restructured navigation questions In-Reply-To: <5246beeb-b954-4997-9bed-7c863591c66b@zmail14.collab.prod.int.phx2.redhat.com> References: <5246beeb-b954-4997-9bed-7c863591c66b@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FCE7B59.5060405@redhat.com> On Tue 05 Jun 2012 03:33:11 PM MDT, Kyle Baker wrote: > > > ----- Original Message ----- >> Attached screenshot of proposed new menu navigation. >> >> 1. There isn't a landing menu item for Subscriptions under >> Subscriptions, just Activation Keys and Import History. While I >> understand that clicking the second level navigation, Subscriptions, >> brings you to the default landing page, shouldn't that default still >> be in the third level nav? > > Yeah good catch. We could have the Third level label be 'Subscriptions List'. > >> >> 2. Currently we have Content Providers with sub nav of Red Hat and >> Custom; is Subscriptions meant to incorporate both? > > No, In 1.0 you will find a list of subscriptions under Organizations and under Red Hat Provider. Breaking Subscriptions out is meant to eliminate the ambiguity and redundancy. Under Repositories you now have 'Custom Repos' and 'Red Hat Repos' which is the same content as providers with the exception of 'Red Hat Repos' which should no longer have a list of subs or an import history tab. These now have the label of repos because that is what they contain. We are sill mirroring content we are just doing it in multiple places and are more specific with nav labels. Users now have one place to see all Subs available in that environment which is under 'Subscriptions' in a nice new tu-payne. > >> >> 3. The current flow for Custom Provider is to create the provider, >> create products, and then finally add repos; what is the suggested >> new flow? > > For the current 'Custom Provider' everything is done exactly the same just the label changed and its position in the nav. For 'Red Hat Provider' we have now eliminated the subscriptions from this page and condensed it into one list under subscriptions. The process is still the same here is well except you now import from the subscription page. This is why the nav is reorganized this why to imply the workflow you outlined. > > 1- Import Subs > 2- Enable Repos(Could add gpgs here or filter packages) > 3- Sync down content > 4- Content Search (Browser) - Find Content, Add to Sys template/Changeset > 5- Manage Sys template/Add to change set > 6- Manage Changeset/Promote to next environment > _______________________________________________ > katello mailing list > katello at lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/katello It is my understanding that we are trying not to abbreviate the words "Repositories" down to "Repos" -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From inecas at redhat.com Wed Jun 6 10:17:01 2012 From: inecas at redhat.com (=?UTF-8?B?SXZhbiBOZcSNYXM=?=) Date: Wed, 06 Jun 2012 12:17:01 +0200 Subject: [katello-devel] API Documentation WIKI and branch Message-ID: <4FCF2E1D.5040102@redhat.com> Hello, I've written a short guide describing how the API doc tool works in Katello [1]: there should be all you need for start. There is also an exported version of the current (mostly autogenerated) documentation on wiki [2]. The documentation itself is in separate branch [3] right now. Please pick up your favorite API part and give the documentation some love. Once it's in stable state, we will merge the docs into master and continue to work there. [1] - https://fedorahosted.org/katello/wiki/ApiDocHowto [2] - https://fedorahosted.org/katello/wiki/ApiDocLatest [3] - https://github.com/Katello/katello/tree/restapi -- Ivan From pchalupa at redhat.com Wed Jun 6 10:52:49 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Wed, 06 Jun 2012 12:52:49 +0200 Subject: [katello-devel] Another reason for manifest-import to be asynchronous In-Reply-To: <4FCE6437.7060206@redhat.com> References: <4FBE2D0B.5080201@redhat.com> <4FBF81F3.9060301@redhat.com> <4FBF83C9.3090602@redhat.com> <4FBF8E96.50704@redhat.com> <4FBF97AD.8000106@redhat.com> <4FCE2B0B.5060908@redhat.com> <4FCE3225.6090604@redhat.com> <4FCE6437.7060206@redhat.com> Message-ID: <4FCF3681.3070400@redhat.com> Remaining time is in CDN requests and ruby processing (mainly ActiveRecord callbacks, validations and SSL). I think it can't be improved much further. There is already implemented cache for CDN by Ivan. Petr On 05.06.12 21:55, Bryan Kearney wrote: > On 06/05/2012 12:21 PM, Mike McCune wrote: >> odd that it still takes so much time. What is the bulk of the time now >> that repository creation is delayed? > > Agree.. that is great improvement.. but any idea where the remainder of > the time is? > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From kybaker at redhat.com Wed Jun 6 13:00:58 2012 From: kybaker at redhat.com (Kyle Baker) Date: Wed, 06 Jun 2012 09:00:58 -0400 (EDT) Subject: [katello-devel] Fwd: restructured navigation questions In-Reply-To: <1f7da678-3424-4020-960e-e1d4b015184b@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <27cf3806-4d25-43ae-93d2-46af4fa4e656@zmail14.collab.prod.int.phx2.redhat.com> My responses got bounced, should work this time. ----- Forwarded Message ----- From: "Kyle Baker" To: jrist at redhat.com Cc: "Malini Rao" , katello-devel at redhat.com, katello at lists.fedorahosted.org Sent: Wednesday, June 6, 2012 8:53:12 AM Subject: Re: restructured navigation questions ----- Original Message ----- > On Tue 05 Jun 2012 03:33:11 PM MDT, Kyle Baker wrote: > > > > > > ----- Original Message ----- > >> Attached screenshot of proposed new menu navigation. > >> > >> 1. There isn't a landing menu item for Subscriptions under > >> Subscriptions, just Activation Keys and Import History. While I > >> understand that clicking the second level navigation, > >> Subscriptions, > >> brings you to the default landing page, shouldn't that default > >> still > >> be in the third level nav? > > > > Yeah good catch. We could have the Third level label be > > 'Subscriptions List'. > > > >> > >> 2. Currently we have Content Providers with sub nav of Red Hat and > >> Custom; is Subscriptions meant to incorporate both? > > > > No, In 1.0 you will find a list of subscriptions under > > Organizations and under Red Hat Provider. Breaking Subscriptions > > out is meant to eliminate the ambiguity and redundancy. Under > > Repositories you now have 'Custom Repos' and 'Red Hat Repos' which > > is the same content as providers with the exception of 'Red Hat > > Repos' which should no longer have a list of subs or an import > > history tab. These now have the label of repos because that is > > what they contain. We are sill mirroring content we are just doing > > it in multiple places and are more specific with nav labels. Users > > now have one place to see all Subs available in that environment > > which is under 'Subscriptions' in a nice new tu-payne. > > > >> > >> 3. The current flow for Custom Provider is to create the provider, > >> create products, and then finally add repos; what is the suggested > >> new flow? > > > > For the current 'Custom Provider' everything is done exactly the > > same just the label changed and its position in the nav. For 'Red > > Hat Provider' we have now eliminated the subscriptions from this > > page and condensed it into one list under subscriptions. The > > process is still the same here is well except you now import from > > the subscription page. This is why the nav is reorganized this why > > to imply the workflow you outlined. > > > > 1- Import Subs > > 2- Enable Repos(Could add gpgs here or filter packages) > > 3- Sync down content > > 4- Content Search (Browser) - Find Content, Add to Sys > > template/Changeset > > 5- Manage Sys template/Add to change set > > 6- Manage Changeset/Promote to next environment > > _______________________________________________ > > katello mailing list > > katello at lists.fedorahosted.org > > https://fedorahosted.org/mailman/listinfo/katello > It is my understanding that we are trying not to abbreviate the words > "Repositories" down to "Repos" Yeah, it should say repositories even if just for consistency sake. > > -J > > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > > _______________________________________________ katello mailing list katello at lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/katello From ohadlevy at redhat.com Thu Jun 7 10:44:11 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Thu, 07 Jun 2012 13:44:11 +0300 Subject: [katello-devel] API versioning In-Reply-To: <4FCC7BFF.2000407@redhat.com> References: <4FCC7BFF.2000407@redhat.com> Message-ID: <4FD085FB.5060409@redhat.com> On 06/04/2012 12:12 PM, Ivan Ne?as wrote: > Hello, > > There has been a discussion about API versioning in foreman-dev [1] > recently. Since we are ahead of API changes (both adding features and > refactoring old calls), I would like to open this discussion for Katello > as well. There are two links mentioned talking about using namespaces > for that purpose [2] [3] (Github works this way as well, Twitter goes > the similar way as well). > > So basically there would be 'katello/api/v1/?' for the old version and > 'katello/api/v2/?' for the new one. This would help us with the > migration phase where some users might still rely on the old API for > some time and give them time to migrate to new version of the API. When > the V2 API is stable, the old one would get depreciated and eventually > removed. > > What do you thing about this approach? > > [1] - > https://groups.google.com/group/foreman-dev/browse_thread/thread/dc7a099ab75360f4 > > [2] - http://freelancing-gods.com/posts/versioning_your_ap_is > [3] - http://railscasts.com/episodes/350-rest-api-versioning?autoplay=true > I've implemented a very basic implementation that supports 1. API versioning via an http header e.g. Accept:'Application/json version=1' 2. the ablity to define the default api version, so in any case you dont see a version in the url. 3. added rabl for easy representation / tweaking of api output (not to relay on as_json method etc) https://github.com/ohadlevy/foreman/commit/abcda01b697aca83d40e25387abc052b7e518949 Ohad From ewoud+katello at kohlvanwijngaarden.nl Thu Jun 7 10:51:58 2012 From: ewoud+katello at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Thu, 7 Jun 2012 12:51:58 +0200 Subject: [katello-devel] API versioning In-Reply-To: <4FD085FB.5060409@redhat.com> References: <4FCC7BFF.2000407@redhat.com> <4FD085FB.5060409@redhat.com> Message-ID: <20120607105157.GC28861@bogey.xentower.nl> On Thu, Jun 07, 2012 at 01:44:11PM +0300, Ohad Levy wrote: > I've implemented a very basic implementation that supports > 1. API versioning via an http header e.g. Accept:'Application/json > version=1' The HTTP RFC[1] tells us parameters should be separated by semicolon. I think a better header would be: Accept: application/json; version=1 [1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html From ohadlevy at redhat.com Thu Jun 7 11:03:07 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Thu, 07 Jun 2012 14:03:07 +0300 Subject: [katello-devel] API versioning In-Reply-To: <20120607105157.GC28861@bogey.xentower.nl> References: <4FCC7BFF.2000407@redhat.com> <4FD085FB.5060409@redhat.com> <20120607105157.GC28861@bogey.xentower.nl> Message-ID: <4FD08A6B.8080204@redhat.com> On 06/07/2012 01:51 PM, Ewoud Kohl van Wijngaarden wrote: > The HTTP RFC[1] tells us parameters should be separated by semicolon. > I think a better header would be: > > Accept: application/json; version=1 > > [1]:http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html thanks, my very basic implementation would still catch that, but thats sounds right :) From bkearney at redhat.com Thu Jun 7 12:16:57 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 07 Jun 2012 08:16:57 -0400 Subject: [katello-devel] API versioning In-Reply-To: <4FD08A6B.8080204@redhat.com> References: <4FCC7BFF.2000407@redhat.com> <4FD085FB.5060409@redhat.com> <20120607105157.GC28861@bogey.xentower.nl> <4FD08A6B.8080204@redhat.com> Message-ID: <4FD09BB9.3050405@redhat.com> On 06/07/2012 07:03 AM, Ohad Levy wrote: > On 06/07/2012 01:51 PM, Ewoud Kohl van Wijngaarden wrote: >> The HTTP RFC[1] tells us parameters should be separated by semicolon. >> I think a better header would be: >> >> Accept: application/json; version=1 >> >> [1]:http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html > thanks, my very basic implementation would still catch that, but thats > sounds right :) headers seem to be the best "RESTy" way to handle incremental destructive API changes. I assume a massive change would require the v1/v2 style URL based approach. -- bk From ohadlevy at redhat.com Thu Jun 7 12:28:09 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Thu, 07 Jun 2012 15:28:09 +0300 Subject: [katello-devel] API versioning In-Reply-To: <4FD09BB9.3050405@redhat.com> References: <4FCC7BFF.2000407@redhat.com> <4FD085FB.5060409@redhat.com> <20120607105157.GC28861@bogey.xentower.nl> <4FD08A6B.8080204@redhat.com> <4FD09BB9.3050405@redhat.com> Message-ID: <4FD09E59.3000906@redhat.com> On 06/07/2012 03:16 PM, Bryan Kearney wrote: > > headers seem to be the best "RESTy" way to handle incremental > destructive API changes. I assume a massive change would require the > v1/v2 style URL based approach. but in all cases, they would be part of the header right? one could define a version as part of the header, or get the default one. Ohad From dmitri at redhat.com Thu Jun 7 13:55:46 2012 From: dmitri at redhat.com (Dmitri Dolguikh) Date: Thu, 07 Jun 2012 17:55:46 +0400 Subject: [katello-devel] API versioning In-Reply-To: <4FD085FB.5060409@redhat.com> References: <4FCC7BFF.2000407@redhat.com> <4FD085FB.5060409@redhat.com> Message-ID: <4FD0B2E2.1000704@redhat.com> I've implemented a very basic implementation that supports > 1. API versioning via an http header e.g. Accept:'Application/json > version=1' > 2. the ablity to define the default api version, so in any case you > dont see a version in the url. > 3. added rabl for easy representation / tweaking of api output (not to > relay on as_json method etc) > > https://github.com/ohadlevy/foreman/commit/abcda01b697aca83d40e25387abc052b7e518949 > > > > Ohad +1 to using mime-header (not just any http header). Solves issues with proxies, etc, inherent when using custom headers. Definitely much better than including version in the url. It's probably not too serious of an issue atm - what version of api should be used in the absence of version information in the header? It could be the earliest one, but that's going to suck down the line. Perhaps we could switch to more recent versions of api used by default over time, after some grace period? -d > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From ohadlevy at redhat.com Thu Jun 7 14:00:35 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Thu, 07 Jun 2012 17:00:35 +0300 Subject: [katello-devel] API versioning In-Reply-To: <4FD0B2E2.1000704@redhat.com> References: <4FCC7BFF.2000407@redhat.com> <4FD085FB.5060409@redhat.com> <4FD0B2E2.1000704@redhat.com> Message-ID: <4FD0B403.50805@redhat.com> On 06/07/2012 04:55 PM, Dmitri Dolguikh wrote: Great to see you here, are you back? :) > +1 to using mime-header (not just any http header). Solves issues with > proxies, etc, inherent when using custom headers. Definitely much better > than including version in the url. It's probably not too serious of an > issue atm - what version of api should be used in the absence of version > information in the header? It could be the earliest one, but that's > going to suck down the line. Perhaps we could switch to more recent > versions of api used by default over time, after some grace period? well, I would assume that at some new version at a point of time, we would change the api version, e.g. SE v1, has only API v1 SE v2, has both API v1 and v2, v1 is the default .. Se Vx has api v1 and v2, where v2 is now the default. Ohad From alikins at redhat.com Thu Jun 7 16:23:36 2012 From: alikins at redhat.com (Adrian Likins) Date: Thu, 07 Jun 2012 12:23:36 -0400 Subject: [katello-devel] katello-password potential changes Message-ID: <4FD0D588.2010902@redhat.com> For the enc/obscured db password support for candlepin, I implemented support for using passwords of the style that katello-password generates (as katello is setup to use that style for it's db passwords). In getting the java side to decrypt the passwords that katello-password generates, I found some issues that may need to be changed. I say "may" because I don't think they are wrong or broken, but my research makes me think they are least somewhat non standard. (And if history repeats itself, crypto stuff that feels non standard is usually wrong). So, what katello does is: 1) katello-generate-passphrase generates a passphrase and stashes it in /etc/katello/secure/passphrase. It makes the passphrase via PASS=$( /etc/katello/secure/passphrase Things to note: that makes a 64 byte ascii string to use as the "passphrase" (keep "passphrase" in mind, since this "passphrase" is used to enc the db "password") 2) katello-password reads in that secure passphrase from above takes the passphrase, and get's the hex sha256 digest of it it's key Note: that's a 64 byte string repr of a 32 byte digest of a 64 byte ascii string takes the hex sha256 hex digest of passphrase+passphrase for it's initialization vector Note: that's a 64 byte string repr of a 32 byte digest of a 128 byte ascii string take that 64 byte key, and that 64 byte iv, and passes to the a wrapper around openssl's AES, in particular 256 bit AES with the CBC block cipher mode First thing that get's weird: AES 256 bit only accepts 32 byte keys. The wrapper is silently truncating the key to 32 bytes. I had to do this in the java code to get decryption working. Second thing that get's weird: AES CBC's initialization vector only supports a 16byte iv. The wrapper is also silently truncating this to 16bytes. I also had to do this explicitly in the java code to get it to decrypt properly. Third thing of weird: Research seems to indicate that the iv should be random, and not something predictable. To quote from RFC 3602: "The IV MUST be chosen at random, and MUST be unpredictable." Now that said, we also have to have the IV to decrypt. Which means including it in the format of the stored password. The caveat being: we aren't using this crypto particular "correctly", but then, we are just trying to obscure the passwords a bit, and I'm not even sure with a plaintext as small as a password if the iv really matters much. Thing of weird IV: I think we should be using a different iv for each password stored. Somewhat moot considering we are only storing one db password, but I thought I'd throw that out there. Suggestion: We should probably be using http://en.wikipedia.org/wiki/PBKDF2 for generating the key for AES from a passphrase. That means we need to store the 8byte salt as well, but that shouldn't be an issue. We would store the 8byte salt append/prepend to the enc password, as well as the 16byte random IV and the rest as the passphase. For java, this means the PBKDF2HmacSHA1, and I think the openssl Cipher.pkcs5_keyivgen will do the right thing for this case, but I haven't tested it yet. All of those may well be overkill for this use case. (and my thoughts above could all be wrong, it's crypto, which I'm usually wrong about...) Thoughts? From mmello at redhat.com Fri Jun 8 01:47:59 2012 From: mmello at redhat.com (Marcelo Moreira de Mello) Date: Thu, 07 Jun 2012 22:47:59 -0300 Subject: [katello-devel] [PATCH] 830007 - pt_BR localization does not show the footer message properly on webUI Message-ID: <4FD159CF.6060101@redhat.com> Hello Folks, Attached follow a patch which addressed the issue reported on BZ#830007. Thank you. Best Regards, mmello -- Marcelo Moreira de Mello RHCA RHCSS RHCVA Senior Software Maintenance Engineer/SEG gpg id: 2048R/FDB110E5 gpg fingerprint: 3BE7 EF71 4DD7 6812 D309 8F18 BD42 D095 FDB1 10E5 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-830007-pt_BR-localization-does-not-show-the-footer-m.patch Type: text/x-patch Size: 689 bytes Desc: not available URL: From tstrachota at redhat.com Fri Jun 8 06:46:51 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Fri, 08 Jun 2012 08:46:51 +0200 Subject: [katello-devel] API Documentation WIKI and branch In-Reply-To: <4FCF2E1D.5040102@redhat.com> References: <4FCF2E1D.5040102@redhat.com> Message-ID: <4FD19FDB.7050903@redhat.com> On 06/06/2012 12:17 PM, Ivan Ne?as wrote: > Hello, > > I've written a short guide describing how the API doc tool works in > Katello [1]: there should be all you need for start. There is also an > exported version of the current (mostly autogenerated) documentation on > wiki [2]. The documentation itself is in separate branch [3] right now. > Please pick up your favorite API part and give the documentation some love. > > Once it's in stable state, we will merge the docs into master and > continue to work there. > > [1] - https://fedorahosted.org/katello/wiki/ApiDocHowto > [2] - https://fedorahosted.org/katello/wiki/ApiDocLatest > [3] - https://github.com/Katello/katello/tree/restapi > I created a wikipage to support our documentation efforts [1]. It will help with tracking who is working on what controller. It would be great if everybody took one controller and found some time to document it. There's also a short page with api conventions [2]. It's just a draft with ideas we agreed upon earlier. Feel free to enhance it. We can use these conventions to track found imperfections. There's a table for listing them down in [1]. Tomas [1] - https://fedorahosted.org/katello/wiki/APIDocumentationEfforts [2] - https://fedorahosted.org/katello/wiki/APIConventions From thomasmckay at redhat.com Fri Jun 8 17:49:30 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 08 Jun 2012 13:49:30 -0400 (EDT) Subject: [katello-devel] [PATCH] 830007 - pt_BR localization does not show the footer message properly on webUI In-Reply-To: <4FD159CF.6060101@redhat.com> Message-ID: <82502b57-494d-469f-b7b9-cd28b51b49bc@zmail16.collab.prod.int.phx2.redhat.com> Thanks for the patch! I will send it to the translators for incorporation (they are currently working on some right now). ----- Original Message ----- > From: "Marcelo Moreira de Mello" > To: katello-devel at redhat.com > Sent: Thursday, June 7, 2012 9:47:59 PM > Subject: [katello-devel] [PATCH] 830007 - pt_BR localization does not show the footer message properly on webUI > > Hello Folks, > > Attached follow a patch which addressed the issue reported on > BZ#830007. > > Thank you. > > Best Regards, > mmello > > -- > Marcelo Moreira de Mello > RHCA RHCSS RHCVA > Senior Software Maintenance Engineer/SEG > > gpg id: 2048R/FDB110E5 > gpg fingerprint: 3BE7 EF71 4DD7 6812 D309 8F18 BD42 D095 FDB1 10E5 > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From bkearney at redhat.com Mon Jun 11 13:43:50 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 11 Jun 2012 09:43:50 -0400 Subject: [katello-devel] katello-password potential changes In-Reply-To: <4FD0D588.2010902@redhat.com> References: <4FD0D588.2010902@redhat.com> Message-ID: <4FD5F616.4020600@redhat.com> Any comments on this, or do we let it go as is for now? -- bk On 06/07/2012 12:23 PM, Adrian Likins wrote: > > For the enc/obscured db password support for candlepin, I > implemented support for using passwords of the style > that katello-password generates (as katello is setup > to use that style for it's db passwords). > > In getting the java side to decrypt the passwords > that katello-password generates, I found some issues > that may need to be changed. > > I say "may" because I don't think they are wrong or > broken, but my research makes me think they are > least somewhat non standard. (And if history > repeats itself, crypto stuff that feels non standard > is usually wrong). > > So, what katello does is: > > 1) katello-generate-passphrase generates a passphrase > and stashes it in /etc/katello/secure/passphrase. It > makes the passphrase via > PASS=$( > /etc/katello/secure/passphrase > > Things to note: that makes a 64 byte ascii string to use as the > "passphrase" > > (keep "passphrase" in mind, since this "passphrase" is used to enc the > db "password") > > 2) katello-password > > reads in that secure passphrase from above > > takes the passphrase, and get's the hex sha256 digest of it it's key > Note: that's a 64 byte string repr of a 32 byte digest of a 64 byte > ascii string > > takes the hex sha256 hex digest of passphrase+passphrase for it's > initialization vector > Note: that's a 64 byte string repr of a 32 byte digest of a 128 byte > ascii string > > take that 64 byte key, and that 64 byte iv, and passes to the a wrapper > around > openssl's AES, in particular 256 bit AES with the CBC block cipher mode > > First thing that get's weird: AES 256 bit only accepts 32 byte keys. The > wrapper is > silently truncating the key to 32 bytes. I had to do this in the java > code to get > decryption working. > > Second thing that get's weird: AES CBC's initialization vector only > supports a 16byte iv. > The wrapper is also silently truncating this to 16bytes. I also had to > do this explicitly in > the java code to get it to decrypt properly. > > Third thing of weird: Research seems to indicate that the iv should be > random, and not > something predictable. To quote from RFC 3602: "The IV MUST be chosen at > random, and MUST be > unpredictable." Now that said, we also have to have the IV to decrypt. > Which means including > it in the format of the stored password. > > The caveat being: we aren't using this crypto particular "correctly", > but then, we are just trying > to obscure the passwords a bit, and I'm not even sure with a plaintext > as small as a password > if the iv really matters much. > > Thing of weird IV: I think we should be using a different iv for each > password stored. Somewhat > moot considering we are only storing one db password, but I thought I'd > throw that out there. > > Suggestion: We should probably be using > http://en.wikipedia.org/wiki/PBKDF2 for > generating the key for AES from a passphrase. That means we need to > store the 8byte salt as well, but > that shouldn't be an issue. We would store the 8byte salt append/prepend > to the enc password, as well > as the 16byte random IV and the rest as the passphase. For java, this > means the PBKDF2HmacSHA1, > and I think the openssl Cipher.pkcs5_keyivgen will do the right thing > for this case, but I haven't tested > it yet. > > All of those may well be overkill for this use case. (and my thoughts > above could all be wrong, it's > crypto, which I'm usually wrong about...) > > Thoughts? > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From thomasmckay at redhat.com Mon Jun 11 18:34:10 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 11 Jun 2012 14:34:10 -0400 (EDT) Subject: [katello-devel] restructured navigation questions In-Reply-To: <5246beeb-b954-4997-9bed-7c863591c66b@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <58fba897-cf1a-4dd1-9c59-95547622e62b@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Kyle Baker" > To: "Tom McKay" > Cc: katello-devel at redhat.com, katello at lists.fedorahosted.org, "Malini Rao" > Sent: Tuesday, June 5, 2012 5:33:11 PM > Subject: Re: restructured navigation questions > > > > ----- Original Message ----- > > Attached screenshot of proposed new menu navigation. > > > > 1. There isn't a landing menu item for Subscriptions under > > Subscriptions, just Activation Keys and Import History. While I > > understand that clicking the second level navigation, > > Subscriptions, > > brings you to the default landing page, shouldn't that default > > still > > be in the third level nav? > > Yeah good catch. We could have the Third level label be > 'Subscriptions List'. > > > > > 2. Currently we have Content Providers with sub nav of Red Hat and > > Custom; is Subscriptions meant to incorporate both? > > No, In 1.0 you will find a list of subscriptions under Organizations > and under Red Hat Provider. Breaking Subscriptions out is meant to > eliminate the ambiguity and redundancy. Under Repositories you now > have 'Custom Repos' and 'Red Hat Repos' which is the same content as > providers with the exception of 'Red Hat Repos' which should no > longer have a list of subs or an import history tab. These now have > the label of repos because that is what they contain. We are sill > mirroring content we are just doing it in multiple places and are > more specific with nav labels. Users now have one place to see all > Subs available in that environment which is under 'Subscriptions' in > a nice new tu-payne. This is still not clear to me. Is the current two-pane under "Content Providers > Custom Content Providers" now going to be under "Repositories > Custom Repositories"? > > > > > 3. The current flow for Custom Provider is to create the provider, > > create products, and then finally add repos; what is the suggested > > new flow? > > For the current 'Custom Provider' everything is done exactly the same > just the label changed and its position in the nav. For 'Red Hat > Provider' we have now eliminated the subscriptions from this page > and condensed it into one list under subscriptions. The process is > still the same here is well except you now import from the > subscription page. This is why the nav is reorganized this why to > imply the workflow you outlined. > > 1- Import Subs > 2- Enable Repos(Could add gpgs here or filter packages) > 3- Sync down content > 4- Content Search (Browser) - Find Content, Add to Sys > template/Changeset > 5- Manage Sys template/Add to change set > 6- Manage Changeset/Promote to next environment > From mmccune at redhat.com Mon Jun 11 23:18:19 2012 From: mmccune at redhat.com (Mike McCune) Date: Mon, 11 Jun 2012 16:18:19 -0700 Subject: [katello-devel] katello-password potential changes In-Reply-To: <4FD5F616.4020600@redhat.com> References: <4FD0D588.2010902@redhat.com> <4FD5F616.4020600@redhat.com> Message-ID: <4FD67CBB.80405@redhat.com> my first reaction is that it feels like a bit of overkill to go to the next step and implement PBKDF2 beyond what we have now. Perhaps a review from the security team would be in order? Mike On 06/11/2012 06:43 AM, Bryan Kearney wrote: > Any comments on this, or do we let it go as is for now? > -- bk > > On 06/07/2012 12:23 PM, Adrian Likins wrote: >> >> For the enc/obscured db password support for candlepin, I >> implemented support for using passwords of the style >> that katello-password generates (as katello is setup >> to use that style for it's db passwords). >> >> In getting the java side to decrypt the passwords >> that katello-password generates, I found some issues >> that may need to be changed. >> >> I say "may" because I don't think they are wrong or >> broken, but my research makes me think they are >> least somewhat non standard. (And if history >> repeats itself, crypto stuff that feels non standard >> is usually wrong). >> >> So, what katello does is: >> >> 1) katello-generate-passphrase generates a passphrase >> and stashes it in /etc/katello/secure/passphrase. It >> makes the passphrase via >> PASS=$( >> /etc/katello/secure/passphrase >> >> Things to note: that makes a 64 byte ascii string to use as the >> "passphrase" >> >> (keep "passphrase" in mind, since this "passphrase" is used to enc the >> db "password") >> >> 2) katello-password >> >> reads in that secure passphrase from above >> >> takes the passphrase, and get's the hex sha256 digest of it it's key >> Note: that's a 64 byte string repr of a 32 byte digest of a 64 byte >> ascii string >> >> takes the hex sha256 hex digest of passphrase+passphrase for it's >> initialization vector >> Note: that's a 64 byte string repr of a 32 byte digest of a 128 byte >> ascii string >> >> take that 64 byte key, and that 64 byte iv, and passes to the a wrapper >> around >> openssl's AES, in particular 256 bit AES with the CBC block cipher mode >> >> First thing that get's weird: AES 256 bit only accepts 32 byte keys. The >> wrapper is >> silently truncating the key to 32 bytes. I had to do this in the java >> code to get >> decryption working. >> >> Second thing that get's weird: AES CBC's initialization vector only >> supports a 16byte iv. >> The wrapper is also silently truncating this to 16bytes. I also had to >> do this explicitly in >> the java code to get it to decrypt properly. >> >> Third thing of weird: Research seems to indicate that the iv should be >> random, and not >> something predictable. To quote from RFC 3602: "The IV MUST be chosen at >> random, and MUST be >> unpredictable." Now that said, we also have to have the IV to decrypt. >> Which means including >> it in the format of the stored password. >> >> The caveat being: we aren't using this crypto particular "correctly", >> but then, we are just trying >> to obscure the passwords a bit, and I'm not even sure with a plaintext >> as small as a password >> if the iv really matters much. >> >> Thing of weird IV: I think we should be using a different iv for each >> password stored. Somewhat >> moot considering we are only storing one db password, but I thought I'd >> throw that out there. >> >> Suggestion: We should probably be using >> http://en.wikipedia.org/wiki/PBKDF2 for >> generating the key for AES from a passphrase. That means we need to >> store the 8byte salt as well, but >> that shouldn't be an issue. We would store the 8byte salt append/prepend >> to the enc password, as well >> as the 16byte random IV and the rest as the passphase. For java, this >> means the PBKDF2HmacSHA1, >> and I think the openssl Cipher.pkcs5_keyivgen will do the right thing >> for this case, but I haven't tested >> it yet. >> >> All of those may well be overkill for this use case. (and my thoughts >> above could all be wrong, it's >> crypto, which I'm usually wrong about...) >> >> Thoughts? >> >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Mike McCune mmccune AT redhat.com Red Hat Engineering | Portland, OR Systems Management | 650.254.4248 From lzap at redhat.com Tue Jun 12 07:00:46 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Tue, 12 Jun 2012 09:00:46 +0200 Subject: [katello-devel] katello-password potential changes In-Reply-To: <4FD0D588.2010902@redhat.com> References: <4FD0D588.2010902@redhat.com> Message-ID: <20120612070046.GD2682@lzapx.brq.redhat.com> Was on PTO, On Thu, Jun 07, 2012 at 12:23:36PM -0400, Adrian Likins wrote: > First thing that get's weird: AES 256 bit only accepts 32 byte > keys. The wrapper is > silently truncating the key to 32 bytes. I had to do this in the > java code to get > decryption working. Ah I swapped 32 bit and 32 byte terms when I was writing this. > Second thing that get's weird: AES CBC's initialization vector > only supports a 16byte iv. > The wrapper is also silently truncating this to 16bytes. I also > had to do this explicitly in > the java code to get it to decrypt properly. > > Third thing of weird: Research seems to indicate that the iv > should be random, and not > something predictable. To quote from RFC 3602: "The IV MUST be > chosen at random, and MUST be > unpredictable." Now that said, we also have to have the IV to > decrypt. Which means including > it in the format of the stored password. > > The caveat being: we aren't using this crypto particular > "correctly", but then, we are just trying > to obscure the passwords a bit, and I'm not even sure with a > plaintext as small as a password > if the iv really matters much. > > Thing of weird IV: I think we should be using a different iv > for each password stored. Somewhat > moot considering we are only storing one db password, but I > thought I'd throw that out there. Yeah my very first idea was - obscure password somehow. I have chosen AES from OpenSSL because we already have this dependency and it is much better than XORing or something like that. > Suggestion: We should probably be using > http://en.wikipedia.org/wiki/PBKDF2 for > generating the key for AES from a passphrase. That means we need to > store the 8byte salt as well, but > that shouldn't be an issue. We would store the 8byte salt > append/prepend to the enc password, as well > as the 16byte random IV and the rest as the passphase. For java, > this means the PBKDF2HmacSHA1, > and I think the openssl Cipher.pkcs5_keyivgen will do the right > thing for this case, but I haven't tested > it yet. > The code is not in the CloudForms v1 so we can change it. This was my idea - to wait until you guys implement this in Java and then we will tune it. I was not sure which OpenSSL Java implementation you use, if you will even have AES implementation available etc. Can you make the suggested changes in the Java version and push it (in a branch or something) so I can copy it to our Ruby version? LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From pchalupa at redhat.com Tue Jun 12 08:16:40 2012 From: pchalupa at redhat.com (Petr Chalupa) Date: Tue, 12 Jun 2012 10:16:40 +0200 Subject: [katello-devel] Another reason for manifest-import to be asynchronous In-Reply-To: <4FCE2B0B.5060908@redhat.com> References: <4FBE2D0B.5080201@redhat.com> <4FBF81F3.9060301@redhat.com> <4FBF83C9.3090602@redhat.com> <4FBF8E96.50704@redhat.com> <4FBF97AD.8000106@redhat.com> <4FCE2B0B.5060908@redhat.com> Message-ID: <4FD6FAE8.9010107@redhat.com> So, I make the manifest asynchronous and I will not include the changes for delayed pulp repository creation. Petr On 05.06.12 17:51, Petr Chalupa wrote: > I've implemented the delayed repository creation for manifest import. > > stageSamTest20Nov2011.zip > 943.4s 15.7min with repository creation > 419.5s 6.9min with delayed repository creation > > stageSamTestSimple20Nov2011.zip > 208.0s 3.4min with repository creation > 116.4s 1.9min with delayed repository creation > > It's faster but I think it's still too slow for synchronous action. > +1 to make it asynchronous. > > If manifest import is asynchronous I will suggest not to merge these > changes, because: > - It makes code more complicated and fragile, until now repositories > always had its repository in pulp. I still have some bugs in cli-tests > to hunt. > - I think, it will not deliver much value for users if import is > asynchronous. > > What do you think? > > Petr > > On 25.05.12 16:31, Mike McCune wrote: >> On 05/25/2012 06:52 AM, Brad Buckingham wrote: >>> On 05/25/2012 09:06 AM, Ivan Ne?as wrote: >>>> On 05/25/2012 02:58 PM, Bryan Kearney wrote: >>>>> On 05/24/2012 08:43 AM, Ivan Ne?as wrote: >>>>>> Hi, >>>>>> >>>>>> I've been working on z stream bug >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=823890, the solution >>>>>> (https://github.com/Katello/katello/pull/144) is to remote the >>>>>> products >>>>>> (including repositories) that were removed from the newly-imported >>>>>> manifest. This slows down of the manifest import - time is needed for >>>>>> removing the repositories which is not big problem for unsynchronized >>>>>> repos, but there might be significant change for repositories already >>>>>> synchronized. >>>>>> >>>>>> I would like to get more ideas on this. Is this the right time to >>>>>> move >>>>>> manifest import to asynchronous state. >>>>>> >>>>>> Also removing repositories (not only in this case) causes records >>>>>> about >>>>>> their promotions in changeset to vanish. We probably need other >>>>>> (softer) >>>>>> mechanism for removing repositories that still leaves some marks that >>>>>> the repository was there once. >>>>>> >>>>> The user can really not do much else while the import is going on. >>>>> But.. i would be happy to add this to the backlog if the team wants >>>>> to. >>>> Yeah, but it's always a bit risky to let longer running tasks being >>>> synchronous: in case of connection time-out the user is not properly >>>> reported about the finish of the request. >>>> >>>> -- Ivan >>> I am +1 for making it async, given that it is a really long running >>> task. If we do that, we'll need to make sure the UI is updated so that >>> users are able to determine that an import is in progress, if they >>> navigate away from and back to the import page. >>> >>> That said, I thought there was some mention in the process of import >>> changing in the future which would make it much faster. (e.g. Not >>> importing repos that aren't going to be enabled). >> >> yes, if we go this route and skip the pulp repo creation during import >> the actual transaction time is quite fast. On a manifest I edited to >> only contain one repo the manifest imports in 2-3 seconds. >> >> If we remove the pulp repo creation, the need to make this task async is >> much lessened but may still be helpful in the case that Lukas mentions >> above where we need to go and delete repositories that are no longer in >> the manifest. >> >> The priority of work should be: >> >> 1) take out pulp repo creation during manifest import >> >> 2) then decide if we should make it async >> >> Mike >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From thomasmckay at redhat.com Tue Jun 12 19:19:28 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Tue, 12 Jun 2012 15:19:28 -0400 (EDT) Subject: [katello-devel] manifest import history location In-Reply-To: <00d2a613-174e-4724-8ab9-ca8361347819@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: Here's another stab at trying to relocate the manifest import history location in the new navigation re-org. Note in the attached navigation.png that under the Content > Subscriptions nav there is an Import History entry. This will lead to a page that has the content listed in current-subs.png. I am suggesting that, 1) This is a very low value page to have as a link in the tool's primary navigation area, and 2) Putting it closer to where manifests are actually imported would have some value. In the import-subs.png you'll see the location for importing a new manifest in the two-pane subscriptions view I'm working on completing this iteration. In Screenshot-3.png you see the History page next to the Import page. I'm arguing that, 1) Having both an Import and History tab does not conflict with the common paradigm in our UI, 2) That having the history close to where importing is actually done increases its value, and 3) The import history itself does not have high enough value to be in the top level navigation structure. Thoughts strongly for or against? -------------- next part -------------- A non-text attachment was scrubbed... Name: current-subs.png Type: image/png Size: 11038 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: navigation.png Type: image/png Size: 43463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: import-subs.png Type: image/png Size: 56798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-3.png Type: image/png Size: 47747 bytes Desc: not available URL: From jrist at redhat.com Tue Jun 12 21:11:38 2012 From: jrist at redhat.com (Jason Rist) Date: Tue, 12 Jun 2012 15:11:38 -0600 Subject: [katello-devel] manifest import history location In-Reply-To: References: <00d2a613-174e-4724-8ab9-ca8361347819@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4FD7B08A.9020101@redhat.com> On Tue 12 Jun 2012 01:19:28 PM MDT, Tom McKay wrote: > Here's another stab at trying to relocate the manifest import history location in the new navigation re-org. > > Note in the attached navigation.png that under the Content> Subscriptions nav there is an Import History entry. This will lead to a page that has the content listed in current-subs.png. > > I am suggesting that, 1) This is a very low value page to have as a link in the tool's primary navigation area, and 2) Putting it closer to where manifests are actually imported would have some value. > > In the import-subs.png you'll see the location for importing a new manifest in the two-pane subscriptions view I'm working on completing this iteration. In Screenshot-3.png you see the History page next to the Import page. > > I'm arguing that, 1) Having both an Import and History tab does not conflict with the common paradigm in our UI, 2) That having the history close to where importing is actually done increases its value, and 3) The import history itself does not have high enough value to be in the top level navigation structure. > > Thoughts strongly for or against? > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I like this better,b ut that said, it doesn't make a lot of sense to have it in the Import/New button. Would it be possible to have it attached to the actual subscriptions? I.E. click the left side row and see it as a tab in the pane? -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bbuckingham at redhat.com Tue Jun 12 22:03:55 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Tue, 12 Jun 2012 18:03:55 -0400 Subject: [katello-devel] System Groups - pull request 199 - will require db:migrate after merge Message-ID: <4FD7BCCB.5050807@redhat.com> Team, I just submitted a pull request to github master that will require a 'rake db:migrate' by developers after it is merged in. The pull request is: https://github.com/Katello/katello/pull/199 This request is primarily to enhance the UI for System Groups to enable users to see the history of completed and in progress actions performed on a system group. As part of this feature, I am removing the current system_tasks model (system_task.rb) which was a simple join table between systems and task_statuses. It is being replaced by a polymorphic association on the task_status model which defines a task_owner. This association allows us to more easily have other 'owners' or users of the task_status, without requiring another join table (similar to system_tasks). In addition, it makes the flow from system_group -> jobs -> task_statuses a bit cleaner. The migration mentioned above will basically perform the following: - for each record in system_tasks, locate the corresponding task_statuses record - for that record, set the task_owner_type (e.g. System) and task_owner_id (e.g. 1, 2, 3...) - once finished, drop the system_tasks table thanks, Brad From thomasmckay at redhat.com Wed Jun 13 14:56:01 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 13 Jun 2012 10:56:01 -0400 (EDT) Subject: [katello-devel] "deep links" into UI don't include organization In-Reply-To: <65d0a916-2dd4-4ca1-8f95-7ce73b080f86@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <53b486f4-46b9-48fb-bf54-9c44f1c288b1@zmail16.collab.prod.int.phx2.redhat.com> Is there a reason why org is not part of katello's URLs? /katello/subscriptions does not have enough info to actually share with another user. From kybaker at redhat.com Wed Jun 13 15:10:02 2012 From: kybaker at redhat.com (Kyle Baker) Date: Wed, 13 Jun 2012 11:10:02 -0400 (EDT) Subject: [katello-devel] Additional Content Search(Browser) Questions In-Reply-To: Message-ID: As we are working though the Content Search(Browser) feature additional questions have come up. In the search results pane on the right a user selects a set of environments from the 'Add Environments' drop-down which will populate the columns with the selected content. After users get the result set should the environment selection span multiple sessions? In a single session, when a user leaves the Content Search screen should their result set remain the same when they return or should the results set update to reflect its current state? Kyle Baker Visual Designer Desk (978) 392 3116 UX Team IRC kylebaker From ehelms at redhat.com Wed Jun 13 15:12:06 2012 From: ehelms at redhat.com (Eric Helms) Date: Wed, 13 Jun 2012 11:12:06 -0400 (EDT) Subject: [katello-devel] "deep links" into UI don't include organization In-Reply-To: <53b486f4-46b9-48fb-bf54-9c44f1c288b1@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <555ff42e-0289-46db-bc60-80c1de91b150@zmail16.collab.prod.int.phx2.redhat.com> There are some known issues around this, as well as an item from our technical debt retrospective to tackle consistency around URLs with regards to organization scoping and RESTful-ness. ----- Original Message ----- From: "Tom McKay" To: katello-devel at redhat.com Sent: Wednesday, June 13, 2012 10:56:01 AM Subject: [katello-devel] "deep links" into UI don't include organization Is there a reason why org is not part of katello's URLs? /katello/subscriptions does not have enough info to actually share with another user. _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From jrist at redhat.com Wed Jun 13 17:49:38 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 13 Jun 2012 11:49:38 -0600 Subject: [katello-devel] Github Pull Request Test Process Message-ID: <4FD8D2B2.9050304@redhat.com> Hey All - Here's the wiki page I've been meaning to put together for reviewing pull requests: https://fedorahosted.org/katello/wiki/GitHubPullRequestProcess Cheers, J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From alikins at redhat.com Wed Jun 13 18:47:46 2012 From: alikins at redhat.com (Adrian Likins) Date: Wed, 13 Jun 2012 14:47:46 -0400 Subject: [katello-devel] Github Pull Request Test Process In-Reply-To: <4FD8D2B2.9050304@redhat.com> References: <4FD8D2B2.9050304@redhat.com> Message-ID: <4FD8E052.4060709@redhat.com> On 06/13/2012 01:49 PM, Jason Rist wrote: > Hey All - Here's the wiki page I've been meaning to put together for > reviewing pull requests: > https://fedorahosted.org/katello/wiki/GitHubPullRequestProcess > > Cheers, > J I would probably add a note about using 'hub' from https://github.com/defunkt/hub Maybe something like: Hub "hub is a command line tool that wraps git in order to extend it with extra features and commands that make working with GitHub easier." With 'hub', to checkout out a branch for a pull request is: hub checkout https://github.com/candlepin/subscription-manager/pull/71 The suggested config wraps git, so it could actually be: git checkout https://github.com/candlepin/subscription-manager/pull/71 It will add the right remote if needed, fetch, and checkout the branch with a name like "candlepin-alikins/830949". It also has some support for creating a pull request from a branch, and merging pull request from the cli. git merge https://github.com/defunkt/hub/pull/73 It requires a newer version of git than is available in RHEL6, but there is a branch at https://github.com/alikins/hub to better work with RHEL6. Adrian From jrist at redhat.com Wed Jun 13 20:10:17 2012 From: jrist at redhat.com (Jason Rist) Date: Wed, 13 Jun 2012 14:10:17 -0600 Subject: [katello-devel] Github Pull Request Test Process In-Reply-To: <4FD8E052.4060709@redhat.com> References: <4FD8D2B2.9050304@redhat.com> <4FD8E052.4060709@redhat.com> Message-ID: <4FD8F3A9.5040408@redhat.com> On Wed 13 Jun 2012 12:47:46 PM MDT, Adrian Likins wrote: > On 06/13/2012 01:49 PM, Jason Rist wrote: >> Hey All - Here's the wiki page I've been meaning to put together for >> reviewing pull requests: >> https://fedorahosted.org/katello/wiki/GitHubPullRequestProcess >> >> Cheers, >> J > > I would probably add a note about using 'hub' from > https://github.com/defunkt/hub > > Maybe something like: > > > Hub > > "hub is a command line tool that wraps git in order to extend it with > extra > features and commands that make working with GitHub easier." > > With 'hub', to checkout out a branch for a pull request is: > > hub checkout https://github.com/candlepin/subscription-manager/pull/71 > > The suggested config wraps git, so it could actually be: > > git checkout https://github.com/candlepin/subscription-manager/pull/71 > > It will add the right remote if needed, fetch, and checkout the branch > with a name like "candlepin-alikins/830949". > > It also has some support for creating a pull request from a branch, and > merging pull request from the cli. > > git merge https://github.com/defunkt/hub/pull/73 > > It requires a newer version of git than is available in RHEL6, but there > is a branch at https://github.com/alikins/hub to better work with RHEL6. > > Adrian Yeah, you had mentioned that in a previous chat - totally open to using this, but I wanted to get the basics down. I'll add this to the wiki. Thanks! -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jbowes at redhat.com Thu Jun 14 11:53:50 2012 From: jbowes at redhat.com (James Bowes) Date: Thu, 14 Jun 2012 08:53:50 -0300 Subject: [katello-devel] Github Pull Request Test Process In-Reply-To: <4FD8F3A9.5040408@redhat.com> References: <4FD8D2B2.9050304@redhat.com> <4FD8E052.4060709@redhat.com> <4FD8F3A9.5040408@redhat.com> Message-ID: <20120614115350.GA37275@pipboy.redhat.com> On Wed, Jun 13, 2012 at 02:10:17PM -0600, Jason Rist wrote: > On Wed 13 Jun 2012 12:47:46 PM MDT, Adrian Likins wrote: > >On 06/13/2012 01:49 PM, Jason Rist wrote: > >>Hey All - Here's the wiki page I've been meaning to put together > >>for reviewing pull requests: > >>https://fedorahosted.org/katello/wiki/GitHubPullRequestProcess > >> > >>Cheers, > >>J > > > >I would probably add a note about using 'hub' from > >https://github.com/defunkt/hub > > > >Maybe something like: > > > > > >Hub > > > >"hub is a command line tool that wraps git in order to extend it > >with extra > >features and commands that make working with GitHub easier." > > > >With 'hub', to checkout out a branch for a pull request is: > > > >hub checkout https://github.com/candlepin/subscription-manager/pull/71 > > > >The suggested config wraps git, so it could actually be: > > > >git checkout https://github.com/candlepin/subscription-manager/pull/71 > > > >It will add the right remote if needed, fetch, and checkout the branch > >with a name like "candlepin-alikins/830949". > > > >It also has some support for creating a pull request from a branch, and > >merging pull request from the cli. > > > >git merge https://github.com/defunkt/hub/pull/73 > > > >It requires a newer version of git than is available in RHEL6, but there > >is a branch at https://github.com/alikins/hub to better work with RHEL6. > > > >Adrian > > Yeah, you had mentioned that in a previous chat - totally open to > using this, but I wanted to get the basics down. I'll add this to > the wiki. Thanks! > We've been pushing our branches into the main candlepin repo for review. Typically you'd see a branch like "jbowes/unbreak-manifests-oops" in candlepin/candlepin.git. That way, nobody has to worry too much about managing all their remotes. Once the pull-request is closed, the branch creator can delete it. > -J > > -- > Jason E. Rist > Senior Software Engineer > Systems Management and Cloud Enablement > Red Hat, Inc. > +1.919.754.4048 > Freenode: jrist > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -James -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kybaker at redhat.com Thu Jun 14 12:58:51 2012 From: kybaker at redhat.com (Kyle Baker) Date: Thu, 14 Jun 2012 08:58:51 -0400 (EDT) Subject: [katello-devel] Additional Content Search(Browser) Questions In-Reply-To: <521646fb-750c-4006-b8e5-1a062adc3ac9@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <377bf8c9-412f-44e8-8b1b-859d40b4fc89@zmail14.collab.prod.int.phx2.redhat.com> Sent again as my first message got bounced - As we are working though the Content Search(Browser) feature additional questions have come up. In the search results pane on the right a user selects a set of environments from the 'Add Environments' drop-down which will populate the columns with the selected content. After users get the result set should the environment selection span multiple sessions? In a single session, when a user leaves the Content Search screen should their result set remain the same when they return or should the results set update to reflect its current state? Kyle Baker Visual Designer Desk (978) 392 3116 UX Team IRC kylebaker From mmccune at redhat.com Thu Jun 14 22:35:40 2012 From: mmccune at redhat.com (Mike McCune) Date: Thu, 14 Jun 2012 15:35:40 -0700 Subject: [katello-devel] Additional Content Search(Browser) Questions In-Reply-To: <377bf8c9-412f-44e8-8b1b-859d40b4fc89@zmail14.collab.prod.int.phx2.redhat.com> References: <377bf8c9-412f-44e8-8b1b-859d40b4fc89@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FDA673C.8010704@redhat.com> On 06/14/2012 05:58 AM, Kyle Baker wrote: > Sent again as my first message got bounced - > > As we are working though the Content Search(Browser) feature additional questions have come up. > > In the search results pane on the right a user selects a set of environments from the 'Add Environments' drop-down which will populate the columns with the selected content. After users get the result set should the environment selection span multiple sessions? not required, no. > > In a single session, when a user leaves the Content Search screen should their result set remain the same when they return or should the results set update to reflect its current state? > no, just start back from the start. We don't have any 'session state' that we store anywhere in the UI other than what Org you have selected and what user you are logged in as. We don't need to maintain search settings as you leave and come back to the page. Mike From dhaval.joshi at nomura.com Fri Jun 15 08:02:45 2012 From: dhaval.joshi at nomura.com (dhaval.joshi at nomura.com) Date: Fri, 15 Jun 2012 08:02:45 +0000 Subject: [katello-devel] help failing to register RHEL 5.6 client to RHEL 6.2 repo In-Reply-To: <9B06D796FBAECD46B1E4817A66F7A55D3232BCA1@MUMWS14103.ASIAPAC.NOM> References: <9B06D796FBAECD46B1E4817A66F7A55D3232BCA1@MUMWS14103.ASIAPAC.NOM> Message-ID: <9B06D796FBAECD46B1E4817A66F7A55D3232C4FD@MUMWS14103.ASIAPAC.NOM> Hi, I am trying to register RHEL 5.6 client to RHEL 6.2 repository When I tried to register it says 2d8fc396-6d4b-4483-a832-130bd1ddf573 Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory 2) I tried to add new provider and added URL for repository sync for RHEL 5, when I go to sync management and try to sync it says Error syncing, how do I check logs what happen, do I need to perform additional steps to sync it ? Regards, Dhaval This e-mail (including any attachments) is confidential, may contain proprietary or privileged information and is intended for the named recipient(s) only. Unintended recipients are prohibited from taking action on the basis of information in this e-mail and must delete all copies. Nomura will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in, this e-mail. If verification is sought please request a hard copy. Any reference to the terms of executed transactions should be treated as preliminary only and subject to formal written confirmation by Nomura. Nomura reserves the right to monitor e-mail communications through its networks (in accordance with applicable laws). No confidentiality or privilege is waived or lost by Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is a reference to any entity in the Nomura Holdings, Inc. group. Please read our Electronic Communications Legal Notice which forms part of this e-mail: http://www.Nomura.com/email_disclaimer.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: From lzap at redhat.com Fri Jun 15 08:20:00 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 15 Jun 2012 10:20:00 +0200 Subject: [katello-devel] help failing to register RHEL 5.6 client to RHEL 6.2 repo In-Reply-To: <9B06D796FBAECD46B1E4817A66F7A55D3232C4FD@MUMWS14103.ASIAPAC.NOM> References: <9B06D796FBAECD46B1E4817A66F7A55D3232BCA1@MUMWS14103.ASIAPAC.NOM> <9B06D796FBAECD46B1E4817A66F7A55D3232C4FD@MUMWS14103.ASIAPAC.NOM> Message-ID: <20120615082000.GA6182@lzapx.brq.redhat.com> Hello, > When I tried to register it says > > 2d8fc396-6d4b-4483-a832-130bd1ddf573 > Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory > And is the client registered then? I think subscription-manager has a minor issue showing this error message (but it actually works). What are your versions? rpm -q subscription-manager katello > 2) > > I tried to add new provider and added URL for repository sync for RHEL 5, when I go to sync management and try to sync it says Error syncing, how do I check logs what happen, do I need to perform additional steps to sync it ? > > Check out /var/log/katello and in case of syncing /var/log/pulp (pulp.log and grinder.log). You can also use katello-debug script and send us the report tarball to a bugzilla (private comment). All sensitive data is removed from it. -- Later, Lukas "lzap" Zapletal #katello #systemengine From gkhachik at redhat.com Fri Jun 15 08:37:49 2012 From: gkhachik at redhat.com (Garik Khachikyan) Date: Fri, 15 Jun 2012 10:37:49 +0200 Subject: [katello-devel] help failing to register RHEL 5.6 client to RHEL 6.2 repo In-Reply-To: <20120615082000.GA6182@lzapx.brq.redhat.com> References: <9B06D796FBAECD46B1E4817A66F7A55D3232BCA1@MUMWS14103.ASIAPAC.NOM> <9B06D796FBAECD46B1E4817A66F7A55D3232C4FD@MUMWS14103.ASIAPAC.NOM> <20120615082000.GA6182@lzapx.brq.redhat.com> Message-ID: <4FDAF45D.3090001@redhat.com> also could you please try to fetch once: `subscription-manager identity` thanks. On 15/06/12 10:20, Lukas Zapletal wrote: > Hello, > >> When I tried to register it says >> >> 2d8fc396-6d4b-4483-a832-130bd1ddf573 >> Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory >> > And is the client registered then? I think subscription-manager has a > minor issue showing this error message (but it actually works). > > What are your versions? > > rpm -q subscription-manager katello > >> 2) >> >> I tried to add new provider and added URL for repository sync for RHEL 5, when I go to sync management and try to sync it says Error syncing, how do I check logs what happen, do I need to perform additional steps to sync it ? >> >> > Check out /var/log/katello and in case of syncing /var/log/pulp > (pulp.log and grinder.log). > > You can also use katello-debug script and send us the report tarball to > a bugzilla (private comment). All sensitive data is removed from it. > > From ehelms at redhat.com Fri Jun 15 12:03:26 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 15 Jun 2012 08:03:26 -0400 (EDT) Subject: [katello-devel] Additional Content Search(Browser) Questions In-Reply-To: <4FDA673C.8010704@redhat.com> Message-ID: We do have the concept of storing some "state" in the URLs such that a user can generate bookmarks and use their browsers back button to return to a given state. This is most noticeable on a tupane page where a user can perform a search and/or select a particular item from the list. If the user then refreshes, or copy/pastes the link or uses the back button they can recreate the state of that search and item being open. So doing at least that much for Content Search (saving the current environments and current search criteria in the URL) is not a stretch. ----- Original Message ----- From: "Mike McCune" To: katello-devel at redhat.com Sent: Thursday, June 14, 2012 6:35:40 PM Subject: Re: [katello-devel] Additional Content Search(Browser) Questions On 06/14/2012 05:58 AM, Kyle Baker wrote: > Sent again as my first message got bounced - > > As we are working though the Content Search(Browser) feature additional questions have come up. > > In the search results pane on the right a user selects a set of environments from the 'Add Environments' drop-down which will populate the columns with the selected content. After users get the result set should the environment selection span multiple sessions? not required, no. > > In a single session, when a user leaves the Content Search screen should their result set remain the same when they return or should the results set update to reflect its current state? > no, just start back from the start. We don't have any 'session state' that we store anywhere in the UI other than what Org you have selected and what user you are logged in as. We don't need to maintain search settings as you leave and come back to the page. Mike _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From bbuckingham at redhat.com Fri Jun 15 15:10:13 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Fri, 15 Jun 2012 11:10:13 -0400 Subject: [katello-devel] System Groups - pull request 199 - will require db:migrate after merge In-Reply-To: <4FD7BCCB.5050807@redhat.com> References: <4FD7BCCB.5050807@redhat.com> Message-ID: <4FDB5055.1080301@redhat.com> On 06/12/2012 06:03 PM, Brad Buckingham wrote: > Team, > > I just submitted a pull request to github master that will require a > 'rake db:migrate' by developers after it is merged in. > > The pull request is: https://github.com/Katello/katello/pull/199 > > This request is primarily to enhance the UI for System Groups to > enable users to see the history of completed and in progress actions > performed on a system group. As part of this feature, I am removing > the current system_tasks model (system_task.rb) which was a simple > join table between systems and task_statuses. It is being replaced by > a polymorphic association on the task_status model which defines a > task_owner. This association allows us to more easily have other > 'owners' or users of the task_status, without requiring another join > table (similar to system_tasks). In addition, it makes the flow from > system_group -> jobs -> task_statuses a bit cleaner. > > The migration mentioned above will basically perform the following: > - for each record in system_tasks, locate the corresponding > task_statuses record > - for that record, set the task_owner_type (e.g. System) and > task_owner_id (e.g. 1, 2, 3...) > - once finished, drop the system_tasks table > > thanks, > Brad > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Developers, The above pull request was just merged in to master. Reminder that you'll need to 'rake db:migrate' to get the updates related to the system_task and task_status models. thanks, Brad From thomasmckay at redhat.com Mon Jun 18 20:12:16 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Mon, 18 Jun 2012 16:12:16 -0400 (EDT) Subject: [katello-devel] manifest import history location In-Reply-To: Message-ID: UX compromise is to put an abbreviated history below the "Upload" button with a link to the full import history page. The history will remain as a 2nd level nav under Subscriptions. ----- Original Message ----- > From: "Tom McKay" > To: katello-devel at redhat.com > Sent: Tuesday, June 12, 2012 3:19:28 PM > Subject: manifest import history location > > Here's another stab at trying to relocate the manifest import history > location in the new navigation re-org. > > Note in the attached navigation.png that under the Content > > Subscriptions nav there is an Import History entry. This will lead > to a page that has the content listed in current-subs.png. > > I am suggesting that, 1) This is a very low value page to have as a > link in the tool's primary navigation area, and 2) Putting it closer > to where manifests are actually imported would have some value. > > In the import-subs.png you'll see the location for importing a new > manifest in the two-pane subscriptions view I'm working on > completing this iteration. In Screenshot-3.png you see the History > page next to the Import page. > > I'm arguing that, 1) Having both an Import and History tab does not > conflict with the common paradigm in our UI, 2) That having the > history close to where importing is actually done increases its > value, and 3) The import history itself does not have high enough > value to be in the top level navigation structure. > > Thoughts strongly for or against? > From kybaker at redhat.com Tue Jun 19 20:00:43 2012 From: kybaker at redhat.com (Kyle Baker) Date: Tue, 19 Jun 2012 16:00:43 -0400 (EDT) Subject: [katello-devel] 'Add Environments' widget update In-Reply-To: <475f583c-39eb-47e8-876c-d3f30b2fa401@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <40aade6d-ec58-42a3-95f0-ba06f447ee34@zmail14.collab.prod.int.phx2.redhat.com> I updated the content search design to optimize the space for additional environment columns. Here are a list of updates to the mock-ups - ? Minimized the 'Add Environments' text to the plus icon. ? The plus icon now sticks to the right and when there is overflow the arrow appears on the left. ? When there is overflow you should see both left and right arrows. When there is no additional overflow in either direction the scroll arrow should be inactive. ? The add environment icon and scrolling arrows now have a gray background to differentiate from the environment columns. The background should change to a darker gray on hover. ? The last environment column should fade to white to indicate additional content. The updated mock-ups and assets can be found here - http://design.lab.bos.redhat.com/wiki/Content_Browser Kyle Baker Visual Designer Desk (978) 392 3116 UX Team IRC kylebaker From kybaker at redhat.com Wed Jun 20 19:55:07 2012 From: kybaker at redhat.com (Kyle Baker) Date: Wed, 20 Jun 2012 15:55:07 -0400 (EDT) Subject: [katello-devel] Added copy functionality to system groups In-Reply-To: <9af43a51-8947-4f1b-81be-276760b8c580@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <8dda9553-c759-4002-8060-99226bdd68b1@zmail14.collab.prod.int.phx2.redhat.com> As part of the system groups feature they are adding the ability to clone an object. This involved expanding upon the existing object actions and adding 'Copy'. This a involved a tweaking existing visuals as well as adding an expandable menu. The mock-ups can be seen here - http://design.lab.bos.redhat.com/wiki/System_Groups#Copy_System_Group Kyle Baker Visual Designer Desk (978) 392 3116 UX Team IRC kylebaker From tstrachota at redhat.com Thu Jun 21 12:58:45 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Thu, 21 Jun 2012 14:58:45 +0200 Subject: [katello-devel] Foreman api work Message-ID: <4FE31A85.4030303@redhat.com> Just an announcement for the team: Martin and me have started to work on splitting the Foreman's controllers to ui and api part. If anyone is interested, we share the code here: https://github.com/mbacovsky/foreman/tree/api Tomas From jrist at redhat.com Thu Jun 21 13:20:20 2012 From: jrist at redhat.com (Jason Rist) Date: Thu, 21 Jun 2012 07:20:20 -0600 Subject: [katello-devel] Foreman api work In-Reply-To: <4FE31A85.4030303@redhat.com> References: <4FE31A85.4030303@redhat.com> Message-ID: <4FE31F94.3030501@redhat.com> On Thu 21 Jun 2012 06:58:45 AM MDT, Tomas Strachota wrote: > Just an announcement for the team: > > Martin and me have started to work on splitting the Foreman's > controllers to ui and api part. > If anyone is interested, we share the code here: > > https://github.com/mbacovsky/foreman/tree/api > > Tomas > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Wow, thanks for the heads up. This is a really great precedent. Let's keep it up! -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bkearney at redhat.com Thu Jun 21 14:22:13 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 21 Jun 2012 10:22:13 -0400 Subject: [katello-devel] Foreman api work In-Reply-To: <4FE31A85.4030303@redhat.com> References: <4FE31A85.4030303@redhat.com> Message-ID: <4FE32E15.30507@redhat.com> On 06/21/2012 08:58 AM, Tomas Strachota wrote: > Just an announcement for the team: > > Martin and me have started to work on splitting the Foreman's > controllers to ui and api part. > If anyone is interested, we share the code here: > > https://github.com/mbacovsky/foreman/tree/api > So, will the pattern be to remote the json code from the regular controllers? -- bk From ewoud+katello at kohlvanwijngaarden.nl Thu Jun 21 14:53:29 2012 From: ewoud+katello at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Thu, 21 Jun 2012 16:53:29 +0200 Subject: [katello-devel] Added copy functionality to system groups In-Reply-To: <8dda9553-c759-4002-8060-99226bdd68b1@zmail14.collab.prod.int.phx2.redhat.com> References: <9af43a51-8947-4f1b-81be-276760b8c580@zmail14.collab.prod.int.phx2.redhat.com> <8dda9553-c759-4002-8060-99226bdd68b1@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <20120621145329.GF28104@bogey.xentower.nl> On Wed, Jun 20, 2012 at 03:55:07PM -0400, Kyle Baker wrote: > As part of the system groups feature they are adding the ability to > clone an object. This involved expanding upon the existing object > actions and adding 'Copy'. This a involved a tweaking existing visuals > as well as adding an expandable menu. > > The mock-ups can be seen here - > http://design.lab.bos.redhat.com/wiki/System_Groups#Copy_System_Group I'm guessing that's an internal link because the DNS doesn't even resolve here. Remember it's a public mailing list. From kybaker at redhat.com Thu Jun 21 14:58:02 2012 From: kybaker at redhat.com (Kyle Baker) Date: Thu, 21 Jun 2012 10:58:02 -0400 (EDT) Subject: [katello-devel] Added copy functionality to system groups In-Reply-To: <20120621145329.GF28104@bogey.xentower.nl> Message-ID: <66d8620a-13ea-494e-8f94-dbee721c8015@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On Wed, Jun 20, 2012 at 03:55:07PM -0400, Kyle Baker wrote: > > As part of the system groups feature they are adding the ability to > > clone an object. This involved expanding upon the existing object > > actions and adding 'Copy'. This a involved a tweaking existing > > visuals > > as well as adding an expandable menu. > > > > The mock-ups can be seen here - > > http://design.lab.bos.redhat.com/wiki/System_Groups#Copy_System_Group > > I'm guessing that's an internal link because the DNS doesn't even > resolve here. Remember it's a public mailing list. Yes, I will find another place to post all of our work. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From thomasmckay at redhat.com Thu Jun 21 15:20:49 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 21 Jun 2012 11:20:49 -0400 (EDT) Subject: [katello-devel] Added copy functionality to system groups In-Reply-To: <20120621145329.GF28104@bogey.xentower.nl> Message-ID: ----- Original Message ----- > From: "Ewoud Kohl van Wijngaarden" > To: katello-devel at redhat.com > Sent: Thursday, June 21, 2012 10:53:29 AM > Subject: Re: [katello-devel] Added copy functionality to system groups > > On Wed, Jun 20, 2012 at 03:55:07PM -0400, Kyle Baker wrote: > > As part of the system groups feature they are adding the ability to > > clone an object. This involved expanding upon the existing object > > actions and adding 'Copy'. This a involved a tweaking existing > > visuals > > as well as adding an expandable menu. > > > > The mock-ups can be seen here - > > http://design.lab.bos.redhat.com/wiki/System_Groups#Copy_System_Group > > I'm guessing that's an internal link because the DNS doesn't even > resolve here. Remember it's a public mailing list. I agree. Can we get the UXD design work out onto the public wiki? > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From kybaker at redhat.com Thu Jun 21 15:32:42 2012 From: kybaker at redhat.com (Kyle Baker) Date: Thu, 21 Jun 2012 11:32:42 -0400 (EDT) Subject: [katello-devel] Added copy functionality to system groups In-Reply-To: Message-ID: <62533a4c-6f0b-4f81-af8d-b4194984ad59@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Ewoud Kohl van Wijngaarden" > > > > To: katello-devel at redhat.com > > Sent: Thursday, June 21, 2012 10:53:29 AM > > Subject: Re: [katello-devel] Added copy functionality to system > > groups > > > > On Wed, Jun 20, 2012 at 03:55:07PM -0400, Kyle Baker wrote: > > > As part of the system groups feature they are adding the ability > > > to > > > clone an object. This involved expanding upon the existing object > > > actions and adding 'Copy'. This a involved a tweaking existing > > > visuals > > > as well as adding an expandable menu. > > > > > > The mock-ups can be seen here - > > > http://design.lab.bos.redhat.com/wiki/System_Groups#Copy_System_Group > > > > I'm guessing that's an internal link because the DNS doesn't even > > resolve here. Remember it's a public mailing list. > > I agree. Can we get the UXD design work out onto the public wiki? Yes, we will come up with a solution that allows Katello UXD work to be public. > > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From mrao at redhat.com Thu Jun 21 20:01:29 2012 From: mrao at redhat.com (Malini Rao) Date: Thu, 21 Jun 2012 16:01:29 -0400 (EDT) Subject: [katello-devel] Nitty gritty UX feedback on System groups In-Reply-To: Message-ID: <20b43529-e52e-4bf3-ba79-56e0dd0eaa5e@zmail12.collab.prod.int.phx2.redhat.com> Hi Brad, I had made notes of some UX things that struck me as I watched your last Sprint demo for system groups. The major functionality looks great and these are at a pretty nitty gritty level but nevertheless important to fix at some point for the finished product. The only slightly bigger topic is where the events page should live and we can discuss that. Other than that, if you have any questions, let me know. Thanks Malini -------------- next part -------------- A non-text attachment was scrubbed... Name: UX feedback.odp Type: application/vnd.oasis.opendocument.presentation Size: 237910 bytes Desc: not available URL: From mrao at redhat.com Thu Jun 21 20:37:47 2012 From: mrao at redhat.com (Malini Rao) Date: Thu, 21 Jun 2012 16:37:47 -0400 (EDT) Subject: [katello-devel] Manage Organizations In-Reply-To: <38eaca8a-fde4-45ef-b06e-6df660e7ed85@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <99bb9da2-a30c-483f-a055-a2ddcf1be213@zmail12.collab.prod.int.phx2.redhat.com> Hello everyone, As a follow up to the discussion on managing orgs in an interstitial page and how it impacts the current permissions model, Kyle and I discussed how we could adjust the UI a bit more. Here's our proposal - We will have a 2 step log in - on the first page, the log in will look like how it is today but instead of the Login button, there will be a next button leading to a slide out page where the user will be presented the list of orgs they have permissions to see. The user makes a selection from this list and then presses the login button. They will then be launched straight into the landing page for Katello with the org switcher presenting the selected org. They will of course be able to switch orgs they have access to or choose the 'Manage Org' link at the bottom of the org switcher. But since this is buried in a more 'lightweight' widget like the Org switcher and since this is another administer activity, we will have the full manage org features available for only those with permissions in the administer area. 'Manage Organizations' within the Org switcher will link up to this page. Let us know if you have an questions or issues with this proposal. Thanks Malini -------------- next part -------------- A non-text attachment was scrubbed... Name: login-1.png Type: image/png Size: 52377 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: login-2.png Type: image/png Size: 52107 bytes Desc: not available URL: From bbuckingham at redhat.com Thu Jun 21 20:41:58 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Thu, 21 Jun 2012 16:41:58 -0400 Subject: [katello-devel] Nitty gritty UX feedback on System groups In-Reply-To: <20b43529-e52e-4bf3-ba79-56e0dd0eaa5e@zmail12.collab.prod.int.phx2.redhat.com> References: <20b43529-e52e-4bf3-ba79-56e0dd0eaa5e@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <4FE38716.40601@redhat.com> On 06/21/2012 04:01 PM, Malini Rao wrote: > Hi Brad, > > I had made notes of some UX things that struck me as I watched your last Sprint demo for system groups. The major functionality looks great and these are at a pretty nitty gritty level but nevertheless important to fix at some point for the finished product. The only slightly bigger topic is where the events page should live and we can discuss that. Other than that, if you have any questions, let me know. > > Thanks > Malini > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Hi Malini, Thanks for the comments. Most of them are straightforward and shouldn't be a big deal to address; however, I'll set up a meeting next week and we can discuss. Some of the comments are actually related to style that is used across the site, some are based on mockups we have for past 'similar' scenarios...etc.; however, definitely open for improvements. :) Cheers, Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrist at redhat.com Thu Jun 21 20:59:42 2012 From: jrist at redhat.com (Jason Rist) Date: Thu, 21 Jun 2012 14:59:42 -0600 Subject: [katello-devel] Manage Organizations In-Reply-To: <99bb9da2-a30c-483f-a055-a2ddcf1be213@zmail12.collab.prod.int.phx2.redhat.com> References: <38eaca8a-fde4-45ef-b06e-6df660e7ed85@zmail12.collab.prod.int.phx2.redhat.com> <99bb9da2-a30c-483f-a055-a2ddcf1be213@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <4FE38B3E.4050800@redhat.com> On Thu 21 Jun 2012 02:37:47 PM MDT, Malini Rao wrote: > Hello everyone, > > As a follow up to the discussion on managing orgs in an interstitial page and how it impacts the current permissions model, Kyle and I discussed how we could adjust the UI a bit more. Here's our proposal - > > We will have a 2 step log in - on the first page, the log in will look like how it is today but instead of the Login button, there will be a next button leading to a slide out page where the user will be presented the list of orgs they have permissions to see. The user makes a selection from this list and then presses the login button. They will then be launched straight into the landing page for Katello with the org switcher presenting the selected org. They will of course be able to switch orgs they have access to or choose the 'Manage Org' link at the bottom of the org switcher. > > But since this is buried in a more 'lightweight' widget like the Org switcher and since this is another administer activity, we will have the full manage org features available for only those with permissions in the administer area. 'Manage Organizations' within the Org switcher will link up to this page. > > Let us know if you have an questions or issues with this proposal. > > Thanks > Malini > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Yeah, that's close to what I was thinking. This will be fine. I think we should do "Login" (instead of next) still, but have the login-2 be a step before finally logging in. I'm very happy with this approach. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From lzap at redhat.com Fri Jun 22 08:58:21 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 22 Jun 2012 10:58:21 +0200 Subject: [katello-devel] Manage Organizations In-Reply-To: <99bb9da2-a30c-483f-a055-a2ddcf1be213@zmail12.collab.prod.int.phx2.redhat.com> References: <38eaca8a-fde4-45ef-b06e-6df660e7ed85@zmail12.collab.prod.int.phx2.redhat.com> <99bb9da2-a30c-483f-a055-a2ddcf1be213@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <20120622085821.GB4435@lzapx.brq.redhat.com> Why not, but if the user has permission to only one organization, I would recommend to completely skip this dialog not asking anything. LZ On Thu, Jun 21, 2012 at 04:37:47PM -0400, Malini Rao wrote: > Hello everyone, > > As a follow up to the discussion on managing orgs in an interstitial page and how it impacts the current permissions model, Kyle and I discussed how we could adjust the UI a bit more. Here's our proposal - > > We will have a 2 step log in - on the first page, the log in will look like how it is today but instead of the Login button, there will be a next button leading to a slide out page where the user will be presented the list of orgs they have permissions to see. The user makes a selection from this list and then presses the login button. They will then be launched straight into the landing page for Katello with the org switcher presenting the selected org. They will of course be able to switch orgs they have access to or choose the 'Manage Org' link at the bottom of the org switcher. > > But since this is buried in a more 'lightweight' widget like the Org switcher and since this is another administer activity, we will have the full manage org features available for only those with permissions in the administer area. 'Manage Organizations' within the Org switcher will link up to this page. > > Let us know if you have an questions or issues with this proposal. > > Thanks > Malini > _______________________________________________ > 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 Fri Jun 22 11:11:32 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 22 Jun 2012 07:11:32 -0400 (EDT) Subject: [katello-devel] Nitty gritty UX feedback on System groups In-Reply-To: <20b43529-e52e-4bf3-ba79-56e0dd0eaa5e@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: ----- Original Message ----- > From: "Malini Rao" > To: katello-devel at redhat.com > Cc: "Brad Buckingham" > Sent: Thursday, June 21, 2012 4:01:29 PM > Subject: [katello-devel] Nitty gritty UX feedback on System groups > > Hi Brad, > > I had made notes of some UX things that struck me as I watched your > last Sprint demo for system groups. The major functionality looks > great and these are at a pretty nitty gritty level but nevertheless > important to fix at some point for the finished product. The only > slightly bigger topic is where the events page should live and we > can discuss that. Other than that, if you have any questions, let me > know. > > Thanks > Malini > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > Slide 1: + "Just use simple numbers instead of the oval round" - Disagree. The oval style is an explicit indicator that hovering over it will bring up a "tipsy" with more information. Slide 2: + "Should not use all caps for title." - This is consistent across the entire site for titles of tables. Why the change? + "Title too long." - If there's room, please retain verbose wording. A valid reason to reconsider might be if translations to primary supported languages cause wrapping of title. Slide 3: + "Sub nav should be reconsidered." - Disagree. There are some panels that are very crowded (eg. Systems). + "Events under Details" - Agree. I believe Kyle(?) instigated the rule that Details always be the first tab with "Events History" under that. (eg. see Systems) + "Event detail should be more closely related to where the action takes place" - Don't understand. This table is the list of packages and package groups that are being installed, updated, or removed. + "Link to events page" - Agree. That would be nice. However, I am against having to go to another page to get details about something that can just as easily be shown inline (eg. through a tipsy). Our UI is not friendly in switching back and forth between pages at the moment. From thomasmckay at redhat.com Fri Jun 22 11:22:13 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 22 Jun 2012 07:22:13 -0400 (EDT) Subject: [katello-devel] Manage Organizations In-Reply-To: <99bb9da2-a30c-483f-a055-a2ddcf1be213@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <72b1850b-900b-48f4-aef9-385e4932fa14@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Malini Rao" > To: katello-devel at redhat.com > Sent: Thursday, June 21, 2012 4:37:47 PM > Subject: [katello-devel] Manage Organizations > > Hello everyone, > > As a follow up to the discussion on managing orgs in an interstitial > page and how it impacts the current permissions model, Kyle and I > discussed how we could adjust the UI a bit more. Here's our proposal > - > > We will have a 2 step log in - on the first page, the log in will > look like how it is today but instead of the Login button, there > will be a next button leading to a slide out page where the user > will be presented the list of orgs they have permissions to see. The > user makes a selection from this list and then presses the login > button. They will then be launched straight into the landing page > for Katello with the org switcher presenting the selected org. They > will of course be able to switch orgs they have access to or choose > the 'Manage Org' link at the bottom of the org switcher. The "Next" button on a login widget seems very odd; you are in fact logging in here, not next-ing. Perhaps keep it as Login and have the org chooser be a dialog that overlays the orgs page? If I read this correctly, after logging in and choosing an org, the user is still brought to the orgs interstitial. > > But since this is buried in a more 'lightweight' widget like the Org > switcher and since this is another administer activity, we will have > the full manage org features available for only those with > permissions in the administer area. 'Manage Organizations' within > the Org switcher will link up to this page. > > Let us know if you have an questions or issues with this proposal. > > Thanks > Malini > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From bkearney at redhat.com Fri Jun 22 12:11:29 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Fri, 22 Jun 2012 08:11:29 -0400 Subject: [katello-devel] Manage Organizations In-Reply-To: <72b1850b-900b-48f4-aef9-385e4932fa14@zmail16.collab.prod.int.phx2.redhat.com> References: <72b1850b-900b-48f4-aef9-385e4932fa14@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4FE460F1.3040907@redhat.com> On 06/22/2012 07:22 AM, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Malini Rao" >> To: katello-devel at redhat.com >> Sent: Thursday, June 21, 2012 4:37:47 PM >> Subject: [katello-devel] Manage Organizations >> >> Hello everyone, >> >> As a follow up to the discussion on managing orgs in an interstitial >> page and how it impacts the current permissions model, Kyle and I >> discussed how we could adjust the UI a bit more. Here's our proposal >> - >> >> We will have a 2 step log in - on the first page, the log in will >> look like how it is today but instead of the Login button, there >> will be a next button leading to a slide out page where the user >> will be presented the list of orgs they have permissions to see. The >> user makes a selection from this list and then presses the login >> button. They will then be launched straight into the landing page >> for Katello with the org switcher presenting the selected org. They >> will of course be able to switch orgs they have access to or choose >> the 'Manage Org' link at the bottom of the org switcher. > > The "Next" button on a login widget seems very odd; you are in fact logging in here, not next-ing. Perhaps keep it as Login and have the org chooser be a dialog that overlays the orgs page? If I read this correctly, after logging in and choosing an org, the user is still brought to the orgs interstitial. agree.. should be login. You dont see the orgs until you are logged in. what does the org switcher look like now? +1 to skipping this if only one org (or none). -- bk From thomasmckay at redhat.com Fri Jun 22 12:29:50 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Fri, 22 Jun 2012 08:29:50 -0400 (EDT) Subject: [katello-devel] new login screen In-Reply-To: <849e7c13-dc29-4384-a53e-41e7d1bb86b4@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <28fb1f70-923b-4662-9825-bf28142f56e7@zmail16.collab.prod.int.phx2.redhat.com> Is it possible to place the login panel centered vertically in the space? (See attachment) -------------- next part -------------- A non-text attachment was scrubbed... Name: login.png Type: image/png Size: 63572 bytes Desc: not available URL: From kybaker at redhat.com Fri Jun 22 12:44:49 2012 From: kybaker at redhat.com (Kyle Baker) Date: Fri, 22 Jun 2012 08:44:49 -0400 (EDT) Subject: [katello-devel] new login screen In-Reply-To: <28fb1f70-923b-4662-9825-bf28142f56e7@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: ----- Original Message ----- > > Is it possible to place the login panel centered vertically in the > space? (See attachment) +1 - This was part of Harlan's feedback to Eric. > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From ehelms at redhat.com Fri Jun 22 12:51:27 2012 From: ehelms at redhat.com (Eric Helms) Date: Fri, 22 Jun 2012 08:51:27 -0400 (EDT) Subject: [katello-devel] new login screen In-Reply-To: Message-ID: <90a75717-5c24-475f-9a2a-80f1fcf9f3d2@zmail16.collab.prod.int.phx2.redhat.com> Centering vertically and dynamically is a PITA, but possible. - Eric ----- Original Message ----- From: "Kyle Baker" To: "Tom McKay" Cc: katello-devel at redhat.com Sent: Friday, June 22, 2012 8:44:49 AM Subject: Re: [katello-devel] new login screen ----- Original Message ----- > > Is it possible to place the login panel centered vertically in the > space? (See attachment) +1 - This was part of Harlan's feedback to Eric. > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > _______________________________________________ katello-devel mailing list katello-devel at redhat.com https://www.redhat.com/mailman/listinfo/katello-devel From calfonso at redhat.com Fri Jun 22 13:00:53 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Fri, 22 Jun 2012 09:00:53 -0400 Subject: [katello-devel] Running Foreman tests - need to change settings.yaml Message-ID: <20120622130053.GA9421@localhost.localdomain> I'm posting this on katello-devel even though this is a Foreman tidbit because of the integration work that's ramping up. It was not apparent to me that I would need to set the login setting to 'true' to get the foreman tests to run. Is there another way to run the tests successfully without changing the login setting default value? If not, any reason to not just have the default set to 'true'? If we need to keep the default set to true, perhaps documenting this in the Foreman README. - Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From jrist at redhat.com Fri Jun 22 13:34:19 2012 From: jrist at redhat.com (Jason Rist) Date: Fri, 22 Jun 2012 07:34:19 -0600 Subject: [katello-devel] Nitty gritty UX feedback on System groups In-Reply-To: References: <20b43529-e52e-4bf3-ba79-56e0dd0eaa5e@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <4FE4745B.7020905@redhat.com> On Fri 22 Jun 2012 05:11:32 AM MDT, Tom McKay wrote: > > > ----- Original Message ----- >> From: "Malini Rao" >> To: katello-devel at redhat.com >> Cc: "Brad Buckingham" >> Sent: Thursday, June 21, 2012 4:01:29 PM >> Subject: [katello-devel] Nitty gritty UX feedback on System groups >> >> Hi Brad, >> >> I had made notes of some UX things that struck me as I watched your >> last Sprint demo for system groups. The major functionality looks >> great and these are at a pretty nitty gritty level but nevertheless >> important to fix at some point for the finished product. The only >> slightly bigger topic is where the events page should live and we >> can discuss that. Other than that, if you have any questions, let me >> know. >> >> Thanks >> Malini >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel >> > > > Slide 1: > + "Just use simple numbers instead of the oval round" - Disagree. The oval style is an explicit indicator that hovering over it will bring up a "tipsy" with more information. > > Slide 2: > + "Should not use all caps for title." - This is consistent across the entire site for titles of tables. Why the change? > > + "Title too long." - If there's room, please retain verbose wording. A valid reason to reconsider might be if translations to primary supported languages cause wrapping of title. > > Slide 3: > + "Sub nav should be reconsidered." - Disagree. There are some panels that are very crowded (eg. Systems). > > + "Events under Details" - Agree. I believe Kyle(?) instigated the rule that Details always be the first tab with "Events History" under that. (eg. see Systems) > > + "Event detail should be more closely related to where the action takes place" - Don't understand. This table is the list of packages and package groups that are being installed, updated, or removed. > > + "Link to events page" - Agree. That would be nice. However, I am against having to go to another page to get details about something that can just as easily be shown inline (eg. through a tipsy). Our UI is not friendly in switching back and forth between pages at the moment. > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel I definitely have to agree with Tom on Slide 1. I have this to add: "Need to standardize how hover states look ? Contact Kyle/ Harlan about that. " - Why? One type of tipsy has help information (black) and one contains expanded information about what you're hovering over (white). This is established (packages) and common. Agree with Tom on Slide 2 on both points. Why be terse when verbose is so much more helpful and the difference is so minor? Otherwise it's more unclear and confusing, degrading the user experience. Agree again with Tom on Events under Details. What should be the default (first showing upon panel expansion) page for this pane? I am not sure that System Group Info or Events would be good/useful. Slide 4: "Group 1 title is getting cut off because of the way the package install panel overlays on top. Need to adjust the spacing so there is no clipping." This should be a bug across the system, as it will impact everything with a subpanel. -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bbuckingham at redhat.com Fri Jun 22 13:47:28 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Fri, 22 Jun 2012 09:47:28 -0400 Subject: [katello-devel] Nitty gritty UX feedback on System groups In-Reply-To: <4FE4745B.7020905@redhat.com> References: <20b43529-e52e-4bf3-ba79-56e0dd0eaa5e@zmail12.collab.prod.int.phx2.redhat.com> <4FE4745B.7020905@redhat.com> Message-ID: <4FE47770.4090400@redhat.com> On 06/22/2012 09:34 AM, Jason Rist wrote: > On Fri 22 Jun 2012 05:11:32 AM MDT, Tom McKay wrote: >> >> >> ----- Original Message ----- >>> From: "Malini Rao" >>> To: katello-devel at redhat.com >>> Cc: "Brad Buckingham" >>> Sent: Thursday, June 21, 2012 4:01:29 PM >>> Subject: [katello-devel] Nitty gritty UX feedback on System groups >>> >>> Hi Brad, >>> >>> I had made notes of some UX things that struck me as I watched your >>> last Sprint demo for system groups. The major functionality looks >>> great and these are at a pretty nitty gritty level but nevertheless >>> important to fix at some point for the finished product. The only >>> slightly bigger topic is where the events page should live and we >>> can discuss that. Other than that, if you have any questions, let me >>> know. >>> >>> Thanks >>> Malini >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> >> >> Slide 1: >> + "Just use simple numbers instead of the oval round" - Disagree. The >> oval style is an explicit indicator that hovering over it will bring >> up a "tipsy" with more information. >> >> Slide 2: >> + "Should not use all caps for title." - This is consistent across >> the entire site for titles of tables. Why the change? >> >> + "Title too long." - If there's room, please retain verbose wording. >> A valid reason to reconsider might be if translations to primary >> supported languages cause wrapping of title. >> >> Slide 3: >> + "Sub nav should be reconsidered." - Disagree. There are some panels >> that are very crowded (eg. Systems). >> >> + "Events under Details" - Agree. I believe Kyle(?) instigated the >> rule that Details always be the first tab with "Events History" under >> that. (eg. see Systems) >> >> + "Event detail should be more closely related to where the action >> takes place" - Don't understand. This table is the list of packages >> and package groups that are being installed, updated, or removed. >> >> + "Link to events page" - Agree. That would be nice. However, I am >> against having to go to another page to get details about something >> that can just as easily be shown inline (eg. through a tipsy). Our UI >> is not friendly in switching back and forth between pages at the moment. >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > I definitely have to agree with Tom on Slide 1. I have this to add: > "Need to standardize how hover states look ? Contact Kyle/ Harlan > about that. " - Why? One type of tipsy has help information (black) > and one contains expanded information about what you're hovering over > (white). This is established (packages) and common. > > Agree with Tom on Slide 2 on both points. Why be terse when verbose is > so much more helpful and the difference is so minor? Otherwise it's > more unclear and confusing, degrading the user experience. > > Agree again with Tom on Events under Details. What should be the > default (first showing upon panel expansion) page for this pane? I am > not sure that System Group Info or Events would be good/useful. > > Slide 4: "Group 1 title is getting cut off because of the way the > package install panel overlays on top. Need to adjust the spacing so > there is no clipping." > This should be a bug across the system, as it will impact everything > with a subpanel. > I was going to wait for the meeting, but now I'm compelled to add a reply. :) Slide 1: - agree with the comments above - "Use colon instead of the | after the field label" - We can do that; however, this style as used as it was part of the System->Errata mockup used for past implementations. If we change it here, we should propagate the styling there as well. Slide 2: - agree with the comments above Slide 3: - "Sub nav should be reconsidered" - agree with the comments above. This was done to be consistent with System->Details->Events (now both are called Event History). If we change this here, we also need revisit systems for consistency. - "Event details should be more closely related to where the action takes place" - Was actually planning to make this either a tipsy (upon completion) or link to open the actual event (e.g. subpanel). Using the link may actually be better in this case as there could be a fair amount of information generated depending upon the size of the group. Another alternative would be a tipsy w/ brief summary with link in the tipsy that opens the event for more details. Slide 4 - - agree with the comments above. This one is actually a generic 2-pane issue. From mrao at redhat.com Fri Jun 22 16:22:20 2012 From: mrao at redhat.com (Malini Rao) Date: Fri, 22 Jun 2012 12:22:20 -0400 (EDT) Subject: [katello-devel] Nitty gritty UX feedback on System groups In-Reply-To: <4FE47770.4090400@redhat.com> Message-ID: Hello everyone, Thanks for the feedback on email and in the meeting this morning about the feedback I sent. Here's the summary of what we discussed in the meeting based on my original feedback and the responses received thereafter - 1. "Just use simple numbers instead of the oval round" - There are black tooltips and white info-tipsies in place in the tool today and the latter can stick upon click and even scroll if necessary. Both need some kind of affordance that a hover state exists and since they are distinguished visually, it will be good to carryover that distinction in the trigger affordance as well. While I wasn't proposing simple text in my original feedback, I feel like we should not use the visual treatment reserved for notifications, alerts and summary rollups for this purpose since it reduces the impact and effectiveness of that treatment for the original purpose. Group did not like the idea of using a link for the number. ACTION ITEM: - Harlan/ Kyle will explore how this can be presented in another way that will work across the board as a pattern for triggering info-tips. 2. "Should not use all caps for title." - I understand this is consistent across the board but it is pretty rare to have all caps for titles as a general UX best practice. This becomes more of an issue when the titles are more than a one word label which is probably how it was used when it was first proposed. Tom's point about potential translation issues is also very valid. I don't think Brad needs to make any change for this page right now but we should reconsider this when updating the styles as part of extending the new Shell styles down to pages and components. Similarly, there was an agreement that the pipe is best used to separate groupings and so we can use the colon consistently when we update the styles. ACTION ITEM: - Harlan/ Kyle will take this ( All caps and Pipe) into account as they are extending the new updated visual feel. We will share these at some point for comments and feedback. 3. "Title too long." - Yes, there can be merits in being more verbose but here, it does not seem to add more value. In general UX best practices for titles is that they should be short, crisp and articulate. The shorter they are, the more they will stand out as titles and allow better scanabilty. Brad explained that there was some feedback on how this was confusing and so he ended up making the title long and no one on the call had objections to shortening this esp since it will be hard to make this a consistent pattern and list all actions possible on any given page as part of the title. The title also seems to be attached only to the top parameters and not the list below which might be adding to the confusion on what is happening on the page. Some of this could potentially be alleviated by pulling the title out of the table. ACTION ITEMS: - Brad to shorten the title. - Kyle to send Brad an example of the title displaying outside the tables so Brad can model this fix after it. 4. Events - Brad explained the intended flow and interaction. All agreed that having a link between the status on the install/ update packages page and the event details is important to make the task flow seem more seamless. Seems also like the Events page will likely be more heavy weight with many other types of events that could be possible in the future. Until that point, we will not move the events page from where it is. ACTION ITEMS: - Brad to send UX the events list page so we can have all the screenshots of the interaction flow. - UX to propose & share a way in which the event information can be presented alongside the status of the job on the Packages / errata pages without necessarily having to go find it on the events page ( some ideas talked about were info tips, overlay panels etc.) Thanks Malini ----- Original Message ----- From: "Brad Buckingham" To: jrist at redhat.com Cc: "Tom McKay" , katello-devel at redhat.com, "Malini Rao" Sent: Friday, June 22, 2012 9:47:28 AM Subject: Re: [katello-devel] Nitty gritty UX feedback on System groups On 06/22/2012 09:34 AM, Jason Rist wrote: > On Fri 22 Jun 2012 05:11:32 AM MDT, Tom McKay wrote: >> >> >> ----- Original Message ----- >>> From: "Malini Rao" >>> To: katello-devel at redhat.com >>> Cc: "Brad Buckingham" >>> Sent: Thursday, June 21, 2012 4:01:29 PM >>> Subject: [katello-devel] Nitty gritty UX feedback on System groups >>> >>> Hi Brad, >>> >>> I had made notes of some UX things that struck me as I watched your >>> last Sprint demo for system groups. The major functionality looks >>> great and these are at a pretty nitty gritty level but nevertheless >>> important to fix at some point for the finished product. The only >>> slightly bigger topic is where the events page should live and we >>> can discuss that. Other than that, if you have any questions, let me >>> know. >>> >>> Thanks >>> Malini >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >>> >> >> >> Slide 1: >> + "Just use simple numbers instead of the oval round" - Disagree. The >> oval style is an explicit indicator that hovering over it will bring >> up a "tipsy" with more information. >> >> Slide 2: >> + "Should not use all caps for title." - This is consistent across >> the entire site for titles of tables. Why the change? >> >> + "Title too long." - If there's room, please retain verbose wording. >> A valid reason to reconsider might be if translations to primary >> supported languages cause wrapping of title. >> >> Slide 3: >> + "Sub nav should be reconsidered." - Disagree. There are some panels >> that are very crowded (eg. Systems). >> >> + "Events under Details" - Agree. I believe Kyle(?) instigated the >> rule that Details always be the first tab with "Events History" under >> that. (eg. see Systems) >> >> + "Event detail should be more closely related to where the action >> takes place" - Don't understand. This table is the list of packages >> and package groups that are being installed, updated, or removed. >> >> + "Link to events page" - Agree. That would be nice. However, I am >> against having to go to another page to get details about something >> that can just as easily be shown inline (eg. through a tipsy). Our UI >> is not friendly in switching back and forth between pages at the moment. >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > I definitely have to agree with Tom on Slide 1. I have this to add: > "Need to standardize how hover states look ? Contact Kyle/ Harlan > about that. " - Why? One type of tipsy has help information (black) > and one contains expanded information about what you're hovering over > (white). This is established (packages) and common. > > Agree with Tom on Slide 2 on both points. Why be terse when verbose is > so much more helpful and the difference is so minor? Otherwise it's > more unclear and confusing, degrading the user experience. > > Agree again with Tom on Events under Details. What should be the > default (first showing upon panel expansion) page for this pane? I am > not sure that System Group Info or Events would be good/useful. > > Slide 4: "Group 1 title is getting cut off because of the way the > package install panel overlays on top. Need to adjust the spacing so > there is no clipping." > This should be a bug across the system, as it will impact everything > with a subpanel. > I was going to wait for the meeting, but now I'm compelled to add a reply. :) Slide 1: - agree with the comments above - "Use colon instead of the | after the field label" - We can do that; however, this style as used as it was part of the System->Errata mockup used for past implementations. If we change it here, we should propagate the styling there as well. Slide 2: - agree with the comments above Slide 3: - "Sub nav should be reconsidered" - agree with the comments above. This was done to be consistent with System->Details->Events (now both are called Event History). If we change this here, we also need revisit systems for consistency. - "Event details should be more closely related to where the action takes place" - Was actually planning to make this either a tipsy (upon completion) or link to open the actual event (e.g. subpanel). Using the link may actually be better in this case as there could be a fair amount of information generated depending upon the size of the group. Another alternative would be a tipsy w/ brief summary with link in the tipsy that opens the event for more details. Slide 4 - - agree with the comments above. This one is actually a generic 2-pane issue. From tstrachota at redhat.com Mon Jun 25 08:06:13 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Mon, 25 Jun 2012 10:06:13 +0200 Subject: [katello-devel] Foreman api work In-Reply-To: <4FE32E15.30507@redhat.com> References: <4FE31A85.4030303@redhat.com> <4FE32E15.30507@redhat.com> Message-ID: <4FE81BF5.5060206@redhat.com> On 06/21/2012 04:22 PM, Bryan Kearney wrote: > On 06/21/2012 08:58 AM, Tomas Strachota wrote: >> Just an announcement for the team: >> >> Martin and me have started to work on splitting the Foreman's >> controllers to ui and api part. >> If anyone is interested, we share the code here: >> >> https://github.com/mbacovsky/foreman/tree/api >> > So, will the pattern be to remote the json code from the regular > controllers? > > -- bk > Yes, it will be generated using rabl [1] templates. It gives us easier control over what is printed to the output. No need to change to_json methods everywhere when you decide to modify structure of the output. 1) https://github.com/nesquena/rabl T. From jsherril at redhat.com Mon Jun 25 14:46:04 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 25 Jun 2012 10:46:04 -0400 Subject: [katello-devel] Faster demoing without production! Message-ID: <4FE879AC.7020300@redhat.com> Ever demoed a web UI action and had to wait wait wait? Want to speed things up without the mess of converting to production and generating assets? Well I've got the configuration change for you, simply follow this two step plan and you'll be on your way to demoing in development mode so fast viewers will think you've got a mainframe! 1. Change config.cache_classes = true in src/config/environments/development.rb 2. Restart your thin server. Thats it! Lets compare some time differences shall we: Systems page: Before:7490ms After: 2541 ms Systems items: Before: 4655ms After: 695 ms Providers page: Before: 7084ms After: 1743 ms Providers items: Before: 3613ms After: 121 ms Its that easy! From jrist at redhat.com Mon Jun 25 14:50:16 2012 From: jrist at redhat.com (Jason Rist) Date: Mon, 25 Jun 2012 08:50:16 -0600 Subject: [katello-devel] Faster demoing without production! In-Reply-To: <4FE879AC.7020300@redhat.com> References: <4FE879AC.7020300@redhat.com> Message-ID: <4FE87AA8.8070403@redhat.com> On Mon 25 Jun 2012 08:46:04 AM MDT, Justin Sherrill wrote: > > Ever demoed a web UI action and had to wait wait wait? > Want to speed things up without the mess of converting to production > and generating assets? > Well I've got the configuration change for you, simply follow this two > step plan and you'll be on your way to demoing in development mode so > fast viewers will think you've got a mainframe! > > 1. Change config.cache_classes = true in > src/config/environments/development.rb > 2. Restart your thin server. > > Thats it! > > Lets compare some time differences shall we: > > Systems page: > Before:7490ms After: 2541 ms > > Systems items: > Before: 4655ms After: 695 ms > > Providers page: > Before: 7084ms After: 1743 ms > > Providers items: > Before: 3613ms After: 121 ms > > > Its that easy! > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Would changing config.action_controller.perform_caching to true also help? If we're caching classes I'm assuming this is only for demo purposes if you're working on classes... -J -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From jsherril at redhat.com Mon Jun 25 15:01:43 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Mon, 25 Jun 2012 11:01:43 -0400 Subject: [katello-devel] Faster demoing without production! In-Reply-To: <4FE87AA8.8070403@redhat.com> References: <4FE879AC.7020300@redhat.com> <4FE87AA8.8070403@redhat.com> Message-ID: <4FE87D57.8030805@redhat.com> On 06/25/2012 10:50 AM, Jason Rist wrote: > On Mon 25 Jun 2012 08:46:04 AM MDT, Justin Sherrill wrote: >> >> Ever demoed a web UI action and had to wait wait wait? >> Want to speed things up without the mess of converting to production >> and generating assets? >> Well I've got the configuration change for you, simply follow this >> two step plan and you'll be on your way to demoing in development >> mode so fast viewers will think you've got a mainframe! >> >> 1. Change config.cache_classes = true in >> src/config/environments/development.rb >> 2. Restart your thin server. >> >> Thats it! >> >> Lets compare some time differences shall we: >> >> Systems page: >> Before:7490ms After: 2541 ms >> >> Systems items: >> Before: 4655ms After: 695 ms >> >> Providers page: >> Before: 7084ms After: 1743 ms >> >> Providers items: >> Before: 3613ms After: 121 ms >> >> >> Its that easy! >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > Would changing config.action_controller.perform_caching to true also > help? If we're caching classes I'm assuming this is only for demo > purposes if you're working on classes... > > -J > Looks like for the items actions its shaving off about 50 ms and on the main index pages about 400 ms. So feel free for some extra speed. From jmatthew at redhat.com Mon Jun 25 17:10:19 2012 From: jmatthew at redhat.com (John Matthews) Date: Mon, 25 Jun 2012 13:10:19 -0400 (EDT) Subject: [katello-devel] SELinux for Pulp Development Environments In-Reply-To: Message-ID: <7ec48dca-54b1-4ce7-8f1a-7326d1b09826@zmail13.collab.prod.int.phx2.redhat.com> We've made a few changes and updated the selinux dev setup into a single script 'pulp-selinux.py'. If you are running Pulp from a git checkout and want to run with SELinux enabled run: sudo ./pulp-selinux.py -I To uninstall: sudo ./pulp-selinux.py -U These instructions are captured in the below wiki page: https://fedorahosted.org/pulp/wiki/SELinux/DevSetup The script can be viewed here: http://git.fedorahosted.org/git/?p=pulp.git;a=blob;f=pulp-selinux.py;hb=HEAD If you run into any issues please let me know. From omaciel at redhat.com Tue Jun 26 14:48:25 2012 From: omaciel at redhat.com (Og Maciel) Date: Tue, 26 Jun 2012 10:48:25 -0400 (EDT) Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <14ecea54-fb79-4099-b020-57da5e267c6e@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> It all started with this Bz i filed this morning: https://bugzilla.redhat.com/show_bug.cgi?id=835586 Then Preethi pointed me to https://bugzilla.redhat.com/show_bug.cgi?id=817914 Which then pointed to my discussion in #pulp which can be seen (most of it) here: https://bugzilla.redhat.com/show_bug.cgi?id=835586#c3 The bottom line: are we going to disallow users from creating i18n organizations now??? -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From bkearney at redhat.com Tue Jun 26 14:52:47 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 26 Jun 2012 10:52:47 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <4FE9CCBF.3000604@redhat.com> On 06/26/2012 10:48 AM, Og Maciel wrote: > It all started with this Bz i filed this morning: https://bugzilla.redhat.com/show_bug.cgi?id=835586 > > Then Preethi pointed me to https://bugzilla.redhat.com/show_bug.cgi?id=817914 > > Which then pointed to my discussion in #pulp which can be seen (most of it) here: https://bugzilla.redhat.com/show_bug.cgi?id=835586#c3 > > The bottom line: are we going to disallow users from creating i18n organizations now??? > Can we urlencode the i18n characters and have it JustWork(tm)? That seems like a much friendlier model. -- bk From jsherril at redhat.com Tue Jun 26 15:13:01 2012 From: jsherril at redhat.com (Justin Sherrill) Date: Tue, 26 Jun 2012 11:13:01 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FE9CCBF.3000604@redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> Message-ID: <4FE9D17D.3020203@redhat.com> On 06/26/2012 10:52 AM, Bryan Kearney wrote: > On 06/26/2012 10:48 AM, Og Maciel wrote: >> It all started with this Bz i filed this morning: >> https://bugzilla.redhat.com/show_bug.cgi?id=835586 >> >> Then Preethi pointed me to >> https://bugzilla.redhat.com/show_bug.cgi?id=817914 >> >> Which then pointed to my discussion in #pulp which can be seen (most >> of it) here: https://bugzilla.redhat.com/show_bug.cgi?id=835586#c3 >> >> The bottom line: are we going to disallow users from creating i18n >> organizations now??? >> > Can we urlencode the i18n characters and have it JustWork(tm)? That > seems like a much friendlier model. We could do something like that, although it would make it really unreadable, and at that point we may not even want to include it in the name. is having something like: m%C3%A1n%C3%A1%C3%B1a in a repo name really helpful? > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From bkearney at redhat.com Tue Jun 26 15:15:45 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 26 Jun 2012 11:15:45 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FE9D17D.3020203@redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> <4FE9D17D.3020203@redhat.com> Message-ID: <4FE9D221.8050606@redhat.com> On 06/26/2012 11:13 AM, Justin Sherrill wrote: > On 06/26/2012 10:52 AM, Bryan Kearney wrote: >> On 06/26/2012 10:48 AM, Og Maciel wrote: >>> It all started with this Bz i filed this morning: >>> https://bugzilla.redhat.com/show_bug.cgi?id=835586 >>> >>> Then Preethi pointed me to >>> https://bugzilla.redhat.com/show_bug.cgi?id=817914 >>> >>> Which then pointed to my discussion in #pulp which can be seen (most >>> of it) here: https://bugzilla.redhat.com/show_bug.cgi?id=835586#c3 >>> >>> The bottom line: are we going to disallow users from creating i18n >>> organizations now??? >>> >> Can we urlencode the i18n characters and have it JustWork(tm)? That >> seems like a much friendlier model. > > We could do something like that, although it would make it really > unreadable, and at that point we may not even want to include it in the > name. > > is having something like: m%C3%A1n%C3%A1%C3%B1a in a repo name really > helpful? I dunno, I might prefer that if i can get the org and product names to be in my native language. Thoughts? -- bk From ehelms at redhat.com Tue Jun 26 15:32:28 2012 From: ehelms at redhat.com (Eric Helms) Date: Tue, 26 Jun 2012 11:32:28 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FE9D221.8050606@redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> <4FE9D17D.3020203@redhat.com> <4FE9D221.8050606@redhat.com> Message-ID: <4FE9D60C.9010101@redhat.com> On 06/26/2012 11:15 AM, Bryan Kearney wrote: > On 06/26/2012 11:13 AM, Justin Sherrill wrote: >> On 06/26/2012 10:52 AM, Bryan Kearney wrote: >>> On 06/26/2012 10:48 AM, Og Maciel wrote: >>>> It all started with this Bz i filed this morning: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=835586 >>>> >>>> Then Preethi pointed me to >>>> https://bugzilla.redhat.com/show_bug.cgi?id=817914 >>>> >>>> Which then pointed to my discussion in #pulp which can be seen (most >>>> of it) here: https://bugzilla.redhat.com/show_bug.cgi?id=835586#c3 >>>> >>>> The bottom line: are we going to disallow users from creating i18n >>>> organizations now??? >>>> >>> Can we urlencode the i18n characters and have it JustWork(tm)? That >>> seems like a much friendlier model. >> >> We could do something like that, although it would make it really >> unreadable, and at that point we may not even want to include it in the >> name. >> >> is having something like: m%C3%A1n%C3%A1%C3%B1a in a repo name really >> helpful? > > > I dunno, I might prefer that if i can get the org and product names to > be in my native language. > > Thoughts? > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel Do we really need to be storing the repository name in Pulp? Why not generate some unique identifier? I would think all that matters is some way to connect the Katello repository model to the Pulp via some sort of identifier so that we can retrieve the information we need about it. And then store the user defined "name" in Katello. - Eric From bkearney at redhat.com Tue Jun 26 15:35:22 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 26 Jun 2012 11:35:22 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FE9D60C.9010101@redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> <4FE9D17D.3020203@redhat.com> <4FE9D221.8050606@redhat.com> <4FE9D60C.9010101@redhat.com> Message-ID: <4FE9D6BA.6010402@redhat.com> On 06/26/2012 11:32 AM, Eric Helms wrote: > On 06/26/2012 11:15 AM, Bryan Kearney wrote: >> On 06/26/2012 11:13 AM, Justin Sherrill wrote: >>> On 06/26/2012 10:52 AM, Bryan Kearney wrote: >>>> On 06/26/2012 10:48 AM, Og Maciel wrote: >>>>> It all started with this Bz i filed this morning: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=835586 >>>>> >>>>> Then Preethi pointed me to >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=817914 >>>>> >>>>> Which then pointed to my discussion in #pulp which can be seen (most >>>>> of it) here: https://bugzilla.redhat.com/show_bug.cgi?id=835586#c3 >>>>> >>>>> The bottom line: are we going to disallow users from creating i18n >>>>> organizations now??? >>>>> >>>> Can we urlencode the i18n characters and have it JustWork(tm)? That >>>> seems like a much friendlier model. >>> >>> We could do something like that, although it would make it really >>> unreadable, and at that point we may not even want to include it in the >>> name. >>> >>> is having something like: m%C3%A1n%C3%A1%C3%B1a in a repo name really >>> helpful? >> >> >> I dunno, I might prefer that if i can get the org and product names to >> be in my native language. >> >> Thoughts? >> >> -- bk >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > Do we really need to be storing the repository name in Pulp? Why not > generate some unique identifier? > > I would think all that matters is some way to connect the Katello > repository model to the Pulp via some sort of identifier so that we can > retrieve the information we need about it. And then store the user > defined "name" in Katello. The assumption has been that since the url structure is: $ORG/$ENV/$PRODUCT/$REPOPATH that it makes sense to have them be human readable based off of the name. I am fine with carrying a seperae field which is the ASCII_FRIENDLY version of the name. But, I think we want to show in hte UI the i18n version of the name. -- bk From ewoud+katello at kohlvanwijngaarden.nl Tue Jun 26 16:21:32 2012 From: ewoud+katello at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Tue, 26 Jun 2012 18:21:32 +0200 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FE9D6BA.6010402@redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> <4FE9D17D.3020203@redhat.com> <4FE9D221.8050606@redhat.com> <4FE9D60C.9010101@redhat.com> <4FE9D6BA.6010402@redhat.com> Message-ID: <20120626162132.GK28104@bogey.xentower.nl> On Tue, Jun 26, 2012 at 11:35:22AM -0400, Bryan Kearney wrote: > On 06/26/2012 11:32 AM, Eric Helms wrote: > >On 06/26/2012 11:15 AM, Bryan Kearney wrote: > >>On 06/26/2012 11:13 AM, Justin Sherrill wrote: > >>>On 06/26/2012 10:52 AM, Bryan Kearney wrote: > >>>>On 06/26/2012 10:48 AM, Og Maciel wrote: > >>>>>It all started with this Bz i filed this morning: > >>>>>https://bugzilla.redhat.com/show_bug.cgi?id=835586 > >>>>> > >>>>>Then Preethi pointed me to > >>>>>https://bugzilla.redhat.com/show_bug.cgi?id=817914 > >>>>> > >>>>>Which then pointed to my discussion in #pulp which can be seen (most > >>>>>of it) here: https://bugzilla.redhat.com/show_bug.cgi?id=835586#c3 > >>>>> > >>>>>The bottom line: are we going to disallow users from creating i18n > >>>>>organizations now??? > >>>>> > >>>>Can we urlencode the i18n characters and have it JustWork(tm)? That > >>>>seems like a much friendlier model. > >>> > >>>We could do something like that, although it would make it really > >>>unreadable, and at that point we may not even want to include it in the > >>>name. > >>> > >>>is having something like: m%C3%A1n%C3%A1%C3%B1a in a repo name really > >>>helpful? > >> > >> > >>I dunno, I might prefer that if i can get the org and product names to > >>be in my native language. > >> > >>Thoughts? > >> > >Do we really need to be storing the repository name in Pulp? Why not > >generate some unique identifier? > > > >I would think all that matters is some way to connect the Katello > >repository model to the Pulp via some sort of identifier so that we can > >retrieve the information we need about it. And then store the user > >defined "name" in Katello. > > The assumption has been that since the url structure is: > > $ORG/$ENV/$PRODUCT/$REPOPATH > > that it makes sense to have them be human readable based off of the > name. I am fine with carrying a seperae field which is the > ASCII_FRIENDLY version of the name. But, I think we want to show in > hte UI the i18n version of the name. Why not store a (UU)ID instead? This would make renaming organizations easier and I think it's not that uncommon. It would make pulp harder to use as standalone because it's less readable and I don't know what the limits for names are in pulp, but I do think it's a good idea to use (UU)IDs. From calfonso at redhat.com Tue Jun 26 19:11:58 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Tue, 26 Jun 2012 15:11:58 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration Message-ID: <20120626191158.GA6836@localhost.localdomain> There has been a bit of discussion going on around how we might go about using foreman's ability to do host provisioning with aeolus and katello. I've published some of the notes from the discussions here: http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration The suggested end goal of this integration is: 1) Allow Katello to clone content, create a snapshot of the content (Content View). 2) Generate the data needed for an Oz template and store it with the Foreman HostGroups. 3) Allow Aeolus to provision guests *and* be able to use the Foreman capabilities around post-boot configuration. If there are additional goals to this integration that I've overlooked and you know about them, please respond with your intel. Take a look at the use cases, and feel free to annotate or reply to this thread. - Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From matt.wagner at redhat.com Tue Jun 26 20:32:25 2012 From: matt.wagner at redhat.com (Matt Wagner) Date: Tue, 26 Jun 2012 16:32:25 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <20120626191158.GA6836@localhost.localdomain> References: <20120626191158.GA6836@localhost.localdomain> Message-ID: <20120626203225.GB20977@mawagner-desktop.usersys.redhat.com> On Tue, Jun 26, 2012 at 03:11:58PM -0400, Chris Alfonso wrote: > There has been a bit of discussion going on around how we might go about using foreman's ability to do host provisioning with aeolus and katello. I've published some of the notes from the discussions here: > http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary > http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration > > The suggested end goal of this integration is: > 1) Allow Katello to clone content, create a snapshot of the content (Content View). > 2) Generate the data needed for an Oz template and store it with the Foreman HostGroups. > 3) Allow Aeolus to provision guests *and* be able to use the Foreman capabilities around post-boot configuration. > > If there are additional goals to this integration that I've overlooked and you know about them, please respond with your intel. Take a look at the use cases, and feel free to annotate or reply to this thread. I should mention that I recently sent some patches that extend aeolus-image-rubygem to include support for the Katello API[1]. Incidentally, it still needs review. (Though it's been suggested that I should spin it out into its own gem, too.) Though I must confess that, despite this, I still don't have a solid understanding of all of the terminology that Katello and family use. So I'm still wrapping my head around some of the implications of what is described. I'm interested in exactly how Aeolus fits into the picture here. It seems like it would be nice if you could get this to be an integrated flow between the apps, so that when you move a system to a new environment or associate it with a different content view, Aeolus can make that happen. I'm not positive how they would fit together. Perhaps a more loaded question, but what does using Foreman for post-boot config mean for Audrey, which is what we're using today? -- Matt [1] http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-June/010723.html From bkearney at redhat.com Tue Jun 26 20:39:19 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 26 Jun 2012 16:39:19 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <20120626191158.GA6836@localhost.localdomain> References: <20120626191158.GA6836@localhost.localdomain> Message-ID: <4FEA1DF7.5000301@redhat.com> On 06/26/2012 03:11 PM, Chris Alfonso wrote: > There has been a bit of discussion going on around how we might go about > using foreman's ability to do host provisioning with aeolus and > katello. I've published some of the notes from the discussions here: > http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary > > http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration > > > The suggested end goal of this integration is: > 1) Allow Katello to clone content, create a snapshot of the content > (Content View). > 2) Generate the data needed for an Oz template and store it with the > Foreman HostGroups. If this could be a Publish from Katello, or a Pull from Aeolus it would be great. a > 3) Allow Aeolus to provision guests *and* be able to use the Foreman > capabilities around post-boot configuration. > > If there are additional goals to this integration that I've overlooked > and you know about them, please respond with your intel. Take a look at > the use cases, and feel free to annotate or reply to this thread. And to allow Foreman to use the same language (Template/Host group) to proivision Bare metal and send it to Aeolus to create images. -- bk From bkearney at redhat.com Tue Jun 26 20:41:23 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 26 Jun 2012 16:41:23 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <20120626162132.GK28104@bogey.xentower.nl> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> <4FE9D17D.3020203@redhat.com> <4FE9D221.8050606@redhat.com> <4FE9D60C.9010101@redhat.com> <4FE9D6BA.6010402@redhat.com> <20120626162132.GK28104@bogey.xentower.nl> Message-ID: <4FEA1E73.3080605@redhat.com> On 06/26/2012 12:21 PM, Ewoud Kohl van Wijngaarden wrote: > On Tue, Jun 26, 2012 at 11:35:22AM -0400, Bryan Kearney wrote: >> On 06/26/2012 11:32 AM, Eric Helms wrote: >>> On 06/26/2012 11:15 AM, Bryan Kearney wrote: >>>> On 06/26/2012 11:13 AM, Justin Sherrill wrote: >>>>> On 06/26/2012 10:52 AM, Bryan Kearney wrote: >>>>>> On 06/26/2012 10:48 AM, Og Maciel wrote: >>>>>>> It all started with this Bz i filed this morning: >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=835586 >>>>>>> >>>>>>> Then Preethi pointed me to >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=817914 >>>>>>> >>>>>>> Which then pointed to my discussion in #pulp which can be seen (most >>>>>>> of it) here: https://bugzilla.redhat.com/show_bug.cgi?id=835586#c3 >>>>>>> >>>>>>> The bottom line: are we going to disallow users from creating i18n >>>>>>> organizations now??? >>>>>>> >>>>>> Can we urlencode the i18n characters and have it JustWork(tm)? That >>>>>> seems like a much friendlier model. >>>>> >>>>> We could do something like that, although it would make it really >>>>> unreadable, and at that point we may not even want to include it in the >>>>> name. >>>>> >>>>> is having something like: m%C3%A1n%C3%A1%C3%B1a in a repo name really >>>>> helpful? >>>> >>>> >>>> I dunno, I might prefer that if i can get the org and product names to >>>> be in my native language. >>>> >>>> Thoughts? >>>> >>> Do we really need to be storing the repository name in Pulp? Why not >>> generate some unique identifier? >>> >>> I would think all that matters is some way to connect the Katello >>> repository model to the Pulp via some sort of identifier so that we can >>> retrieve the information we need about it. And then store the user >>> defined "name" in Katello. >> >> The assumption has been that since the url structure is: >> >> $ORG/$ENV/$PRODUCT/$REPOPATH >> >> that it makes sense to have them be human readable based off of the >> name. I am fine with carrying a seperae field which is the >> ASCII_FRIENDLY version of the name. But, I think we want to show in >> hte UI the i18n version of the name. > > Why not store a (UU)ID instead? This would make renaming organizations > easier and I think it's not that uncommon. It would make pulp harder to > use as standalone because it's less readable and I don't know what the > limits for names are in pulp, but I do think it's a good idea to use > (UU)IDs. The feedback we got was that we should try to make the repo urls should be human readible. If you are looking at a machine and the url is; /3232/43432/42432432/SOME URL then it may not be easy to understand what the machien will get. -- bk From bkearney at redhat.com Tue Jun 26 20:43:22 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 26 Jun 2012 16:43:22 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <20120626203225.GB20977@mawagner-desktop.usersys.redhat.com> References: <20120626191158.GA6836@localhost.localdomain> <20120626203225.GB20977@mawagner-desktop.usersys.redhat.com> Message-ID: <4FEA1EEA.4080307@redhat.com> On 06/26/2012 04:32 PM, Matt Wagner wrote: > On Tue, Jun 26, 2012 at 03:11:58PM -0400, Chris Alfonso wrote: >> There has been a bit of discussion going on around how we might go about using foreman's ability to do host provisioning with aeolus and katello. I've published some of the notes from the discussions here: >> http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary >> http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration >> >> The suggested end goal of this integration is: >> 1) Allow Katello to clone content, create a snapshot of the content (Content View). >> 2) Generate the data needed for an Oz template and store it with the Foreman HostGroups. >> 3) Allow Aeolus to provision guests *and* be able to use the Foreman capabilities around post-boot configuration. >> >> If there are additional goals to this integration that I've overlooked and you know about them, please respond with your intel. Take a look at the use cases, and feel free to annotate or reply to this thread. > > I should mention that I recently sent some patches that extend > aeolus-image-rubygem to include support for the Katello API[1]. > Incidentally, it still needs review. (Though it's been suggested that I > should spin it out into its own gem, too.) > > Though I must confess that, despite this, I still don't have a solid > understanding of all of the terminology that Katello and family use. So > I'm still wrapping my head around some of the implications of what is > described. What verbiage is causing issues? -- bk From matt.wagner at redhat.com Tue Jun 26 21:03:04 2012 From: matt.wagner at redhat.com (Matt Wagner) Date: Tue, 26 Jun 2012 17:03:04 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <4FEA1EEA.4080307@redhat.com> References: <20120626191158.GA6836@localhost.localdomain> <20120626203225.GB20977@mawagner-desktop.usersys.redhat.com> <4FEA1EEA.4080307@redhat.com> Message-ID: <20120626210304.GA23038@mawagner-desktop.usersys.redhat.com> On Tue, Jun 26, 2012 at 04:43:22PM -0400, Bryan Kearney wrote: > On 06/26/2012 04:32 PM, Matt Wagner wrote: > > > >Though I must confess that, despite this, I still don't have a solid > >understanding of all of the terminology that Katello and family use. So > >I'm still wrapping my head around some of the implications of what is > >described. > > What verbiage is causing issues? Sorry, I think my wording might have been ambiguous. (Which is ironic given the context.) What I meant wasn't an issue with verbiage per se, as much as disclaiming that my brain was still absorbing some of the concepts here that are relatively unfamiliar to me. (Environments, products, content views, libraries...) They all make sense, it's just that the connections between things are still forming in my brain -- so if I say something in-thread that makes no sense, please forgive me. ;) -- Matt From bkearney at redhat.com Tue Jun 26 22:44:56 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 26 Jun 2012 18:44:56 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <20120626210304.GA23038@mawagner-desktop.usersys.redhat.com> References: <20120626191158.GA6836@localhost.localdomain> <20120626203225.GB20977@mawagner-desktop.usersys.redhat.com> <4FEA1EEA.4080307@redhat.com> <20120626210304.GA23038@mawagner-desktop.usersys.redhat.com> Message-ID: <4FEA3B68.1040507@redhat.com> On 06/26/2012 05:03 PM, Matt Wagner wrote: > On Tue, Jun 26, 2012 at 04:43:22PM -0400, Bryan Kearney wrote: >> On 06/26/2012 04:32 PM, Matt Wagner wrote: >>> >>> Though I must confess that, despite this, I still don't have a solid >>> understanding of all of the terminology that Katello and family use. So >>> I'm still wrapping my head around some of the implications of what is >>> described. >> >> What verbiage is causing issues? > > Sorry, I think my wording might have been ambiguous. (Which is ironic > given the context.) What I meant wasn't an issue with verbiage per se, > as much as disclaiming that my brain was still absorbing some of the > concepts here that are relatively unfamiliar to me. (Environments, > products, content views, libraries...) They all make sense, it's just > that the connections between things are still forming in my brain -- so > if I say something in-thread that makes no sense, please forgive me. ;) No issues... I know our stuff is obtuse. Last I heard, Environments (Think moving your apps from Dev then Test then Production) map to clouds. -- bk From ohadlevy at redhat.com Wed Jun 27 06:14:18 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 27 Jun 2012 09:14:18 +0300 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <4FEA0CF0.5040108@redhat.com> References: <20120626191158.GA6836@localhost.localdomain> <4FEA0CF0.5040108@redhat.com> Message-ID: <4FEAA4BA.90209@redhat.com> On 06/26/2012 10:26 PM, Giulio Fidente wrote: > On 06/26/2012 09:11 PM, Chris Alfonso wrote: >> There has been a bit of discussion going on around how we might go >> about using foreman's ability to do host provisioning with aeolus >> and katello. > > not sure it will be of great help but for a GPS engagement we're > currently working on some integration of Foreman and CloudEngine; we > drive both from the rest apis from a customized web frotend interesting, can you provide more info about what is the higher level functionality you are offering? > > we don't need of Foreman provisioning capabilities, so we run it with > the 'unattended' mode disabled > > features we currently use: > > - parameters for hosts (still these are global vars) > - hostgroups (as these are needed to inherit various and different > classes) > > the puppetmaster is autosigning client's certificates; are you sure thats wise? :) > we use audrey to set the puppet-agent environment at launch time > > at launch time we POST (via foreman rest api) a new host into puppet, > also setting its environment, hostgroup and passing to some host > parameters, reused by the puppet classes > > puppet environments/classes/hostgroups definitions on the puppetmaster > are managed by their ITops > > this allows the customer for a completely independent management of > the puppet/foreman stuff while giving cloud users a chance to 'use' > those services interesting, did you see the EC2 support we have in foreman? do you have any idea how would that complement (if at all) your needs? Ohad From ohadlevy at redhat.com Wed Jun 27 06:18:22 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 27 Jun 2012 09:18:22 +0300 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <20120626191158.GA6836@localhost.localdomain> References: <20120626191158.GA6836@localhost.localdomain> Message-ID: <4FEAA5AE.4010102@redhat.com> On 06/26/2012 10:11 PM, Chris Alfonso wrote: > There has been a bit of discussion going on around how we might go about > using foreman's ability to do host provisioning with aeolus and katello. > I've published some of the notes from the discussions here: > http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary > > http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration > > > The suggested end goal of this integration is: > 1) Allow Katello to clone content, create a snapshot of the content > (Content View). > 2) Generate the data needed for an Oz template and store it with the > Foreman HostGroups. > 3) Allow Aeolus to provision guests *and* be able to use the Foreman > capabilities around post-boot configuration. > > If there are additional goals to this integration that I've overlooked > and you know about them, please respond with your intel. Take a look at > the use cases, and feel free to annotate or reply to this thread. One major difference, is the ability to manage the system in the long term as well, so its not really just about launching it, rather managing its configuration for the whole system life cycle. other side benefits, is to manage stuff you need in your enterprise but dont need on a common cloud, things like ip address management, dns, dhcp, automation of puppet certificates, status reporting,inventory auditing etc. Ohad From msuchy at redhat.com Wed Jun 27 08:19:45 2012 From: msuchy at redhat.com (=?ISO-8859-1?Q?Miroslav_Such=FD?=) Date: Wed, 27 Jun 2012 10:19:45 +0200 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <4FEAC221.5000807@redhat.com> On 06/26/2012 04:48 PM, Og Maciel wrote: > It all started with this Bz i filed this morning: https://bugzilla.redhat.com/show_bug.cgi?id=835586 > > Then Preethi pointed me to https://bugzilla.redhat.com/show_bug.cgi?id=817914 > > Which then pointed to my discussion in #pulp which can be seen (most of it) here: https://bugzilla.redhat.com/show_bug.cgi?id=835586#c3 > > The bottom line: are we going to disallow users from creating i18n organizations now??? > Hold on. Can we get status from Pulp? Why Pulp 1.1 will disallow multi-bytes names in repo name in first place? -- Miroslav Suchy Red Hat Satellite Engineering From lzap at redhat.com Wed Jun 27 11:27:53 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 27 Jun 2012 13:27:53 +0200 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FE9D221.8050606@redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> <4FE9D17D.3020203@redhat.com> <4FE9D221.8050606@redhat.com> Message-ID: <20120627112753.GC3693@lzapx.brq.redhat.com> On Tue, Jun 26, 2012 at 11:15:45AM -0400, Bryan Kearney wrote: > I dunno, I might prefer that if i can get the org and product names > to be in my native language. > > Thoughts? > Most of latin (and maybe other groups) characters has "decomposition" pair in the UNICODE. Some years ago, I wrote a Java bit that was converting those into decomposed strings, for all the other characters (Greek, Chinese...) I used hexcode encoding. Example character is LATIN SMALL LETTER A WITH OGONEK: http://www.fileformat.info/info/unicode/char/105/index.htm It's decomposed format is LATIN SMALL LETTER A: http://www.fileformat.info/info/unicode/char/0061/index.htm This works for many languages which use latin characters. With this, we can cover big portion of world to have nice-formatted names. Unfortunately, Chinese does not fit here, but I cannot imagine nice textual encoding for Chinese characters. Example (for those with UTF-8 ready MUAs): repozit??_Luk??_Zapletal -> repozitar_Lukas_Zapletal repo_? -> repo_63A9 It definitely does not solve this, but gives nicer names for those people with latin alphabets :-) -- Later, Lukas "lzap" Zapletal #katello #systemengine From jason.dobies at redhat.com Wed Jun 27 11:54:02 2012 From: jason.dobies at redhat.com (Jay Dobies) Date: Wed, 27 Jun 2012 07:54:02 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <20120627112753.GC3693@lzapx.brq.redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> <4FE9D17D.3020203@redhat.com> <4FE9D221.8050606@redhat.com> <20120627112753.GC3693@lzapx.brq.redhat.com> Message-ID: <4FEAF45A.3090407@redhat.com> > On Tue, Jun 26, 2012 at 11:15:45AM -0400, Bryan Kearney wrote: >> I dunno, I might prefer that if i can get the org and product names >> to be in my native language. That's what the name field is for. The ID is the programmatic way of referring to repositories and isn't intended to be displayed to users. The display name and description have no restrictions and can be in the user's native language. -- Jay Dobies Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org From calfonso at redhat.com Wed Jun 27 12:07:10 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Wed, 27 Jun 2012 08:07:10 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <4FEAA5AE.4010102@redhat.com> References: <20120626191158.GA6836@localhost.localdomain> <4FEAA5AE.4010102@redhat.com> Message-ID: <20120627120710.GA27061@localhost.localdomain> On 27/06/12 09:18 +0300, Ohad Levy wrote: >On 06/26/2012 10:11 PM, Chris Alfonso wrote: >>There has been a bit of discussion going on around how we might go about >>using foreman's ability to do host provisioning with aeolus and katello. >>I've published some of the notes from the discussions here: >>http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary >> >>http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration >> >> >>The suggested end goal of this integration is: >>1) Allow Katello to clone content, create a snapshot of the content >>(Content View). >>2) Generate the data needed for an Oz template and store it with the >>Foreman HostGroups. >>3) Allow Aeolus to provision guests *and* be able to use the Foreman >>capabilities around post-boot configuration. >> >>If there are additional goals to this integration that I've overlooked >>and you know about them, please respond with your intel. Take a look at >>the use cases, and feel free to annotate or reply to this thread. > >One major difference, is the ability to manage the system in the long >term as well, so its not really just about launching it, rather >managing its configuration for the whole system life cycle. > >other side benefits, is to manage stuff you need in your enterprise >but dont need on a common cloud, things like ip address management, >dns, dhcp, automation of puppet certificates, status >reporting,inventory auditing etc. These are core foreman capabilities offered in the latest code base and not necessarily features that will be integrated with katello or conductor. In other words, a user would go directly to foreman to manage these features, correct? - Chris > >Ohad > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From ohadlevy at redhat.com Wed Jun 27 12:45:35 2012 From: ohadlevy at redhat.com (Ohad Levy) Date: Wed, 27 Jun 2012 15:45:35 +0300 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <20120627120710.GA27061@localhost.localdomain> References: <20120626191158.GA6836@localhost.localdomain> <4FEAA5AE.4010102@redhat.com> <20120627120710.GA27061@localhost.localdomain> Message-ID: <4FEB006F.1020500@redhat.com> On 06/27/2012 03:07 PM, Chris Alfonso wrote: > On 27/06/12 09:18 +0300, Ohad Levy wrote: >> On 06/26/2012 10:11 PM, Chris Alfonso wrote: >>> There has been a bit of discussion going on around how we might go about >>> using foreman's ability to do host provisioning with aeolus and katello. >>> I've published some of the notes from the discussions here: >>> http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary >>> >>> >>> http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration >>> >>> >>> >>> The suggested end goal of this integration is: >>> 1) Allow Katello to clone content, create a snapshot of the content >>> (Content View). >>> 2) Generate the data needed for an Oz template and store it with the >>> Foreman HostGroups. >>> 3) Allow Aeolus to provision guests *and* be able to use the Foreman >>> capabilities around post-boot configuration. >>> >>> If there are additional goals to this integration that I've overlooked >>> and you know about them, please respond with your intel. Take a look at >>> the use cases, and feel free to annotate or reply to this thread. >> >> One major difference, is the ability to manage the system in the long >> term as well, so its not really just about launching it, rather >> managing its configuration for the whole system life cycle. >> >> other side benefits, is to manage stuff you need in your enterprise >> but dont need on a common cloud, things like ip address management, >> dns, dhcp, automation of puppet certificates, status >> reporting,inventory auditing etc. > These are core foreman capabilities offered in the latest code base and > not necessarily features that will be integrated with katello or > conductor. In other words, a user would go directly to foreman to manage > these features, correct? While I personally don't mind, I think the goal is that users don't login directly into foreman, rather we expose it via CE/SE. I would expect a lot of these features showing up in Katello, and for the record, you can't easily provision lots of system in rhevm via CE without dns and ip management support ( or at least subnets / networking). Ohad From bkearney at redhat.com Wed Jun 27 12:48:13 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 27 Jun 2012 08:48:13 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FEAF45A.3090407@redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> <4FE9D17D.3020203@redhat.com> <4FE9D221.8050606@redhat.com> <20120627112753.GC3693@lzapx.brq.redhat.com> <4FEAF45A.3090407@redhat.com> Message-ID: <4FEB010D.90900@redhat.com> On 06/27/2012 07:54 AM, Jay Dobies wrote: >> On Tue, Jun 26, 2012 at 11:15:45AM -0400, Bryan Kearney wrote: >>> I dunno, I might prefer that if i can get the org and product names >>> to be in my native language. > > That's what the name field is for. The ID is the programmatic way of > referring to repositories and isn't intended to be displayed to users. > The display name and description have no restrictions and can be in the > user's native language. > But, it gets exposed in the repo name and url in the yum.repos.d file. -- bk From jason.dobies at redhat.com Wed Jun 27 12:51:48 2012 From: jason.dobies at redhat.com (Jay Dobies) Date: Wed, 27 Jun 2012 08:51:48 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FEB010D.90900@redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> <4FE9D17D.3020203@redhat.com> <4FE9D221.8050606@redhat.com> <20120627112753.GC3693@lzapx.brq.redhat.com> <4FEAF45A.3090407@redhat.com> <4FEB010D.90900@redhat.com> Message-ID: <4FEB01E4.3060600@redhat.com> On 06/27/2012 08:48 AM, Bryan Kearney wrote: > On 06/27/2012 07:54 AM, Jay Dobies wrote: >>> On Tue, Jun 26, 2012 at 11:15:45AM -0400, Bryan Kearney wrote: >>>> I dunno, I might prefer that if i can get the org and product names >>>> to be in my native language. >> >> That's what the name field is for. The ID is the programmatic way of >> referring to repositories and isn't intended to be displayed to users. >> The display name and description have no restrictions and can be in the >> user's native language. >> > But, it gets exposed in the repo name and url in the yum.repos.d file. > > -- bk The ID only gets into the URL if you don't specify a relative URL (or a feed in which case we derive it). Yum is actually a big part of the problem. Their repo ID doesn't allow i18n characters, so we ran into issues generating the .repo file for those IDs. So even if we let it happen, yum wouldn't. -- Jay Dobies Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org From bkearney at redhat.com Wed Jun 27 12:53:12 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 27 Jun 2012 08:53:12 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <4FEB006F.1020500@redhat.com> References: <20120626191158.GA6836@localhost.localdomain> <4FEAA5AE.4010102@redhat.com> <20120627120710.GA27061@localhost.localdomain> <4FEB006F.1020500@redhat.com> Message-ID: <4FEB0238.9060208@redhat.com> On 06/27/2012 08:45 AM, Ohad Levy wrote: > On 06/27/2012 03:07 PM, Chris Alfonso wrote: >> On 27/06/12 09:18 +0300, Ohad Levy wrote: >>> On 06/26/2012 10:11 PM, Chris Alfonso wrote: >>>> There has been a bit of discussion going on around how we might go >>>> about >>>> using foreman's ability to do host provisioning with aeolus and >>>> katello. >>>> I've published some of the notes from the discussions here: >>>> http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary >>>> >>>> >>>> >>>> http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration >>>> >>>> >>>> >>>> >>>> The suggested end goal of this integration is: >>>> 1) Allow Katello to clone content, create a snapshot of the content >>>> (Content View). >>>> 2) Generate the data needed for an Oz template and store it with the >>>> Foreman HostGroups. >>>> 3) Allow Aeolus to provision guests *and* be able to use the Foreman >>>> capabilities around post-boot configuration. >>>> >>>> If there are additional goals to this integration that I've overlooked >>>> and you know about them, please respond with your intel. Take a look at >>>> the use cases, and feel free to annotate or reply to this thread. >>> >>> One major difference, is the ability to manage the system in the long >>> term as well, so its not really just about launching it, rather >>> managing its configuration for the whole system life cycle. >>> >>> other side benefits, is to manage stuff you need in your enterprise >>> but dont need on a common cloud, things like ip address management, >>> dns, dhcp, automation of puppet certificates, status >>> reporting,inventory auditing etc. >> These are core foreman capabilities offered in the latest code base and >> not necessarily features that will be integrated with katello or >> conductor. In other words, a user would go directly to foreman to manage >> these features, correct? > > While I personally don't mind, I think the goal is that users don't > login directly into foreman, rather we expose it via CE/SE. > > I would expect a lot of these features showing up in Katello, and for > the record, you can't easily provision lots of system in rhevm via CE > without dns and ip management support ( or at least subnets / networking). Agree... the expectation is that Katello provides a light unification layer over foreman, pulp, and candlepin. I would expect two things: 1) all the heavy lifting is done in foreman 2) the foreman ui also gets any new features we need in katello. This means double effort, but gets the features out to the foreman community for maturity. -- bk From thomasmckay at redhat.com Wed Jun 27 13:30:37 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 27 Jun 2012 09:30:37 -0400 (EDT) Subject: [katello-devel] importing manifests with the "force" flag In-Reply-To: <342426f0-44a3-4e03-baaa-a974bb30c530@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <332e1af3-6a43-4447-842e-76a93a36c702@zmail16.collab.prod.int.phx2.redhat.com> Katello allows an additional flag to be passed to candlepin when importing a manifest: Force. The only case I've seen where this is required is when importing a manifest with a creation date that is earlier than the currently imported manifest. My question: Should this really be allowed? Is a manifest with an earlier date even valid any longer? From dgoodwin at rm-rf.ca Wed Jun 27 13:38:17 2012 From: dgoodwin at rm-rf.ca (Devan Goodwin) Date: Wed, 27 Jun 2012 10:38:17 -0300 Subject: [katello-devel] importing manifests with the "force" flag In-Reply-To: <332e1af3-6a43-4447-842e-76a93a36c702@zmail16.collab.prod.int.phx2.redhat.com> References: <342426f0-44a3-4e03-baaa-a974bb30c530@zmail16.collab.prod.int.phx2.redhat.com> <332e1af3-6a43-4447-842e-76a93a36c702@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: I believe the creation date is the only thing force buys you, and indeed an older manifest should not normally be usable unless something went wrong with the new one. The force flag has kind of run off the rails. It was requested for development purposes if I recall correctly, but there is definitely no reason I can think of it should be allowed for end users. On Wed, Jun 27, 2012 at 10:30 AM, Tom McKay wrote: > > Katello allows an additional flag to be passed to candlepin when importing a manifest: Force. The only case I've seen where this is required is when importing a manifest with a creation date that is earlier than the currently imported manifest. My question: Should this really be allowed? Is a manifest with an earlier date even valid any longer? > _______________________________________________ > candlepin mailing list > candlepin at lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/candlepin From lzap at redhat.com Wed Jun 27 14:11:41 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Wed, 27 Jun 2012 16:11:41 +0200 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FEB01E4.3060600@redhat.com> References: <081da3c6-c8fe-4154-be8f-8294ccc003cf@zmail11.collab.prod.int.phx2.redhat.com> <4FE9CCBF.3000604@redhat.com> <4FE9D17D.3020203@redhat.com> <4FE9D221.8050606@redhat.com> <20120627112753.GC3693@lzapx.brq.redhat.com> <4FEAF45A.3090407@redhat.com> <4FEB010D.90900@redhat.com> <4FEB01E4.3060600@redhat.com> Message-ID: <20120627141141.GF3693@lzapx.brq.redhat.com> Ok and why not to use the "cool" approach (don't know the name of it): ID-anything-you-want-in-ascii I think some blog systems and CMS use this. We could setup Apache2 filter or something that would do the magic of ignoring everything after the first dash character. On the disc, we would only keep IDs, but in yum we could have anything. So it would be: /4-acme-corporation/32-dev/3335-my-cool-repo For untranslatable characters (like Chinese) we would just ignore them. In the simplest format an example with Chinese environment name would end up as: /4-acme-corporation/32/3335-my-cool-repo No problems with renaming: /4-acme-corporation-and-sons/32/3335-blah-blah Thats it. But there's a snag, punster-admins could slip some funny repo URLs in the yum configuration, something like: /4-i-can-insert-whatever-i-want/32/3335-you-fools And that would actually work. It could also confuse squids. But what does NOT confuse http cache... ;-) LZ On Wed, Jun 27, 2012 at 08:51:48AM -0400, Jay Dobies wrote: > On 06/27/2012 08:48 AM, Bryan Kearney wrote: > >On 06/27/2012 07:54 AM, Jay Dobies wrote: > >>>On Tue, Jun 26, 2012 at 11:15:45AM -0400, Bryan Kearney wrote: > >>>>I dunno, I might prefer that if i can get the org and product names > >>>>to be in my native language. > >> > >>That's what the name field is for. The ID is the programmatic way of > >>referring to repositories and isn't intended to be displayed to users. > >>The display name and description have no restrictions and can be in the > >>user's native language. > >> > >But, it gets exposed in the repo name and url in the yum.repos.d file. > > > >-- bk > > The ID only gets into the URL if you don't specify a relative URL > (or a feed in which case we derive it). > > Yum is actually a big part of the problem. Their repo ID doesn't > allow i18n characters, so we ran into issues generating the .repo > file for those IDs. So even if we let it happen, yum wouldn't. > > > -- > Jay Dobies > Freenode: jdob @ #pulp > http://pulpproject.org | http://blog.pulpproject.org > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -- Later, Lukas "lzap" Zapletal #katello #systemengine From omaciel at redhat.com Wed Jun 27 14:16:50 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 27 Jun 2012 10:16:50 -0400 (EDT) Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <20120627141141.GF3693@lzapx.brq.redhat.com> Message-ID: <3337eac9-ee6a-4942-b191-b8adcb44a733@zmail11.collab.prod.int.phx2.redhat.com> To be honest, why can't we use a UID for this? Are we really expecting people to memorize the urls or deliberately type the url following what rails uses as standard practice? Isn't this why we have links in the web ui and bookmarks? Things could be a whole lot simpler if we used UIDs, no? -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From bkearney at redhat.com Wed Jun 27 14:17:30 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 27 Jun 2012 10:17:30 -0400 Subject: [katello-devel] importing manifests with the "force" flag In-Reply-To: References: <342426f0-44a3-4e03-baaa-a974bb30c530@zmail16.collab.prod.int.phx2.redhat.com> <332e1af3-6a43-4447-842e-76a93a36c702@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <4FEB15FA.5090406@redhat.com> On 06/27/2012 09:38 AM, Devan Goodwin wrote: > I believe the creation date is the only thing force buys you, and > indeed an older manifest should not normally be usable unless > something went wrong with the new one. The force flag has kind of run > off the rails. It was requested for development purposes if I recall > correctly, but there is definitely no reason I can think of it should > be allowed for end users. If we turn back on checking the signature, and the checks for type, then it will become relevant again. - bk From jason.dobies at redhat.com Wed Jun 27 14:19:47 2012 From: jason.dobies at redhat.com (Jay Dobies) Date: Wed, 27 Jun 2012 10:19:47 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <3337eac9-ee6a-4942-b191-b8adcb44a733@zmail11.collab.prod.int.phx2.redhat.com> References: <3337eac9-ee6a-4942-b191-b8adcb44a733@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <4FEB1683.20701@redhat.com> On 06/27/2012 10:16 AM, Og Maciel wrote: > To be honest, why can't we use a UID for this? Are we really expecting people to memorize the urls or deliberately type the url following what rails uses as standard practice? Isn't this why we have links in the web ui and bookmarks? Things could be a whole lot simpler if we used UIDs, no? > That was how I pitched the restriction to Todd when I suggested it. Use the display name for pretty UIs and manage your own UID generation under the covers. -- Jay Dobies Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org From bkearney at redhat.com Wed Jun 27 14:20:31 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 27 Jun 2012 10:20:31 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <3337eac9-ee6a-4942-b191-b8adcb44a733@zmail11.collab.prod.int.phx2.redhat.com> References: <3337eac9-ee6a-4942-b191-b8adcb44a733@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <4FEB16AF.7020203@redhat.com> On 06/27/2012 10:16 AM, Og Maciel wrote: > To be honest, why can't we use a UID for this? Are we really expecting people to memorize the urls or deliberately type the url following what rails uses as standard practice? Isn't this why we have links in the web ui and bookmarks? Things could be a whole lot simpler if we used UIDs, no? > No, this is for the contents of your yum.repos file.... not the web ui. -- bk - From omaciel at redhat.com Wed Jun 27 14:22:09 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 27 Jun 2012 10:22:09 -0400 (EDT) Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FEB16AF.7020203@redhat.com> Message-ID: <5de18a5c-a23d-4235-8c2f-55da95d26c66@zmail11.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > No, this is for the contents of your yum.repos file.... not the web > ui. But if people will be managing their system via Katello web ui (cli even), why would they poke at yum.repod.d? -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From bkearney at redhat.com Wed Jun 27 14:23:38 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 27 Jun 2012 10:23:38 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <5de18a5c-a23d-4235-8c2f-55da95d26c66@zmail11.collab.prod.int.phx2.redhat.com> References: <5de18a5c-a23d-4235-8c2f-55da95d26c66@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <4FEB176A.9040107@redhat.com> On 06/27/2012 10:22 AM, Og Maciel wrote: > ----- Original Message ----- >> No, this is for the contents of your yum.repos file.... not the web >> ui. > > But if people will be managing their system via Katello web ui (cli even), why would they poke at yum.repod.d? > I am thinking the sysadmin.. it is nice to see on the box what it should get. If they have to go to the server, it will be less useful. -- bk From thomasmckay at redhat.com Wed Jun 27 14:25:05 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Wed, 27 Jun 2012 10:25:05 -0400 (EDT) Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FEB176A.9040107@redhat.com> Message-ID: <80a1b770-b2c2-4c37-9ff1-6f004c5257a6@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Bryan Kearney" > To: "Og Maciel" > Cc: katello-devel at redhat.com > Sent: Wednesday, June 27, 2012 10:23:38 AM > Subject: Re: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? > > On 06/27/2012 10:22 AM, Og Maciel wrote: > > ----- Original Message ----- > >> No, this is for the contents of your yum.repos file.... not the > >> web > >> ui. > > > > But if people will be managing their system via Katello web ui (cli > > even), why would they poke at yum.repod.d? > > > I am thinking the sysadmin.. it is nice to see on the box what it > should > get. If they have to go to the server, it will be less useful. But can't the name and description be inserted into the redhat.repo file generated? Why read the URL if it is described already in your language of choice? > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jbowes at redhat.com Wed Jun 27 14:28:05 2012 From: jbowes at redhat.com (James Bowes) Date: Wed, 27 Jun 2012 11:28:05 -0300 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FEB1683.20701@redhat.com> References: <3337eac9-ee6a-4942-b191-b8adcb44a733@zmail11.collab.prod.int.phx2.redhat.com> <4FEB1683.20701@redhat.com> Message-ID: <20120627142804.GB4286@pipboy.redhat.com> On Wed, Jun 27, 2012 at 10:19:47AM -0400, Jay Dobies wrote: > On 06/27/2012 10:16 AM, Og Maciel wrote: > >To be honest, why can't we use a UID for this? Are we really expecting people to memorize the urls or deliberately type the url following what rails uses as standard practice? Isn't this why we have links in the web ui and bookmarks? Things could be a whole lot simpler if we used UIDs, no? > > > > That was how I pitched the restriction to Todd when I suggested it. > Use the display name for pretty UIs and manage your own UID > generation under the covers. > I'm a big fan of having short usable repo ids in the yum repos file, and in the urls. It really helps for debugging problems. If someone can document the list of allowed characters, maybe katello can include some logic to map the characters in a name to something that's somewhat equivalent in a-z. Drop accents, etc. then just append a unique number to the end, if needed. Or alternatively, let the user set the id for a repo, but autopopulate that field in katello with a best guess. > -- > Jay Dobies > Freenode: jdob @ #pulp > http://pulpproject.org | http://blog.pulpproject.org > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -James -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From omaciel at redhat.com Wed Jun 27 14:28:48 2012 From: omaciel at redhat.com (Og Maciel) Date: Wed, 27 Jun 2012 10:28:48 -0400 (EDT) Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FEB176A.9040107@redhat.com> Message-ID: > I am thinking the sysadmin.. it is nice to see on the box what it > should > get. If they have to go to the server, it will be less useful. What are our best practices? Shouldn't sysadmin also be using the tool itself? i.e. log to katello -- Og Maciel Senior QA Engineer Red Hat, Inc. +1.919.754.4782 irc: omaciel From jason.dobies at redhat.com Wed Jun 27 14:29:05 2012 From: jason.dobies at redhat.com (Jay Dobies) Date: Wed, 27 Jun 2012 10:29:05 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <4FEB16AF.7020203@redhat.com> References: <3337eac9-ee6a-4942-b191-b8adcb44a733@zmail11.collab.prod.int.phx2.redhat.com> <4FEB16AF.7020203@redhat.com> Message-ID: <4FEB18B1.6030701@redhat.com> On 06/27/2012 10:20 AM, Bryan Kearney wrote: > On 06/27/2012 10:16 AM, Og Maciel wrote: >> To be honest, why can't we use a UID for this? Are we really expecting >> people to memorize the urls or deliberately type the url following >> what rails uses as standard practice? Isn't this why we have links in >> the web ui and bookmarks? Things could be a whole lot simpler if we >> used UIDs, no? >> > No, this is for the contents of your yum.repos file.... not the web ui. > > -- bk Doesn't the same thing apply? The header in the [] will be a UID but you can have "name" in there which, to my knowledge, doesn't have the same limitation in yum as the ID does. -- Jay Dobies Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org From jason.dobies at redhat.com Wed Jun 27 14:30:27 2012 From: jason.dobies at redhat.com (Jay Dobies) Date: Wed, 27 Jun 2012 10:30:27 -0400 Subject: [katello-devel] pulp 1.1 will disallow i18n names for repos... what does that mean for Katello??? In-Reply-To: <20120627142804.GB4286@pipboy.redhat.com> References: <3337eac9-ee6a-4942-b191-b8adcb44a733@zmail11.collab.prod.int.phx2.redhat.com> <4FEB1683.20701@redhat.com> <20120627142804.GB4286@pipboy.redhat.com> Message-ID: <4FEB1903.8070300@redhat.com> > I'm a big fan of having short usable repo ids in the yum repos file, and in > the urls. It really helps for debugging problems. If someone can > document the list of allowed characters, ^[\-_A-Za-z0-9]+$ maybe katello can include some > logic to map the characters in a name to something that's somewhat > equivalent in a-z. Drop accents, etc. then just append a unique number > to the end, if needed. Or alternatively, let the user set the id for a > repo, but autopopulate that field in katello with a best guess. > >> -- >> Jay Dobies >> Freenode: jdob @ #pulp >> http://pulpproject.org | http://blog.pulpproject.org >> >> >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > -James > -- Jay Dobies Freenode: jdob @ #pulp http://pulpproject.org | http://blog.pulpproject.org From calfonso at redhat.com Wed Jun 27 14:38:14 2012 From: calfonso at redhat.com (Chris Alfonso) Date: Wed, 27 Jun 2012 10:38:14 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <4FEB0238.9060208@redhat.com> References: <20120626191158.GA6836@localhost.localdomain> <4FEAA5AE.4010102@redhat.com> <20120627120710.GA27061@localhost.localdomain> <4FEB006F.1020500@redhat.com> <4FEB0238.9060208@redhat.com> Message-ID: <20120627143814.GC27061@localhost.localdomain> On 27/06/12 08:53 -0400, Bryan Kearney wrote: >On 06/27/2012 08:45 AM, Ohad Levy wrote: >>On 06/27/2012 03:07 PM, Chris Alfonso wrote: >>>On 27/06/12 09:18 +0300, Ohad Levy wrote: >>>>On 06/26/2012 10:11 PM, Chris Alfonso wrote: >>>>>There has been a bit of discussion going on around how we might go >>>>>about >>>>>using foreman's ability to do host provisioning with aeolus and >>>>>katello. >>>>>I've published some of the notes from the discussions here: >>>>>http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary >>>>> >>>>> >>>>> >>>>>http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration >>>>> >>>>> >>>>> >>>>> >>>>>The suggested end goal of this integration is: >>>>>1) Allow Katello to clone content, create a snapshot of the content >>>>>(Content View). >>>>>2) Generate the data needed for an Oz template and store it with the >>>>>Foreman HostGroups. >>>>>3) Allow Aeolus to provision guests *and* be able to use the Foreman >>>>>capabilities around post-boot configuration. >>>>> >>>>>If there are additional goals to this integration that I've overlooked >>>>>and you know about them, please respond with your intel. Take a look at >>>>>the use cases, and feel free to annotate or reply to this thread. >>>> >>>>One major difference, is the ability to manage the system in the long >>>>term as well, so its not really just about launching it, rather >>>>managing its configuration for the whole system life cycle. >>>> >>>>other side benefits, is to manage stuff you need in your enterprise >>>>but dont need on a common cloud, things like ip address management, >>>>dns, dhcp, automation of puppet certificates, status >>>>reporting,inventory auditing etc. >>>These are core foreman capabilities offered in the latest code base and >>>not necessarily features that will be integrated with katello or >>>conductor. In other words, a user would go directly to foreman to manage >>>these features, correct? >> >>While I personally don't mind, I think the goal is that users don't >>login directly into foreman, rather we expose it via CE/SE. >> >>I would expect a lot of these features showing up in Katello, and for >>the record, you can't easily provision lots of system in rhevm via CE >>without dns and ip management support ( or at least subnets / networking). > >Agree... the expectation is that Katello provides a light unification >layer over foreman, pulp, and candlepin. I would expect two things: > >1) all the heavy lifting is done in foreman >2) the foreman ui also gets any new features we need in katello. This >means double effort, but gets the features out to the foreman >community for maturity. > >-- bk Do you guys think it's necessary to have Foreman run on the same server as Katello? If so, I think we would have to merge the ssl setup and get the two projects on the same gem versions. Not sure if this is already worked out or if you think running on the same server is out of scope for the integration. Would there always be a 1-1 integration between Katello and Foreman? Or is there some other grand vision for an HA architecture? - Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From dgoodwin at rm-rf.ca Wed Jun 27 14:44:44 2012 From: dgoodwin at rm-rf.ca (Devan Goodwin) Date: Wed, 27 Jun 2012 11:44:44 -0300 Subject: [katello-devel] importing manifests with the "force" flag In-Reply-To: <4FEB15FA.5090406@redhat.com> References: <342426f0-44a3-4e03-baaa-a974bb30c530@zmail16.collab.prod.int.phx2.redhat.com> <332e1af3-6a43-4447-842e-76a93a36c702@zmail16.collab.prod.int.phx2.redhat.com> <4FEB15FA.5090406@redhat.com> Message-ID: On Wed, Jun 27, 2012 at 11:17 AM, Bryan Kearney wrote: > On 06/27/2012 09:38 AM, Devan Goodwin wrote: >> >> I believe the creation date is the only thing force buys you, and >> indeed an older manifest should not normally be usable unless >> something went wrong with the new one. The force flag has kind of run >> off the rails. It was requested for development purposes if I recall >> correctly, but there is definitely no reason I can think of it should >> be allowed for end users. > > > If we turn back on checking the signature, and the checks for type, then it > will become relevant again. > > - bk > What's the use case where an end user would want to bypass date checking? Same question for bypassing signature checking. (that one is even more scary to me, what on earth would someone be doing to need that?) :) Seems to me that force should be hidden from view, and possibly not be there at all. From bkearney at redhat.com Wed Jun 27 14:48:40 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 27 Jun 2012 10:48:40 -0400 Subject: [katello-devel] importing manifests with the "force" flag In-Reply-To: References: <342426f0-44a3-4e03-baaa-a974bb30c530@zmail16.collab.prod.int.phx2.redhat.com> <332e1af3-6a43-4447-842e-76a93a36c702@zmail16.collab.prod.int.phx2.redhat.com> <4FEB15FA.5090406@redhat.com> Message-ID: <4FEB1D48.3020806@redhat.com> On 06/27/2012 10:44 AM, Devan Goodwin wrote: > On Wed, Jun 27, 2012 at 11:17 AM, Bryan Kearney wrote: >> On 06/27/2012 09:38 AM, Devan Goodwin wrote: >>> >>> I believe the creation date is the only thing force buys you, and >>> indeed an older manifest should not normally be usable unless >>> something went wrong with the new one. The force flag has kind of run >>> off the rails. It was requested for development purposes if I recall >>> correctly, but there is definitely no reason I can think of it should >>> be allowed for end users. >> >> >> If we turn back on checking the signature, and the checks for type, then it >> will become relevant again. >> >> - bk >> > > What's the use case where an end user would want to bypass date checking? I download the wrong manifest, and need to restore to the last one i downloaded? > > Same question for bypassing signature checking. (that one is even more > scary to me, what on earth would someone be doing to need that?) :) Consultants who hack stuff. > > Seems to me that force should be hidden from view, and possibly not be > there at all. > I am fine to bury this in the CLI. That allows us to have it for advanced users. -- bk From bkearney at redhat.com Wed Jun 27 14:52:07 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 27 Jun 2012 10:52:07 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <20120627143814.GC27061@localhost.localdomain> References: <20120626191158.GA6836@localhost.localdomain> <4FEAA5AE.4010102@redhat.com> <20120627120710.GA27061@localhost.localdomain> <4FEB006F.1020500@redhat.com> <4FEB0238.9060208@redhat.com> <20120627143814.GC27061@localhost.localdomain> Message-ID: <4FEB1E17.4020804@redhat.com> On 06/27/2012 10:38 AM, Chris Alfonso wrote: > On 27/06/12 08:53 -0400, Bryan Kearney wrote: >> On 06/27/2012 08:45 AM, Ohad Levy wrote: >>> On 06/27/2012 03:07 PM, Chris Alfonso wrote: >>>> On 27/06/12 09:18 +0300, Ohad Levy wrote: >>>>> On 06/26/2012 10:11 PM, Chris Alfonso wrote: >>>>>> There has been a bit of discussion going on around how we might go >>>>>> about >>>>>> using foreman's ability to do host provisioning with aeolus and >>>>>> katello. >>>>>> I've published some of the notes from the discussions here: >>>>>> http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The suggested end goal of this integration is: >>>>>> 1) Allow Katello to clone content, create a snapshot of the content >>>>>> (Content View). >>>>>> 2) Generate the data needed for an Oz template and store it with the >>>>>> Foreman HostGroups. >>>>>> 3) Allow Aeolus to provision guests *and* be able to use the Foreman >>>>>> capabilities around post-boot configuration. >>>>>> >>>>>> If there are additional goals to this integration that I've >>>>>> overlooked >>>>>> and you know about them, please respond with your intel. Take a >>>>>> look at >>>>>> the use cases, and feel free to annotate or reply to this thread. >>>>> >>>>> One major difference, is the ability to manage the system in the long >>>>> term as well, so its not really just about launching it, rather >>>>> managing its configuration for the whole system life cycle. >>>>> >>>>> other side benefits, is to manage stuff you need in your enterprise >>>>> but dont need on a common cloud, things like ip address management, >>>>> dns, dhcp, automation of puppet certificates, status >>>>> reporting,inventory auditing etc. >>>> These are core foreman capabilities offered in the latest code base and >>>> not necessarily features that will be integrated with katello or >>>> conductor. In other words, a user would go directly to foreman to >>>> manage >>>> these features, correct? >>> >>> While I personally don't mind, I think the goal is that users don't >>> login directly into foreman, rather we expose it via CE/SE. >>> >>> I would expect a lot of these features showing up in Katello, and for >>> the record, you can't easily provision lots of system in rhevm via CE >>> without dns and ip management support ( or at least subnets / >>> networking). >> >> Agree... the expectation is that Katello provides a light unification >> layer over foreman, pulp, and candlepin. I would expect two things: >> >> 1) all the heavy lifting is done in foreman >> 2) the foreman ui also gets any new features we need in katello. This >> means double effort, but gets the features out to the foreman >> community for maturity. >> >> -- bk > > Do you guys think it's necessary to have Foreman run on the same server > as Katello? If so, I think we would have to merge the ssl setup and get > the two projects on the same gem versions. Not sure if this is already > worked out or if you think running on the same server is out of scope > for the integration. Would there always be a 1-1 integration between > Katello and Foreman? Or is there some other grand vision for an HA > architecture? Like the other libraries, I think we want them on the same machine and on uniquee machines. I think we need to do another effort to get Katello, Aeolus, and Foreman on the same stack. I have heard we want to look to 1.9.3 and, Rails 3.0, and a common gem sack. -- bk From jbowes at redhat.com Wed Jun 27 14:52:01 2012 From: jbowes at redhat.com (James Bowes) Date: Wed, 27 Jun 2012 11:52:01 -0300 Subject: [katello-devel] importing manifests with the "force" flag In-Reply-To: References: <342426f0-44a3-4e03-baaa-a974bb30c530@zmail16.collab.prod.int.phx2.redhat.com> <332e1af3-6a43-4447-842e-76a93a36c702@zmail16.collab.prod.int.phx2.redhat.com> <4FEB15FA.5090406@redhat.com> Message-ID: <20120627145201.GC4286@pipboy.redhat.com> On Wed, Jun 27, 2012 at 11:44:44AM -0300, Devan Goodwin wrote: > On Wed, Jun 27, 2012 at 11:17 AM, Bryan Kearney wrote: > > On 06/27/2012 09:38 AM, Devan Goodwin wrote: > >> > >> I believe the creation date is the only thing force buys you, and > >> indeed an older manifest should not normally be usable unless > >> something went wrong with the new one. The force flag has kind of run > >> off the rails. It was requested for development purposes if I recall > >> correctly, but there is definitely no reason I can think of it should > >> be allowed for end users. > > > > > > If we turn back on checking the signature, and the checks for type, then it > > will become relevant again. > > > > - bk > > > > What's the use case where an end user would want to bypass date checking? > > Same question for bypassing signature checking. (that one is even more > scary to me, what on earth would someone be doing to need that?) :) > > Seems to me that force should be hidden from view, and possibly not be > there at all. > I've long been trying to get that option out of the ui. There's few cases where a non developer can use it and it won't end up hurting them. It should be available as an advanced cli option, wrapped in nice warnings, and only used when something catastrophic has happened, and you need to roll back to an old version. I'd prefer sig checking to just be a config option, but if we wanted it to be tweakable at run time, it should be a seperate option, so you can roll back to and older manifest version, but still verify its integrity. > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel -James -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bkearney at redhat.com Wed Jun 27 14:57:23 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 27 Jun 2012 10:57:23 -0400 Subject: [katello-devel] importing manifests with the "force" flag In-Reply-To: <20120627145201.GC4286@pipboy.redhat.com> References: <342426f0-44a3-4e03-baaa-a974bb30c530@zmail16.collab.prod.int.phx2.redhat.com> <332e1af3-6a43-4447-842e-76a93a36c702@zmail16.collab.prod.int.phx2.redhat.com> <4FEB15FA.5090406@redhat.com> <20120627145201.GC4286@pipboy.redhat.com> Message-ID: <4FEB1F53.7060406@redhat.com> On 06/27/2012 10:52 AM, James Bowes wrote: > On Wed, Jun 27, 2012 at 11:44:44AM -0300, Devan Goodwin wrote: >> On Wed, Jun 27, 2012 at 11:17 AM, Bryan Kearney wrote: >>> On 06/27/2012 09:38 AM, Devan Goodwin wrote: >>>> >>>> I believe the creation date is the only thing force buys you, and >>>> indeed an older manifest should not normally be usable unless >>>> something went wrong with the new one. The force flag has kind of run >>>> off the rails. It was requested for development purposes if I recall >>>> correctly, but there is definitely no reason I can think of it should >>>> be allowed for end users. >>> >>> >>> If we turn back on checking the signature, and the checks for type, then it >>> will become relevant again. >>> >>> - bk >>> >> >> What's the use case where an end user would want to bypass date checking? >> >> Same question for bypassing signature checking. (that one is even more >> scary to me, what on earth would someone be doing to need that?) :) >> >> Seems to me that force should be hidden from view, and possibly not be >> there at all. >> > > I've long been trying to get that option out of the ui. There's few > cases where a non developer can use it and it won't end up hurting them. > > It should be available as an advanced cli option, wrapped in nice > warnings, and only used when something catastrophic has happened, and > you need to roll back to an old version. > > I'd prefer sig checking to just be a config option, but if we wanted it > to be tweakable at run time, it should be a seperate option, so you can > roll back to and older manifest version, but still verify its integrity. > >> _______________________________________________ >> katello-devel mailing list >> katello-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/katello-devel > > -James > ok.. added to the backlog: As a user, i would like the Force flag removed from the UI but kept in the CLI for manifest uploads so that I can not hurt myself accidently. -- bk From hbrock at redhat.com Wed Jun 27 15:53:20 2012 From: hbrock at redhat.com (Hugh Brock) Date: Wed, 27 Jun 2012 11:53:20 -0400 Subject: [katello-devel] Katello-Foreman-Aeolus Integration In-Reply-To: <4FEB1E17.4020804@redhat.com> References: <20120626191158.GA6836@localhost.localdomain> <4FEAA5AE.4010102@redhat.com> <20120627120710.GA27061@localhost.localdomain> <4FEB006F.1020500@redhat.com> <4FEB0238.9060208@redhat.com> <20120627143814.GC27061@localhost.localdomain> <4FEB1E17.4020804@redhat.com> Message-ID: <20120627155320.GA3573@redhat.com> On Wed, Jun 27, 2012 at 10:52:07AM -0400, Bryan Kearney wrote: > On 06/27/2012 10:38 AM, Chris Alfonso wrote: > >On 27/06/12 08:53 -0400, Bryan Kearney wrote: > >>On 06/27/2012 08:45 AM, Ohad Levy wrote: > >>>On 06/27/2012 03:07 PM, Chris Alfonso wrote: > >>>>On 27/06/12 09:18 +0300, Ohad Levy wrote: > >>>>>On 06/26/2012 10:11 PM, Chris Alfonso wrote: > >>>>>>There has been a bit of discussion going on around how we might go > >>>>>>about > >>>>>>using foreman's ability to do host provisioning with aeolus and > >>>>>>katello. > >>>>>>I've published some of the notes from the discussions here: > >>>>>>http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration-Summary > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integration > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>The suggested end goal of this integration is: > >>>>>>1) Allow Katello to clone content, create a snapshot of the content > >>>>>>(Content View). > >>>>>>2) Generate the data needed for an Oz template and store it with the > >>>>>>Foreman HostGroups. > >>>>>>3) Allow Aeolus to provision guests *and* be able to use the Foreman > >>>>>>capabilities around post-boot configuration. > >>>>>> > >>>>>>If there are additional goals to this integration that I've > >>>>>>overlooked > >>>>>>and you know about them, please respond with your intel. Take a > >>>>>>look at > >>>>>>the use cases, and feel free to annotate or reply to this thread. > >>>>> > >>>>>One major difference, is the ability to manage the system in the long > >>>>>term as well, so its not really just about launching it, rather > >>>>>managing its configuration for the whole system life cycle. > >>>>> > >>>>>other side benefits, is to manage stuff you need in your enterprise > >>>>>but dont need on a common cloud, things like ip address management, > >>>>>dns, dhcp, automation of puppet certificates, status > >>>>>reporting,inventory auditing etc. > >>>>These are core foreman capabilities offered in the latest code base and > >>>>not necessarily features that will be integrated with katello or > >>>>conductor. In other words, a user would go directly to foreman to > >>>>manage > >>>>these features, correct? > >>> > >>>While I personally don't mind, I think the goal is that users don't > >>>login directly into foreman, rather we expose it via CE/SE. > >>> > >>>I would expect a lot of these features showing up in Katello, and for > >>>the record, you can't easily provision lots of system in rhevm via CE > >>>without dns and ip management support ( or at least subnets / > >>>networking). > >> > >>Agree... the expectation is that Katello provides a light unification > >>layer over foreman, pulp, and candlepin. I would expect two things: > >> > >>1) all the heavy lifting is done in foreman > >>2) the foreman ui also gets any new features we need in katello. This > >>means double effort, but gets the features out to the foreman > >>community for maturity. > >> > >>-- bk > > > >Do you guys think it's necessary to have Foreman run on the same server > >as Katello? If so, I think we would have to merge the ssl setup and get > >the two projects on the same gem versions. Not sure if this is already > >worked out or if you think running on the same server is out of scope > >for the integration. Would there always be a 1-1 integration between > >Katello and Foreman? Or is there some other grand vision for an HA > >architecture? > > Like the other libraries, I think we want them on the same machine > and on uniquee machines. I think we need to do another effort to get > Katello, Aeolus, and Foreman on the same stack. I have heard we want > to look to 1.9.3 and, Rails 3.0, and a common gem sack. We're on the same stack (or were for product anyway), and Cloud Engine upstream also works on both F16 (ruby 1.8.7) and F17 (ruby 1.9.3). We do need to get all three things on the same stack going forward. The bigger deal for running them all on the same box is that we need to merge the ssl setup, though. I would like to do that ASAP. --H -- == Hugh Brock, hbrock at redhat.com == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From jlabocki at redhat.com Thu Jun 28 00:56:10 2012 From: jlabocki at redhat.com (James Labocki) Date: Wed, 27 Jun 2012 20:56:10 -0400 (EDT) Subject: [katello-devel] importing manifests with the "force" flag In-Reply-To: <4FEB1F53.7060406@redhat.com> References: <342426f0-44a3-4e03-baaa-a974bb30c530@zmail16.collab.prod.int.phx2.redhat.com> <332e1af3-6a43-4447-842e-76a93a36c702@zmail16.collab.prod.int.phx2.redhat.com> <4FEB15FA.5090406@redhat.com> <20120627145201.GC4286@pipboy.redhat.com> <4FEB1F53.7060406@redhat.com> Message-ID: <6B9E7CAC-FA4A-47DA-AE8E-1601C7DA60EA@redhat.com> On Jun 27, 2012, at 10:57 AM, Bryan Kearney wrote: > On 06/27/2012 10:52 AM, James Bowes wrote: >> On Wed, Jun 27, 2012 at 11:44:44AM -0300, Devan Goodwin wrote: >>> On Wed, Jun 27, 2012 at 11:17 AM, Bryan Kearney wrote: >>>> On 06/27/2012 09:38 AM, Devan Goodwin wrote: >>>>> >>>>> I believe the creation date is the only thing force buys you, and >>>>> indeed an older manifest should not normally be usable unless >>>>> something went wrong with the new one. The force flag has kind of run >>>>> off the rails. It was requested for development purposes if I recall >>>>> correctly, but there is definitely no reason I can think of it should >>>>> be allowed for end users. >>>> >>>> >>>> If we turn back on checking the signature, and the checks for type, then it >>>> will become relevant again. >>>> >>>> - bk >>>> >>> >>> What's the use case where an end user would want to bypass date checking? >>> >>> Same question for bypassing signature checking. (that one is even more >>> scary to me, what on earth would someone be doing to need that?) :) >>> >>> Seems to me that force should be hidden from view, and possibly not be >>> there at all. >>> >> >> I've long been trying to get that option out of the ui. There's few >> cases where a non developer can use it and it won't end up hurting them. >> >> It should be available as an advanced cli option, wrapped in nice >> warnings, and only used when something catastrophic has happened, and >> you need to roll back to an old version. >> >> I'd prefer sig checking to just be a config option, but if we wanted it >> to be tweakable at run time, it should be a seperate option, so you can >> roll back to and older manifest version, but still verify its integrity. >> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> >> -James >> > ok.. added to the backlog: > > As a user, i would like the Force flag removed from the UI but kept in the CLI for manifest uploads so that I can not hurt myself accidently. +1 > > -- bk > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From tstrachota at redhat.com Thu Jun 28 13:42:15 2012 From: tstrachota at redhat.com (Tomas Strachota) Date: Thu, 28 Jun 2012 15:42:15 +0200 Subject: [katello-devel] API documentation Message-ID: <4FEC5F37.3070806@redhat.com> Hello team, our api documentation efforts are slowly moving. We've got 4 controllers finished and 1 assigned but there are still 32 left untouched. We can speed it up a lot if everybody takes one and looks at it. It's not difficult as we have basic docs already automatically generated. You only have to check the parameters and fill in some meaningful descriptions. Those two links will show you where to start: https://fedorahosted.org/katello/wiki/ApiDocHowto https://fedorahosted.org/katello/wiki/APIDocumentationEfforts Tomas From bkearney at redhat.com Thu Jun 28 13:48:35 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 28 Jun 2012 09:48:35 -0400 Subject: [katello-devel] API documentation In-Reply-To: <4FEC5F37.3070806@redhat.com> References: <4FEC5F37.3070806@redhat.com> Message-ID: <4FEC60B3.8090000@redhat.com> If folks could spend some time now and then to address this and maybe hit a bug or two. Proress in these areas as well as features is great. -- bk On 06/28/2012 09:42 AM, Tomas Strachota wrote: > Hello team, > our api documentation efforts are slowly moving. We've got 4 controllers > finished and 1 assigned but there are still 32 left untouched. We can > speed it up a lot if everybody takes one and looks at it. It's not > difficult as we have basic docs already automatically generated. You > only have to check the parameters and fill in some meaningful descriptions. > > Those two links will show you where to start: > https://fedorahosted.org/katello/wiki/ApiDocHowto > https://fedorahosted.org/katello/wiki/APIDocumentationEfforts > > Tomas > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel From thomasmckay at redhat.com Thu Jun 28 14:02:47 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 28 Jun 2012 10:02:47 -0400 (EDT) Subject: [katello-devel] organization history visibility In-Reply-To: <173bc078-0f1a-4c3f-b37b-21c2caa59a19@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: The history displayed in katello for an organization comes directly from candlepin, which has no knowledge of katello users. This history, then, contains information from across the entire katello organization's users. While logged into katello as a user named "User1" the history displayed contains events generated by user "admin". 2012-06-22 admin consumed a subscription for product Red Hat Enterprise Linux Server, Standard (1 Virtual Machine up to 8 vCPUs) 2012-06-22 admin consumed a subscription for product Resilient Storage (8 sockets) 2012-06-22 admin created a pool for product Resilient Storage (8 sockets) 2012-06-22 admin consumed a subscription for product Red Hat Enterprise Linux Server, Standard (1 Virtual Machine up to 8 vCPUs) 2012-06-22 admin consumed a subscription for product High-Availability (8 sockets) 2012-06-22 admin created a pool for product High-Availability (8 sockets) 2012-06-22 admin created new consumer sys-TEST-v 2012-06-22 admin created new consumer sys-DEV-v Is this a concern, or is it alright to consider that "read access" to a katello organization means visibility of all candlepin events? From mrao at redhat.com Thu Jun 28 16:05:47 2012 From: mrao at redhat.com (Malini Rao) Date: Thu, 28 Jun 2012 12:05:47 -0400 (EDT) Subject: [katello-devel] Log in Interstitial and Manage organizations In-Reply-To: Message-ID: <859b8cb4-6dfb-49f0-924b-290550a1d898@zmail12.collab.prod.int.phx2.redhat.com> Hey Jason, As we mentioned in the Converge UI meeting yesterday, Kyle and I have been putting together the modified screens for the Org selection as part of log in and also the relocation of the original 'Manage Organizations' interstitial page. This is not far from what you are currently implementing for this iteration but irons out some of the wrinkles from the user expectation and perception point of view and mostly in terms of visual design. We also covered some details around where to set/ reset the default org etc. You can access all details here- http://design.lab.bos.redhat.com/wiki/Katello_Reorganization The one other thing we called out but will detail as a separate exercise is how the Administer topics display. Currently, the connection between the selected Administer link on the top with the content directly under the regular content tabs is weak. If you have any questions, comments or feedback, please let us know. Thanks Malini From bkearney at redhat.com Thu Jun 28 16:14:03 2012 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 28 Jun 2012 12:14:03 -0400 Subject: [katello-devel] Log in Interstitial and Manage organizations In-Reply-To: <859b8cb4-6dfb-49f0-924b-290550a1d898@zmail12.collab.prod.int.phx2.redhat.com> References: <859b8cb4-6dfb-49f0-924b-290550a1d898@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <4FEC82CB.7080605@redhat.com> On 06/28/2012 12:05 PM, Malini Rao wrote: > Hey Jason, > > As we mentioned in the Converge UI meeting yesterday, Kyle and I have been putting together the modified screens for the Org selection as part of log in and also the relocation of the original 'Manage Organizations' interstitial page. This is not far from what you are currently implementing for this iteration but irons out some of the wrinkles from the user expectation and perception point of view and mostly in terms of visual design. > > We also covered some details around where to set/ reset the default org etc. > > You can access all details here- http://design.lab.bos.redhat.com/wiki/Katello_Reorganization > > The one other thing we called out but will detail as a separate exercise is how the Administer topics display. Currently, the connection between the selected Administer link on the top with the content directly under the regular content tabs is weak. > > If you have any questions, comments or feedback, please let us know. Another item.. I would expect a large number of admin topics when we bring in Foreman> We need to think how the second level nav will work in that case. -- bk From kybaker at redhat.com Thu Jun 28 16:18:16 2012 From: kybaker at redhat.com (Kyle Baker) Date: Thu, 28 Jun 2012 12:18:16 -0400 (EDT) Subject: [katello-devel] Log in Interstitial and Manage organizations In-Reply-To: <4FEC82CB.7080605@redhat.com> Message-ID: <827b0c14-4396-4245-9f01-5511a9d84cd7@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 06/28/2012 12:05 PM, Malini Rao wrote: > > Hey Jason, > > > > As we mentioned in the Converge UI meeting yesterday, Kyle and I > > have been putting together the modified screens for the Org > > selection as part of log in and also the relocation of the > > original 'Manage Organizations' interstitial page. This is not far > > from what you are currently implementing for this iteration but > > irons out some of the wrinkles from the user expectation and > > perception point of view and mostly in terms of visual design. > > > > We also covered some details around where to set/ reset the default > > org etc. > > > > You can access all details here- > > http://design.lab.bos.redhat.com/wiki/Katello_Reorganization > > > > The one other thing we called out but will detail as a separate > > exercise is how the Administer topics display. Currently, the > > connection between the selected Administer link on the top with > > the content directly under the regular content tabs is weak. > > > > If you have any questions, comments or feedback, please let us > > know. > > Another item.. I would expect a large number of admin topics when we > bring in Foreman> We need to think how the second level nav will work > in > that case. We will make sure to follow up on Foreman integration in the Administer area. We also will be posting these screens in the Katello wiki. A link will follow. > > -- bk > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From jrist at redhat.com Thu Jun 28 16:25:50 2012 From: jrist at redhat.com (Jason Rist) Date: Thu, 28 Jun 2012 10:25:50 -0600 Subject: [katello-devel] Log in Interstitial and Manage organizations In-Reply-To: <859b8cb4-6dfb-49f0-924b-290550a1d898@zmail12.collab.prod.int.phx2.redhat.com> References: <859b8cb4-6dfb-49f0-924b-290550a1d898@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <4FEC858E.90205@redhat.com> On 06/28/2012 10:05 AM, Malini Rao wrote: > Hey Jason, > > As we mentioned in the Converge UI meeting yesterday, Kyle and I have been putting together the modified screens for the Org selection as part of log in and also the relocation of the original 'Manage Organizations' interstitial page. This is not far from what you are currently implementing for this iteration but irons out some of the wrinkles from the user expectation and perception point of view and mostly in terms of visual design. > > We also covered some details around where to set/ reset the default org etc. > > You can access all details here- http://design.lab.bos.redhat.com/wiki/Katello_Reorganization > > The one other thing we called out but will detail as a separate exercise is how the Administer topics display. Currently, the connection between the selected Administer link on the top with the content directly under the regular content tabs is weak. > > If you have any questions, comments or feedback, please let us know. > > Thanks > Malini Thanks Malini - that is an internal URL, but to summarize for those external, there is an interstitial that is proposed between Login and a post-login URL if an Org has not been selected. Since we're re-using the Org Selector (instead of writing more code and in an effort to keep the Org Selector DRY), the ability to Select (the button) is not possible. I'd like to propose that we have the checkbox "Make this org my default" before the dropdown. Also, since I'm reusing the current setup of the login sliding mechanism (since I just now received this UXD directive and have been working on this for almost 2 weeks), and as such I would prefer not to add another page or remove the branding just for the interstitial. I'll demo what I have so far and we can add the additional changes next sprint if time and priorities permit. As for the "connection between the selected Administer link" being "weak", I'm not sure what you mean at all. Thanks, Jason -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From thomasmckay at redhat.com Thu Jun 28 16:42:14 2012 From: thomasmckay at redhat.com (Tom McKay) Date: Thu, 28 Jun 2012 12:42:14 -0400 (EDT) Subject: [katello-devel] Log in Interstitial and Manage organizations In-Reply-To: <859b8cb4-6dfb-49f0-924b-290550a1d898@zmail12.collab.prod.int.phx2.redhat.com> Message-ID: <073eb4e2-8e91-4561-a22a-6081f7957dd1@zmail16.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Malini Rao" > To: katello-devel at redhat.com > Sent: Thursday, June 28, 2012 12:05:47 PM > Subject: [katello-devel] Log in Interstitial and Manage organizations > > Hey Jason, > > As we mentioned in the Converge UI meeting yesterday, Kyle and I have > been putting together the modified screens for the Org selection as > part of log in and also the relocation of the original 'Manage > Organizations' interstitial page. This is not far from what you are > currently implementing for this iteration but irons out some of the > wrinkles from the user expectation and perception point of view and > mostly in terms of visual design. > > We also covered some details around where to set/ reset the default > org etc. Not sure what meetings this was discussed in, but be careful about what you mean by "default organization." I have it on my list of things to make the user tab for "Environments" change to accurate reflect what it really is: This is the default environment that a system, when registered by that user, gets placed in and nothing more. I think the concept of a default organization (ie. where the user logs into by default) is valid but it doesn't exist today, as far as I know. Someone correct me? In any case, they are two entirely separate concepts. > > You can access all details here- > http://design.lab.bos.redhat.com/wiki/Katello_Reorganization > > The one other thing we called out but will detail as a separate > exercise is how the Administer topics display. Currently, the > connection between the selected Administer link on the top with the > content directly under the regular content tabs is weak. > > If you have any questions, comments or feedback, please let us know. > > Thanks > Malini > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From kybaker at redhat.com Thu Jun 28 16:52:24 2012 From: kybaker at redhat.com (Kyle Baker) Date: Thu, 28 Jun 2012 12:52:24 -0400 (EDT) Subject: [katello-devel] Log in Interstitial and Manage organizations In-Reply-To: <073eb4e2-8e91-4561-a22a-6081f7957dd1@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <980d1381-5200-4d86-a3f1-7367aed61953@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Malini Rao" > > To: katello-devel at redhat.com > > Sent: Thursday, June 28, 2012 12:05:47 PM > > Subject: [katello-devel] Log in Interstitial and Manage > > organizations > > > > Hey Jason, > > > > As we mentioned in the Converge UI meeting yesterday, Kyle and I > > have > > been putting together the modified screens for the Org selection as > > part of log in and also the relocation of the original 'Manage > > Organizations' interstitial page. This is not far from what you are > > currently implementing for this iteration but irons out some of the > > wrinkles from the user expectation and perception point of view and > > mostly in terms of visual design. > > > > We also covered some details around where to set/ reset the default > > org etc. > > Not sure what meetings this was discussed in, but be careful about > what you mean by "default organization." I have it on my list of > things to make the user tab for "Environments" change to accurate > reflect what it really is: This is the default environment that a > system, when registered by that user, gets placed in and nothing > more. > > I think the concept of a default organization (ie. where the user > logs into by default) is valid but it doesn't exist today, as far as > I know. Someone correct me? In any case, they are two entirely > separate concepts. > > > > > You can access all details here- > > http://design.lab.bos.redhat.com/wiki/Katello_Reorganization > > > > The one other thing we called out but will detail as a separate > > exercise is how the Administer topics display. Currently, the > > connection between the selected Administer link on the top with the > > content directly under the regular content tabs is weak. > > > > If you have any questions, comments or feedback, please let us External link as promised - https://fedorahosted.org/katello/wiki/Katello%20Reorganization > > know. > > > > Thanks > > Malini > > > > _______________________________________________ > > katello-devel mailing list > > katello-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > katello-devel mailing list > katello-devel at redhat.com > https://www.redhat.com/mailman/listinfo/katello-devel > From mrao at redhat.com Thu Jun 28 19:21:17 2012 From: mrao at redhat.com (Malini Rao) Date: Thu, 28 Jun 2012 15:21:17 -0400 (EDT) Subject: [katello-devel] Log in Interstitial and Manage organizations In-Reply-To: <4FEC858E.90205@redhat.com> Message-ID: Jason, Comments inline - ----- Original Message ----- From: "Jason Rist" To: "Malini Rao" Cc: katello-devel at redhat.com Sent: Thursday, June 28, 2012 12:25:50 PM Subject: Re: Log in Interstitial and Manage organizations On 06/28/2012 10:05 AM, Malini Rao wrote: > Hey Jason, > > As we mentioned in the Converge UI meeting yesterday, Kyle and I have been putting together the modified screens for the Org selection as part of log in and also the relocation of the original 'Manage Organizations' interstitial page. This is not far from what you are currently implementing for this iteration but irons out some of the wrinkles from the user expectation and perception point of view and mostly in terms of visual design. > > We also covered some details around where to set/ reset the default org etc. > > You can access all details here- http://design.lab.bos.redhat.com/wiki/Katello_Reorganization > > The one other thing we called out but will detail as a separate exercise is how the Administer topics display. Currently, the connection between the selected Administer link on the top with the content directly under the regular content tabs is weak > > If you have any questions, comments or feedback, please let us know. > > Thanks > Malini Thanks Malini - that is an internal URL, but to summarize for those external, there is an interstitial that is proposed between Login and a post-login URL if an Org has not been selected. >>MR: I apologize for sending out an internal link on this list. I was so focused on getting this out to you ASAP that I went with the habit of posting on the internal wiki that we had so far. Kyle has now re-posted the design proposal in the right place - https://fedorahosted.org/katello/wiki/Katello%20Reorganization. We will ensure, we post stuff here moving forward. Since we're re-using the Org Selector (instead of writing more code and in an effort to keep the Org Selector DRY), the ability to Select (the button) is not possible. I'd like to propose that we have the checkbox "Make this org my default" before the dropdown. >>MR: I understand the value of reusing the Org Selector widget but what doesn't make sense from the user perspective is to check/ uncheck the "Make this my default Selection" checkbox BEFORE actually making the selection. We are not suggesting any change for the sprint demo coming up but we almost prefer that we remove the " Make this my default selection" flag from the login interstitial page and leave that option in the Org switcher and the Manage Organizations page. Also, since I'm reusing the current setup of the login sliding mechanism (since I just now received this UXD directive and have been working on this for almost 2 weeks), and as such I would prefer not to add another page or remove the branding just for the interstitial. I'll demo what I have so far and we can add the additional changes next sprint if time and priorities permit. >>MR: Need to clarify a couple of points here. There was a call in which you guys ( I was not part of this call/ IRC) discussed that Kyle's original proposal for the Mange Organizations interstitial page was not going to work because of the way permissions worked. The proposal that Kyle and I made with a 2-step login with the 'Next' button and the slide out panel for the org selection was made on June 21st... a few days after that initial call. You indicated that you liked this approach but also mentioned that it was incorrect that we were pressing a button called 'Login' on the second page when infact you are logging in on the first page. Given this, Kyle and I put our heads together because we thought your point was very valid. We then came up with this proposal that we sent out today. So, while this whole discussion may have spanned 2 weeks, we (UXD) have tried to be as responsive as possible. When we sent out the proposal today, we did not send it out with the expectation that it will all be incorporated for the sprint demo coming up but we did want to send it out ASAP anyway. I understand you have put in significant work on the slide out panel and we are willing to keep an open mind and see the demo and then evaluate if it would be acceptable in terms of the user experience given the requirements and constraints. However, the reason we did make the distinction is because we wanted to convey very clearly to the user the very point you brought up - to be correct about when the login happens and convey that the Org selection is a post login act and using the slide out within the login muddies that paradigm. As for the "connection between the selected Administer link" being "weak", I'm not sure what you mean at all. >>MR: If you look at this screen - https://fedorahosted.org/katello/wiki/Manage%20Organizations, the content displayed in the main body of the screen pertains to the Administer link that lives way up on the shell even though it is directly under the main content tabs ( Dashboard, content, systems etc). I understand none of these tabs are selected but because they do continue to display there, there is a strong user expectation that the main body of the screen is related to one of the tabs above. It makes full sense to pull Administer out from the rest of the Org related content but we break that clean distinction by displaying the content close to the unrelated tabs. I understand the need to have these various content areas accessible easily but we need to solve this tension created by the multi-purpose use of the screen real estate and the proximity/ distance to what it does and does not pertain to. This is a definite usability issue and we should solve it. But this is a bit of detailing that is yet to be done as part of the re-org exercise that none of us has had the bandwidth to consider until now. Also it is an exercise in itself and we didn't want to lump it as part of the Manage Org page design proposals. Bryan also just brought up how the Admin are topics could grow with Foreman integration and so it looks like we need to think of a more robust design anyway. Thanks, Jason -- Jason E. Rist Senior Software Engineer Systems Management and Cloud Enablement Red Hat, Inc. +1.919.754.4048 Freenode: jrist From bbuckingham at redhat.com Thu Jun 28 20:44:55 2012 From: bbuckingham at redhat.com (Brad Buckingham) Date: Thu, 28 Jun 2012 16:44:55 -0400 Subject: [katello-devel] Nitty gritty UX feedback on System groups In-Reply-To: References: Message-ID: <4FECC247.8010901@redhat.com> Hi Malini, Attached is the screen shot for the System Groups Event History page requested in the action items below. Thanks, Brad On 06/22/2012 12:22 PM, Malini Rao wrote: > Hello everyone, > > Thanks for the feedback on email and in the meeting this morning about the feedback I sent. > > Here's the summary of what we discussed in the meeting based on my original feedback and the responses received thereafter - > > 1. "Just use simple numbers instead of the oval round" - There are black tooltips and white info-tipsies in place in the tool today and the latter can stick upon click and even scroll if necessary. Both need some kind of affordance that a hover state exists and since they are distinguished visually, it will be good to carryover that distinction in the trigger affordance as well. While I wasn't proposing simple text in my original feedback, I feel like we should not use the visual treatment reserved for notifications, alerts and summary rollups for this purpose since it reduces the impact and effectiveness of that treatment for the original purpose. Group did not like the idea of using a link for the number. > > ACTION ITEM: > - Harlan/ Kyle will explore how this can be presented in another way that will work across the board as a pattern for triggering info-tips. > > > 2. "Should not use all caps for title." - I understand this is consistent across the board but it is pretty rare to have all caps for titles as a general UX best practice. This becomes more of an issue when the titles are more than a one word label which is probably how it was used when it was first proposed. Tom's point about potential translation issues is also very valid. I don't think Brad needs to make any change for this page right now but we should reconsider this when updating the styles as part of extending the new Shell styles down to pages and components. Similarly, there was an agreement that the pipe is best used to separate groupings and so we can use the colon consistently when we update the styles. > > ACTION ITEM: > - Harlan/ Kyle will take this ( All caps and Pipe) into account as they are extending the new updated visual feel. We will share these at some point for comments and feedback. > > > 3. "Title too long." - Yes, there can be merits in being more verbose but here, it does not seem to add more value. In general UX best practices for titles is that they should be short, crisp and articulate. The shorter they are, the more they will stand out as titles and allow better scanabilty. Brad explained that there was some feedback on how this was confusing and so he ended up making the title long and no one on the call had objections to shortening this esp since it will be hard to make this a consistent pattern and list all actions possible on any given page as part of the title. The title also seems to be attached only to the top parameters and not the list below which might be adding to the confusion on what is happening on the page. Some of this could potentially be alleviated by pulling the title out of the table. > > ACTION ITEMS: > - Brad to shorten the title. > - Kyle to send Brad an example of the title displaying outside the tables so Brad can model this fix after it. > > > 4. Events - Brad explained the intended flow and interaction. All agreed that having a link between the status on the install/ update packages page and the event details is important to make the task flow seem more seamless. Seems also like the Events page will likely be more heavy weight with many other types of events that could be possible in the future. Until that point, we will not move the events page from where it is. > > ACTION ITEMS: > - Brad to send UX the events list page so we can have all the screenshots of the interaction flow. > - UX to propose& share a way in which the event information can be presented alongside the status of the job on the Packages / errata pages without necessarily having to go find it on the events page ( some ideas talked about were info tips, overlay panels etc.) > > Thanks > Malini > > > ----- Original Message ----- > From: "Brad Buckingham" > To: jrist at redhat.com > Cc: "Tom McKay", katello-devel at redhat.com, "Malini Rao" > Sent: Friday, June 22, 2012 9:47:28 AM > Subject: Re: [katello-devel] Nitty gritty UX feedback on System groups > > On 06/22/2012 09:34 AM, Jason Rist wrote: >> On Fri 22 Jun 2012 05:11:32 AM MDT, Tom McKay wrote: >>> >>> ----- Original Message ----- >>>> From: "Malini Rao" >>>> To: katello-devel at redhat.com >>>> Cc: "Brad Buckingham" >>>> Sent: Thursday, June 21, 2012 4:01:29 PM >>>> Subject: [katello-devel] Nitty gritty UX feedback on System groups >>>> >>>> Hi Brad, >>>> >>>> I had made notes of some UX things that struck me as I watched your >>>> last Sprint demo for system groups. The major functionality looks >>>> great and these are at a pretty nitty gritty level but nevertheless >>>> important to fix at some point for the finished product. The only >>>> slightly bigger topic is where the events page should live and we >>>> can discuss that. Other than that, if you have any questions, let me >>>> know. >>>> >>>> Thanks >>>> Malini >>>> _______________________________________________ >>>> katello-devel mailing list >>>> katello-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/katello-devel >>>> >>> >>> Slide 1: >>> + "Just use simple numbers instead of the oval round" - Disagree. The >>> oval style is an explicit indicator that hovering over it will bring >>> up a "tipsy" with more information. >>> >>> Slide 2: >>> + "Should not use all caps for title." - This is consistent across >>> the entire site for titles of tables. Why the change? >>> >>> + "Title too long." - If there's room, please retain verbose wording. >>> A valid reason to reconsider might be if translations to primary >>> supported languages cause wrapping of title. >>> >>> Slide 3: >>> + "Sub nav should be reconsidered." - Disagree. There are some panels >>> that are very crowded (eg. Systems). >>> >>> + "Events under Details" - Agree. I believe Kyle(?) instigated the >>> rule that Details always be the first tab with "Events History" under >>> that. (eg. see Systems) >>> >>> + "Event detail should be more closely related to where the action >>> takes place" - Don't understand. This table is the list of packages >>> and package groups that are being installed, updated, or removed. >>> >>> + "Link to events page" - Agree. That would be nice. However, I am >>> against having to go to another page to get details about something >>> that can just as easily be shown inline (eg. through a tipsy). Our UI >>> is not friendly in switching back and forth between pages at the moment. >>> >>> _______________________________________________ >>> katello-devel mailing list >>> katello-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/katello-devel >> I definitely have to agree with Tom on Slide 1. I have this to add: >> "Need to standardize how hover states look ? Contact Kyle/ Harlan >> about that. " - Why? One type of tipsy has help information (black) >> and one contains expanded information about what you're hovering over >> (white). This is established (packages) and common. >> >> Agree with Tom on Slide 2 on both points. Why be terse when verbose is >> so much more helpful and the difference is so minor? Otherwise it's >> more unclear and confusing, degrading the user experience. >> >> Agree again with Tom on Events under Details. What should be the >> default (first showing upon panel expansion) page for this pane? I am >> not sure that System Group Info or Events would be good/useful. >> >> Slide 4: "Group 1 title is getting cut off because of the way the >> package install panel overlays on top. Need to adjust the spacing so >> there is no clipping." >> This should be a bug across the system, as it will impact everything >> with a subpanel. >> > I was going to wait for the meeting, but now I'm compelled to add a > reply. :) > > Slide 1: > - agree with the comments above > - "Use colon instead of the | after the field label" - We can do that; > however, this style as used as it was part of the System->Errata mockup > used for past implementations. If we change it here, we should > propagate the styling there as well. > > Slide 2: > - agree with the comments above > > Slide 3: > - "Sub nav should be reconsidered" - agree with the comments above. > This was done to be consistent with System->Details->Events (now both > are called Event History). If we change this here, we also need revisit > systems for consistency. > - "Event details should be more closely related to where the action > takes place" - Was actually planning to make this either a tipsy (upon > completion) or link to open the actual event (e.g. subpanel). Using the > link may actually be better in this case as there could be a fair amount > of information generated depending upon the size of the group. Another > alternative would be a tipsy w/ brief summary with link in the tipsy > that opens the event for more details. > > Slide 4 - > - agree with the comments above. This one is actually a generic 2-pane > issue. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: SystemGroup-EventHistory.png Type: image/png Size: 117165 bytes Desc: not available URL: From lzap at redhat.com Fri Jun 29 21:28:27 2012 From: lzap at redhat.com (Lukas Zapletal) Date: Fri, 29 Jun 2012 23:28:27 +0200 Subject: [katello-devel] Nightly build online Message-ID: <20120629212827.GA4411@lzapx.brq.redhat.com> Hello, we had some issues with nightly (testing) builds, but it is finally fixed. You can install testing version again now. Please report bugs. katello-0.2.43-1.git.36.5ddcc14.el6.noarch katello-cli-0.2.41-1.git.25.9c71bc3.el6.noarch katello-agent-1.0.4-1.git.0.4d2cfb2.el6.noarch pulp-1.1.10-1.el6.noarch candlepin-0.5.32-1.el6.noarch subscription-manager-0.99.14-1.el6.x86_64 python-rhsm-0.99.8-1.el6.noarch yum-3.2.29-22.el6.noarch LZ -- Later, Lukas "lzap" Zapletal #katello #systemengine From msuchy at redhat.com Sat Jun 30 10:44:34 2012 From: msuchy at redhat.com (Miroslav Suchy) Date: Sat, 30 Jun 2012 12:44:34 +0200 Subject: [katello-devel] API documentation In-Reply-To: <4FEC5F37.3070806@redhat.com> References: <4FEC5F37.3070806@redhat.com> Message-ID: <4FEED892.1080704@redhat.com> On 28.6.2012 15:42, Tomas Strachota wrote: > Hello team, > our api documentation efforts are slowly moving. We've got 4 controllers > finished and 1 assigned but there are still 32 left untouched. We can > speed it up a lot if everybody takes one and looks at it. It's not > difficult as we have basic docs already automatically generated. You > only have to check the parameters and fill in some meaningful descriptions. > > Those two links will show you where to start: > https://fedorahosted.org/katello/wiki/ApiDocHowto > https://fedorahosted.org/katello/wiki/APIDocumentationEfforts Can we have subpackage katello-api-doc, which will contain those static pages? Mirek