1. I would put REST api as a separate section, and also not in the same hierarchy/section as client libraries, because REST is part of the project, and clients consume it.

2. Having sections named "clients" and "client libraries" can be confusing.

Perhaps "integrations" or "applications that consume hawkular" is better for "clients"?

3. Is there a section dedicated to community events (meetups/conferences/hackaton/summit, etc.) where there are talks about the project? Didn't see it in the diagram.

4. Overview can link to quick start imo

5. What should be the difference between quick start and the download sections?

6. Ways to contact community? I saw only social links in the footer, but what about mailing list/irc,etc.?

p.s. I wrote an article couple of years ago on usability of community websites, maybe some ideas from there would be helpful as well https://opensource.com/business/14/8/open-source-project-front-door

On Tue, Jun 14, 2016 at 2:46 PM, Thomas Heute <theute(a)redhat.com&gt; wrote: > > > On Tue, Jun 14, 2016 at 1:24 PM, Alissa Bonas <abonas(a)redhat.com&gt; wrote: > >> 1. I would put REST api as a separate section, and also not in the same >> hierarchy/section as client libraries, because REST is part of the project, >> and clients consume it. >> > > I'm not sure, from a developer perspective it doesn't really matter if > REST is part of the project (except that you have nothing else to > download/use), but it should be clear what options, as a developer, you > have. > One has the choice between Ruby, Python, Go or plain REST. > > At least that was my way of thinking. > > > >> 2. Having sections named "clients" and "client libraries" can be >> confusing. >> > > Agreed. > > >> Perhaps "integrations" or "applications that consume hawkular" is better >> for "clients"? >> > > I thought of "consumers" for a short name. As we have "feeds" that feed > data and "consumers" that consumed and display or do something with the > data. Still not convinced about that name though.... > consumers sounds good. > 3. Is there a section dedicated to community events >> (meetups/conferences/hackaton/summit, etc.) where there are talks about the >> project? Didn't see it in the diagram. >> > > Good point. > We should probably splash them on the front page + blog. > > >> 4. Overview can link to quick start imo >> > > Not sure what you mean, after one read the overview he should definitely > be invited to get started. > my point was that the navigation should be as simple and efficient as possible. so if a user reads the overview page, there's no need to go to the homepage again in order to go to "get started", but rather navigate directly/have an inviting link from overview to get started.

> > >> 5. What should be the difference between quick start and the download >> sections? >> > > Quick start explains how to install the quickest way and get something > out of the product. > > The download section allows to find links of latest and previous releases. > like above, I would also link between quick start and download pages so the user will get a convenient flow of "here's how to" and "here's where you can download from"

> > >> 6. Ways to contact community? I saw only social links in the footer, but >> what about mailing list/irc,etc.? >> > > That would be in Community>Connect > >> >> > >> p.s. I wrote an article couple of years ago on usability of community >> websites, maybe some ideas from there would be helpful as well >> https://opensource.com/business/14/8/open-source-project-front-door >> > > > I'll have a look, thanks ! > > Thomas > > > >> >> >> thanks, >> Alissa >> >> On Tue, Jun 14, 2016 at 1:25 PM, Thomas Heute <theute(a)redhat.com&gt; wrote: >> >>> With the recent repackaging effort + the ManageIQ UI, we need to >>> rethink hawkular.org. >>> >>> It's tricky to keep it simple, what to download, for what usecase... >>> And at the moment it's getting outdated. >>> >>> IMO, it should be trivial for end users to figure out: >>> - What to download >>> - where to download and how to install the server >>> - find/browse/download the various options to feed the server with >>> data (WF agent, ptrans supported protocoles, ...) >>> - find/browse/download options to use/read the data: (ManageIQ, >>> Grafana...) >>> >>> and for the developers >>> - find/browse/download the client libraries (Ruby, Python...) >>> - Find client libraries documentation >>> - Find examples... >>> >>> We should probably not separate/fork Hawkular Services from Hawkular >>> "community" too much, beside the installation procedure and few things that >>> we would mention as only available in the "larger" package. I use the term >>> "Hawkular Server" in the mind map for the 2 "flavors". >>> >>> Please propose improvements to the draft attached that represents the >>> website structure. (A square is not necessarily a page, it may be a section >>> of a page) >>> >>> Thomas >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Consumers is terrible word for any client, as they both consume as well as produce the data.

For example for Heapster, we currently produce the data, however at the moment I'm creating a change that will consume the data from HWKMETRICS.

Integration / clients is far more used and known word, while consumer/producer is something more specific and implies a design pattern. - Micke ----- Original Message ----- From: "Alissa Bonas" <abonas(a)redhat.com&gt; To: "Discussions around Hawkular development" < hawkular-dev(a)lists.jboss.org&gt; Sent: Tuesday, June 14, 2016 3:32:16 PM Subject: Re: [Hawkular-dev] Hawkular.org On Tue, Jun 14, 2016 at 2:46 PM, Thomas Heute < theute(a)redhat.com > wrote: On Tue, Jun 14, 2016 at 1:24 PM, Alissa Bonas < abonas(a)redhat.com > wrote: 1. I would put REST api as a separate section, and also not in the same hierarchy/section as client libraries, because REST is part of the project, and clients consume it. I'm not sure, from a developer perspective it doesn't really matter if REST is part of the project (except that you have nothing else to download/use), but it should be clear what options, as a developer, you have. One has the choice between Ruby, Python, Go or plain REST. At least that was my way of thinking. 2. Having sections named "clients" and "client libraries" can be confusing. Agreed. Perhaps "integrations" or "applications that consume hawkular" is better for "clients"? I thought of "consumers" for a short name. As we have "feeds" that feed data and "consumers" that consumed and display or do something with the data. Still not convinced about that name though.... consumers sounds good. 3. Is there a section dedicated to community events (meetups/conferences/hackaton/summit, etc.) where there are talks about the project? Didn't see it in the diagram. Good point. We should probably splash them on the front page + blog. 4. Overview can link to quick start imo Not sure what you mean, after one read the overview he should definitely be invited to get started. my point was that the navigation should be as simple and efficient as possible. so if a user reads the overview page, there's no need to go to the homepage again in order to go to "get started", but rather navigate directly/have an inviting link from overview to get started. 5. What should be the difference between quick start and the download sections? Quick start explains how to install the quickest way and get something out of the product. The download section allows to find links of latest and previous releases. like above, I would also link between quick start and download pages so the user will get a convenient flow of "here's how to" and "here's where you can download from" 6. Ways to contact community? I saw only social links in the footer, but what about mailing list/irc,etc.? That would be in Community>Connect p.s. I wrote an article couple of years ago on usability of community websites, maybe some ideas from there would be helpful as well https://opensource.com/business/14/8/open-source-project-front-door I'll have a look, thanks ! Thomas thanks, Alissa On Tue, Jun 14, 2016 at 1:25 PM, Thomas Heute < theute(a)redhat.com > wrote: With the recent repackaging effort + the ManageIQ UI, we need to rethink hawkular.org . It's tricky to keep it simple, what to download, for what usecase... And at the moment it's getting outdated. IMO, it should be trivial for end users to figure out: - What to download - where to download and how to install the server - find/browse/download the various options to feed the server with data (WF agent, ptrans supported protocoles, ...) - find/browse/download options to use/read the data: (ManageIQ, Grafana...) and for the developers - find/browse/download the client libraries (Ruby, Python...) - Find client libraries documentation - Find examples... We should probably not separate/fork Hawkular Services from Hawkular "community" too much, beside the installation procedure and few things that we would mention as only available in the "larger" package. I use the term "Hawkular Server" in the mind map for the 2 "flavors". Please propose improvements to the draft attached that represents the website structure. (A square is not necessarily a page, it may be a section of a page) Thomas _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Currently Heapster stores in internal memory few minutes of data and allows queries that request this data (through its REST-interface). The consume part will just request the data from the HWKMETRICS instead. - Micke ----- Original Message ----- From: "Thomas Heute" <theute(a)redhat.com&gt; To: "Discussions around Hawkular development" < hawkular-dev(a)lists.jboss.org&gt; Sent: Tuesday, June 14, 2016 4:09:40 PM Subject: Re: [Hawkular-dev] Hawkular.org On Tue, Jun 14, 2016 at 3:06 PM, Michael Burman < miburman(a)redhat.com > wrote: Consumers is terrible word for any client, as they both consume as well as produce the data. Well that was actually reflecting the current state, we have "things" that feed data to the server and "things" that consume data from the server. The client libraries provide an API to feed and consume. For example for Heapster, we currently produce the data, however at the moment I'm creating a change that will consume the data from HWKMETRICS. Why does it consume data now ? Thomas Integration / clients is far more used and known word, while consumer/producer is something more specific and implies a design pattern. - Micke _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

I do not see the idea proposed yet, but why not structure the website around major projects? We have Hawkular community, Hawkular Services, Hawkular Metrics, and APM. Projects like Inventory or the clients would fall under Hawkular Services umbrella. So rather than designing a generic structure with everything make individual sub-sites and then apply the structure you proposed.

On 14 Jun 2016, at 22:32, Stefan Negrea wrote: > I do not see the idea proposed yet, but why not structure the website > around major projects? We have Hawkular community, Hawkular Services, > Hawkular Metrics, and APM. Projects like Inventory or the clients > would > fall under Hawkular Services umbrella. So rather than designing a > generic > structure with everything make individual sub-sites and then apply the > structure you proposed. I think even if/when Hawkular-metrics gets its own section (which is well warranted as we create a metrics distribution), we need to make sure that it blends well into the Hawkular-services documentation. We can for sure use some include tags to accomplish this. I think Hawkular-services should now be the main/default focus area of hawkular.org (at least from the non-APM side)

Likewise we should also be careful with external documentation like gitbook. I have seen some pretty good and comprehensive documentation there, so the idea behind is good. An issue is certainly that it is yet another place for stuff and dilutes the content on hawkular.org. Perhaps there is a way to include/iframe it, the experience could potentially be good, as some of the current (long) pages have issues with the navigation via the page-tree in the left part. On the other hand (and I think this was mentioned already) there may be a way to include content from hawkular.org into the gitbook, so that it exists in both forms, but from one source (-> consistency)

_______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On Wed, Jun 15, 2016 at 10:17 AM, Heiko W.Rupp < hrupp(a)redhat.com > wrote: On 14 Jun 2016, at 22:32, Stefan Negrea wrote: > I do not see the idea proposed yet, but why not structure the website > around major projects? We have Hawkular community, Hawkular Services, > Hawkular Metrics, and APM. Projects like Inventory or the clients > would > fall under Hawkular Services umbrella. So rather than designing a > generic > structure with everything make individual sub-sites and then apply the > structure you proposed. I think even if/when Hawkular-metrics gets its own section (which is well warranted as we create a metrics distribution), we need to make sure that it blends well into the Hawkular-services documentation. We can for sure use some include tags to accomplish this. I think Hawkular-services should now be the main/default focus area of hawkular.org (at least from the non-APM side) +1 Likewise we should also be careful with external documentation like gitbook. I have seen some pretty good and comprehensive documentation there, so the idea behind is good. An issue is certainly that it is yet another place for stuff and dilutes the content on hawkular.org . Perhaps there is a way to include/iframe it, the experience could potentially be good, as some of the current (long) pages have issues with the navigation via the page-tree in the left part. On the other hand (and I think this was mentioned already) there may be a way to include content from hawkular.org into the gitbook, so that it exists in both forms, but from one source (-> consistency) Agreed. Gary could you look into the options to "blend" gitbook.io content better into hawkular.org ? Here is the reference point: http://www.hawkular.org/docs/components/btm/index.html Maybe iFraming https://hawkular.gitbooks.io/hawkular-apm-user-guide/content/ would work... Maybe using a custom theme that adds our hawkular.org header/footer in gitbook.io would work (I didn't see how to apply a theme to all books though)... I gave you admin rights if you need to poke around, but I didn't see anything there that would help us... Thomas _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On Wed, Jun 15, 2016 at 12:01 PM, Gary Brown < gbrown(a)redhat.com > wrote: Hi http://pasteboard.co/1HmIxzsJ.png Tried using an iframe - problems are: 1) Border around iframe - not sure if this can be reduced/removed 2) When left hand menu showing, it is not possible to add comments (i.e. no + sign appears) 3) When menu hidden, plus sign shows, but asks to sign in to comment - when link selected the iframe content goes blank So not sure iframe is a workable solution. Will see what customisations can be made to the gitbook itself to look more integrated - however wondering whether we should do much customisation, as I think users know they are navigating from a website to documentation, so would not be concerned with a different look and feel - as long as a consistent approach was used for all documentation. Unless they arrive on the documentation from a Google search ;) Thomas Regards Gary ----- Original Message ----- > > > On Wed, Jun 15, 2016 at 10:17 AM, Heiko W.Rupp < hrupp(a)redhat.com > wrote: > > > On 14 Jun 2016, at 22:32, Stefan Negrea wrote: > > > I do not see the idea proposed yet, but why not structure the website > > around major projects? We have Hawkular community, Hawkular Services, > > Hawkular Metrics, and APM. Projects like Inventory or the clients > > would > > fall under Hawkular Services umbrella. So rather than designing a > > generic > > structure with everything make individual sub-sites and then apply the > > structure you proposed. > > I think even if/when Hawkular-metrics gets its own section (which is > well > warranted as we create a metrics distribution), we need to make sure > that > it blends well into the Hawkular-services documentation. We can for sure > use some include tags to accomplish this. I think Hawkular-services > should now be the main/default focus area of hawkular.org (at least > from the non-APM side) > > +1 > > > > Likewise we should also be careful with external documentation like > gitbook. I have seen some pretty good and comprehensive documentation > there, so the idea behind is good. An issue is certainly that it is yet > another > place for stuff and dilutes the content on hawkular.org . > Perhaps there is a way to include/iframe it, the experience could > potentially > be good, as some of the current (long) pages have issues with the > navigation > via the page-tree in the left part. > On the other hand (and I think this was mentioned already) there may be > a way to include content from hawkular.org into the gitbook, so that it > exists in both forms, but from one source (-> consistency) > > Agreed. > Gary could you look into the options to "blend" gitbook.io content better > into hawkular.org ? > > Here is the reference point: > http://www.hawkular.org/docs/components/btm/index.html > Maybe iFraming > https://hawkular.gitbooks.io/hawkular-apm-user-guide/content/ > would work... > Maybe using a custom theme that adds our hawkular.org header/footer in > gitbook.io would work (I didn't see how to apply a theme to all books > though)... > > I gave you admin rights if you need to poke around, but I didn't see > anything > there that would help us... > > Thomas > > > > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

But can it be applied to all books for an organization or does it need to be copied over all the books GItHub repos ? On Wed, Jun 15, 2016 at 12:54 PM, Gary Brown < gbrown(a)redhat.com > wrote: Its possible to customise the header/footer html with the current gitbook version being used by APM: header: http://pasteboard.co/1Hq9NDo9.png footer: http://pasteboard.co/1HqbdKdx.png Just need a suitable html fragment/ banner image to be provided. The header is same line as the search box, so needs to be constrained. Regards Gary ----- Original Message ----- > > > On Wed, Jun 15, 2016 at 12:01 PM, Gary Brown < gbrown(a)redhat.com > wrote: > > > Hi > > http://pasteboard.co/1HmIxzsJ.png > > Tried using an iframe - problems are: > > 1) Border around iframe - not sure if this can be reduced/removed > > 2) When left hand menu showing, it is not possible to add comments (i.e. no > + > sign appears) > > 3) When menu hidden, plus sign shows, but asks to sign in to comment - when > link selected the iframe content goes blank > > So not sure iframe is a workable solution. > > Will see what customisations can be made to the gitbook itself to look more > integrated - however wondering whether we should do much customisation, as > I > think users know they are navigating from a website to documentation, so > would not be concerned with a different look and feel - as long as a > consistent approach was used for all documentation. > > Unless they arrive on the documentation from a Google search ;) > > Thomas > > > > Regards > Gary > > ----- Original Message ----- > > > > > > On Wed, Jun 15, 2016 at 10:17 AM, Heiko W.Rupp < hrupp(a)redhat.com > > > wrote: > > > > > > On 14 Jun 2016, at 22:32, Stefan Negrea wrote: > > > > > I do not see the idea proposed yet, but why not structure the website > > > around major projects? We have Hawkular community, Hawkular Services, > > > Hawkular Metrics, and APM. Projects like Inventory or the clients > > > would > > > fall under Hawkular Services umbrella. So rather than designing a > > > generic > > > structure with everything make individual sub-sites and then apply the > > > structure you proposed. > > > > I think even if/when Hawkular-metrics gets its own section (which is > > well > > warranted as we create a metrics distribution), we need to make sure > > that > > it blends well into the Hawkular-services documentation. We can for sure > > use some include tags to accomplish this. I think Hawkular-services > > should now be the main/default focus area of hawkular.org (at least > > from the non-APM side) > > > > +1 > > > > > > > > Likewise we should also be careful with external documentation like > > gitbook. I have seen some pretty good and comprehensive documentation > > there, so the idea behind is good. An issue is certainly that it is yet > > another > > place for stuff and dilutes the content on hawkular.org . > > Perhaps there is a way to include/iframe it, the experience could > > potentially > > be good, as some of the current (long) pages have issues with the > > navigation > > via the page-tree in the left part. > > On the other hand (and I think this was mentioned already) there may be > > a way to include content from hawkular.org into the gitbook, so that it > > exists in both forms, but from one source (-> consistency) > > > > Agreed. > > Gary could you look into the options to "blend" gitbook.io content better > > into hawkular.org ? > > > > Here is the reference point: > > http://www.hawkular.org/docs/components/btm/index.html > > Maybe iFraming > > https://hawkular.gitbooks.io/hawkular-apm-user-guide/content/ > > would work... > > Maybe using a custom theme that adds our hawkular.org header/footer in > > gitbook.io would work (I didn't see how to apply a theme to all books > > though)... > > > > I gave you admin rights if you need to poke around, but I didn't see > > anything > > there that would help us... > > > > Thomas > > > > > > > > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On Wed, Jun 15, 2016 at 1:12 PM, Gary Brown < gbrown(a)redhat.com > wrote: Its per book so would need to be copied: That's quiet annoying :( And Gitbook doesn't support gitmodules it seems: https://github.com/theute/test2 --> https://theute.gitbooks.io/test2/content/ Thomas header/footer html files: https://github.com/hawkular/hawkular-apm-user-guide/tree/master/layouts referenced from: https://github.com/hawkular/hawkular-apm-user-guide/blob/master/book.json... Regards Gary ----- Original Message ----- > But can it be applied to all books for an organization or does it need to > be > copied over all the books GItHub repos ? > > On Wed, Jun 15, 2016 at 12:54 PM, Gary Brown < gbrown(a)redhat.com > wrote: > > > Its possible to customise the header/footer html with the current gitbook > version being used by APM: > > header: http://pasteboard.co/1Hq9NDo9.png > footer: http://pasteboard.co/1HqbdKdx.png > > Just need a suitable html fragment/ banner image to be provided. > > The header is same line as the search box, so needs to be constrained. > > Regards > Gary > > ----- Original Message ----- > > > > > > On Wed, Jun 15, 2016 at 12:01 PM, Gary Brown < gbrown(a)redhat.com > wrote: > > > > > > Hi > > > > http://pasteboard.co/1HmIxzsJ.png > > > > Tried using an iframe - problems are: > > > > 1) Border around iframe - not sure if this can be reduced/removed > > > > 2) When left hand menu showing, it is not possible to add comments (i.e. > > no > > + > > sign appears) > > > > 3) When menu hidden, plus sign shows, but asks to sign in to comment - > > when > > link selected the iframe content goes blank > > > > So not sure iframe is a workable solution. > > > > Will see what customisations can be made to the gitbook itself to look > > more > > integrated - however wondering whether we should do much customisation, > > as > > I > > think users know they are navigating from a website to documentation, so > > would not be concerned with a different look and feel - as long as a > > consistent approach was used for all documentation. > > > > Unless they arrive on the documentation from a Google search ;) > > > > Thomas > > > > > > > > Regards > > Gary > > > > ----- Original Message ----- > > > > > > > > > On Wed, Jun 15, 2016 at 10:17 AM, Heiko W.Rupp < hrupp(a)redhat.com > > > > wrote: > > > > > > > > > On 14 Jun 2016, at 22:32, Stefan Negrea wrote: > > > > > > > I do not see the idea proposed yet, but why not structure the website > > > > around major projects? We have Hawkular community, Hawkular Services, > > > > Hawkular Metrics, and APM. Projects like Inventory or the clients > > > > would > > > > fall under Hawkular Services umbrella. So rather than designing a > > > > generic > > > > structure with everything make individual sub-sites and then apply > > > > the > > > > structure you proposed. > > > > > > I think even if/when Hawkular-metrics gets its own section (which is > > > well > > > warranted as we create a metrics distribution), we need to make sure > > > that > > > it blends well into the Hawkular-services documentation. We can for > > > sure > > > use some include tags to accomplish this. I think Hawkular-services > > > should now be the main/default focus area of hawkular.org (at least > > > from the non-APM side) > > > > > > +1 > > > > > > > > > > > > Likewise we should also be careful with external documentation like > > > gitbook. I have seen some pretty good and comprehensive documentation > > > there, so the idea behind is good. An issue is certainly that it is yet > > > another > > > place for stuff and dilutes the content on hawkular.org . > > > Perhaps there is a way to include/iframe it, the experience could > > > potentially > > > be good, as some of the current (long) pages have issues with the > > > navigation > > > via the page-tree in the left part. > > > On the other hand (and I think this was mentioned already) there may be > > > a way to include content from hawkular.org into the gitbook, so that it > > > exists in both forms, but from one source (-> consistency) > > > > > > Agreed. > > > Gary could you look into the options to "blend" gitbook.io content > > > better > > > into hawkular.org ? > > > > > > Here is the reference point: > > > http://www.hawkular.org/docs/components/btm/index.html > > > Maybe iFraming > > > https://hawkular.gitbooks.io/hawkular-apm-user-guide/content/ > > > would work... > > > Maybe using a custom theme that adds our hawkular.org header/footer in > > > gitbook.io would work (I didn't see how to apply a theme to all books > > > though)... > > > > > > I gave you admin rights if you need to poke around, but I didn't see > > > anything > > > there that would help us... > > > > > > Thomas > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > > > > > > _______________________________________________ > > > hawkular-dev mailing list > > > hawkular-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > > > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Based on that suggestion, here is another proposal. Rectangle means a page Underline is more likely a section on a page Green arrows mean links (To Travis, to gitbook.io...) Let me know what you think of that updated section Thomas On Tue, Jun 14, 2016 at 10:32 PM, Stefan Negrea <snegrea(a)redhat.com&gt; wrote: > I do not see the idea proposed yet, but why not structure the website > around major projects? We have Hawkular community, Hawkular Services, > Hawkular Metrics, and APM. Projects like Inventory or the clients would > fall under Hawkular Services umbrella. So rather than designing a generic > structure with everything make individual sub-sites and then apply the > structure you proposed. > > The current website was designed when the direction of the community was > different so a re-org along the previous structure is not sufficient. > > Thank you, > Stefan Negrea > > On Tue, Jun 14, 2016 at 12:08 PM, Michael Burman <miburman(a)redhat.com&gt; > wrote: > >> Currently Heapster stores in internal memory few minutes of data and >> allows queries that request this data (through its REST-interface). The >> consume part will just request the data from the HWKMETRICS instead. >> >> - Micke >> >> ----- Original Message ----- >> From: "Thomas Heute" <theute(a)redhat.com&gt; >> To: "Discussions around Hawkular development" < >> hawkular-dev(a)lists.jboss.org&gt; >> Sent: Tuesday, June 14, 2016 4:09:40 PM >> Subject: Re: [Hawkular-dev] Hawkular.org >> >> >> >> On Tue, Jun 14, 2016 at 3:06 PM, Michael Burman < miburman(a)redhat.com > >> wrote: >> >> >> Consumers is terrible word for any client, as they both consume as well >> as produce the data. >> >> Well that was actually reflecting the current state, we have "things" >> that feed data to the server and "things" that consume data from the >> server. The client libraries provide an API to feed and consume. >> >> >> For example for Heapster, we currently produce the data, however at the >> moment I'm creating a change that will consume the data from HWKMETRICS. >> >> Why does it consume data now ? >> >> Thomas >> >> >> >> >> Integration / clients is far more used and known word, while >> consumer/producer is something more specific and implies a design pattern. >> >> - Micke >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > >

I think the structure is ok, but prefer having Downloads and Documentation at the top level. But instead of the previous structure, still organise based on package, so:

Documentation Hawkular Server (link) Quick Start ... Hawkular APM (link) ... Hawkular Metrics (link) ... Hawkular Clients Libraries Java ... Clients ... and similar for downloads. So top level is similar to first structure, but second tier is organised by package rather than book (in terms of docs). Regards Gary ----- Original Message ----- > Sorry, I meant to sent the PNG file... here it is > > On Wed, Jun 15, 2016 at 8:08 PM, Thomas Heute < theute(a)redhat.com > wrote: > > > > Based on that suggestion, here is another proposal. > > Rectangle means a page > Underline is more likely a section on a page > Green arrows mean links (To Travis, to gitbook.io...) > > Let me know what you think of that updated section > > Thomas > > On Tue, Jun 14, 2016 at 10:32 PM, Stefan Negrea < snegrea(a)redhat.com > wrote: > > > > I do not see the idea proposed yet, but why not structure the website around > major projects? We have Hawkular community, Hawkular Services, Hawkular > Metrics, and APM. Projects like Inventory or the clients would fall under > Hawkular Services umbrella. So rather than designing a generic structure > with everything make individual sub-sites and then apply the structure you > proposed. > > The current website was designed when the direction of the community was > different so a re-org along the previous structure is not sufficient. > > Thank you, > Stefan Negrea > > On Tue, Jun 14, 2016 at 12:08 PM, Michael Burman < miburman(a)redhat.com > > wrote: > > > Currently Heapster stores in internal memory few minutes of data and allows > queries that request this data (through its REST-interface). The consume > part will just request the data from the HWKMETRICS instead. > > - Micke > > ----- Original Message ----- > From: "Thomas Heute" < theute(a)redhat.com > > To: "Discussions around Hawkular development" < hawkular-dev(a)lists.jboss.org > > > Sent: Tuesday, June 14, 2016 4:09:40 PM > Subject: Re: [Hawkular-dev] Hawkular.org > > > > On Tue, Jun 14, 2016 at 3:06 PM, Michael Burman < miburman(a)redhat.com > > wrote: > > > Consumers is terrible word for any client, as they both consume as well as > produce the data. > > Well that was actually reflecting the current state, we have "things" that > feed data to the server and "things" that consume data from the server. The > client libraries provide an API to feed and consume. > > > For example for Heapster, we currently produce the data, however at the > moment I'm creating a change that will consume the data from HWKMETRICS. > > Why does it consume data now ? > > Thomas > > > > > Integration / clients is far more used and known word, while > consumer/producer is something more specific and implies a design pattern. > > - Micke > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On 16 Jun 2016, at 15:33, Stefan Negrea wrote: > On Thu, Jun 16, 2016 at 2:20 AM, Gary Brown <gbrown(a)redhat.com&gt; wrote: > >> I think the structure is ok, but prefer having Downloads and Documentation >> at the top level. But instead of the previous structure, still organise >> based on package, so: >> > > There is no point having top level Downloads and Documentation if > everything is sectioned the way Thomas proposed in the last email. There And then as user having to navigate separate trees to get e.g. to the downloads section of hawkular-services and the Go client is also confusing. Personally I'd like to see one top level of downloads or even downloads+docs | Project | Docs | Download latest |-----------------|-----------|---------------| | hawkular-services | docs/hs/.. | v0.0.5 | | go client | docs/go/.. | v 0.0.3 | With docs + downloads being hyperlinked

Individual subtrees could even link to this table for their downloads (but directly link to the target docs) _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Sorry, I meant to sent the PNG file... here it is On Wed, Jun 15, 2016 at 8:08 PM, Thomas Heute <theute(a)redhat.com&gt; wrote: > Based on that suggestion, here is another proposal. > > Rectangle means a page > Underline is more likely a section on a page > Green arrows mean links (To Travis, to gitbook.io...) > > Let me know what you think of that updated section > > Thomas > > On Tue, Jun 14, 2016 at 10:32 PM, Stefan Negrea <snegrea(a)redhat.com&gt; > wrote: > >> I do not see the idea proposed yet, but why not structure the website >> around major projects? We have Hawkular community, Hawkular Services, >> Hawkular Metrics, and APM. Projects like Inventory or the clients would >> fall under Hawkular Services umbrella. So rather than designing a generic >> structure with everything make individual sub-sites and then apply the >> structure you proposed. >> >> The current website was designed when the direction of the community was >> different so a re-org along the previous structure is not sufficient. >> >> Thank you, >> Stefan Negrea >> >> On Tue, Jun 14, 2016 at 12:08 PM, Michael Burman <miburman(a)redhat.com&gt; >> wrote: >> >>> Currently Heapster stores in internal memory few minutes of data and >>> allows queries that request this data (through its REST-interface). The >>> consume part will just request the data from the HWKMETRICS instead. >>> >>> - Micke >>> >>> ----- Original Message ----- >>> From: "Thomas Heute" <theute(a)redhat.com&gt; >>> To: "Discussions around Hawkular development" < >>> hawkular-dev(a)lists.jboss.org&gt; >>> Sent: Tuesday, June 14, 2016 4:09:40 PM >>> Subject: Re: [Hawkular-dev] Hawkular.org >>> >>> >>> >>> On Tue, Jun 14, 2016 at 3:06 PM, Michael Burman < miburman(a)redhat.com >>> > wrote: >>> >>> >>> Consumers is terrible word for any client, as they both consume as well >>> as produce the data. >>> >>> Well that was actually reflecting the current state, we have "things" >>> that feed data to the server and "things" that consume data from the >>> server. The client libraries provide an API to feed and consume. >>> >>> >>> For example for Heapster, we currently produce the data, however at the >>> moment I'm creating a change that will consume the data from HWKMETRICS. >>> >>> Why does it consume data now ? >>> >>> Thomas >>> >>> >>> >>> >>> Integration / clients is far more used and known word, while >>> consumer/producer is something more specific and implies a design pattern. >>> >>> - Micke >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

OTOH I would not want a totally separate structure for Hawkular Services *and* Hawkular Community, as they are very much the same except for some installation process (have to install C* separately or not) and maybe for additional parts in Community. The idea was to combined both into a single concept of server.

On Tue, Jul 5, 2016 at 3:19 AM, Thomas Heute <theute(a)redhat.com&gt; wrote: > > > On Thu, Jun 16, 2016 at 6:11 PM, Stefan Negrea <snegrea(a)redhat.com&gt; > wrote: > >> I really like this last revision because the content is sectioned along >> the way we deliver to users. So when a user navigates the website, the >> content is always related to what they can directly download and use and >> not mixed together. >> >> I have 3 small proposals: >> 1) Hawkular and Overview can be combined into one Hawkular Overview or >> Hawkular (which has the overview of the projects). >> > > This is more an issue with the representation in the mindmap I think. > Hawkular is really the homepage: http://www.hawkular.org/index.html and > I think we can remove the link since the link on the logo does the same > thing and it's quite a UXD standard. > Overview is a more detailed page: > http://www.hawkular.org/docs/overview.html a user should find it's way > among the various projects. > As long as we do not have two top menu entries, one for Hawkular and one for Overview, then the proposal makes sense. > > >> 2) The Grafana plugin should be moved under Metrics because is for >> Metrics and only Metrics. >> > > The Grafana plugins works with Metrics and Services > But it is a Metrics specific integration, no other services will ever integrate with Grafana.

> > >> 3) Hawkular Server should be renamed Hawkular Services because that the >> official project name. >> > > OTOH I would not want a totally separate structure for Hawkular Services > *and* Hawkular Community, as they are very much the same except for some > installation process (have to install C* separately or not) and maybe for > additional parts in Community. The idea was to combined both into a single > concept of server. > Agree here, what I suggested is that Hawkular Community is just a subsection in the Hawkular Services; and not two different sections. That will give more visibility to the concept of Hawkular Services rather than promote the unused name of Hawkular Server . > Thomas > > >> >> >> Thank you, >> Stefan Negrea >> >> Software Engineer >> >> On Wed, Jun 15, 2016 at 1:18 PM, Thomas Heute <theute(a)redhat.com&gt; wrote: >> >>> Sorry, I meant to sent the PNG file... here it is >>> >>> On Wed, Jun 15, 2016 at 8:08 PM, Thomas Heute <theute(a)redhat.com&gt; >>> wrote: >>> >>>> Based on that suggestion, here is another proposal. >>>> >>>> Rectangle means a page >>>> Underline is more likely a section on a page >>>> Green arrows mean links (To Travis, to gitbook.io...) >>>> >>>> Let me know what you think of that updated section >>>> >>>> Thomas >>>> >>>> On Tue, Jun 14, 2016 at 10:32 PM, Stefan Negrea <snegrea(a)redhat.com&gt; >>>> wrote: >>>> >>>>> I do not see the idea proposed yet, but why not structure the website >>>>> around major projects? We have Hawkular community, Hawkular Services, >>>>> Hawkular Metrics, and APM. Projects like Inventory or the clients would >>>>> fall under Hawkular Services umbrella. So rather than designing a generic >>>>> structure with everything make individual sub-sites and then apply the >>>>> structure you proposed. >>>>> >>>>> The current website was designed when the direction of the community >>>>> was different so a re-org along the previous structure is not sufficient. >>>>> >>>>> Thank you, >>>>> Stefan Negrea >>>>> >>>>> On Tue, Jun 14, 2016 at 12:08 PM, Michael Burman <miburman(a)redhat.com >>>>> > wrote: >>>>> >>>>>> Currently Heapster stores in internal memory few minutes of data and >>>>>> allows queries that request this data (through its REST-interface). The >>>>>> consume part will just request the data from the HWKMETRICS instead. >>>>>> >>>>>> - Micke >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Thomas Heute" <theute(a)redhat.com&gt; >>>>>> To: "Discussions around Hawkular development" < >>>>>> hawkular-dev(a)lists.jboss.org&gt; >>>>>> Sent: Tuesday, June 14, 2016 4:09:40 PM >>>>>> Subject: Re: [Hawkular-dev] Hawkular.org >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 14, 2016 at 3:06 PM, Michael Burman < >>>>>> miburman(a)redhat.com > wrote: >>>>>> >>>>>> >>>>>> Consumers is terrible word for any client, as they both consume as >>>>>> well as produce the data. >>>>>> >>>>>> Well that was actually reflecting the current state, we have >>>>>> "things" that feed data to the server and "things" that consume data from >>>>>> the server. The client libraries provide an API to feed and consume. >>>>>> >>>>>> >>>>>> For example for Heapster, we currently produce the data, however at >>>>>> the moment I'm creating a change that will consume the data from HWKMETRICS. >>>>>> >>>>>> Why does it consume data now ? >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Integration / clients is far more used and known word, while >>>>>> consumer/producer is something more specific and implies a design pattern. >>>>>> >>>>>> - Micke >>>>>> >>>>>> _______________________________________________ >>>>>> hawkular-dev mailing list >>>>>> hawkular-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

2) The Grafana plugin should be moved under Metrics because is for Metrics and only Metrics.

3) Hawkular Server should be renamed Hawkular Services because that the official project name.

Le 05/07/2016 à 14:59, Heiko W.Rupp a écrit : >> 2) The Grafana plugin should be moved under Metrics because is for Metrics >> > and only Metrics. > If this is true - can we make it work with H-services as well? > The Grafana plugin works with all active flavors of Metrics: standalone, Openshift-Metrics and Hawkular-Services. I'm not sure what Stefan meant.

On Tue, Jul 5, 2016 at 4:05 PM, Stefan Negrea <snegrea(a)redhat.com&gt; wrote: > On Tue, Jul 5, 2016 at 8:03 AM, Thomas Segismont <tsegismo(a)redhat.com&gt; > wrote: > >> >> >> Le 05/07/2016 à 14:59, Heiko W.Rupp a écrit : >> >> 2) The Grafana plugin should be moved under Metrics because is for >> Metrics >> >> > and only Metrics. >> > If this is true - can we make it work with H-services as well? >> > >> >> The Grafana plugin works with all active flavors of Metrics: standalone, >> Openshift-Metrics and Hawkular-Services. >> >> I'm not sure what Stefan meant. >> > > The Grafana plugins works with Metrics deployed on all distributions > however, the plugin itself can only be used with the Metrics project, there > are no projects (such as Alerts, or Inventory) that will ever integrate > with it. That is why I think it should be under the Metrics project and not > in another place. The integration itself is very specific to just Metrics, > not the entire Hawkular Services. > But then it applies to Hawkular services (the most important Hawkular project) and then should really shine there as much as for Metrics. We really need to think of Hawkular Metrics as a core part of Hawkular Services, not as a side project. Same for the documentation, the documentation to use metrics will need to be part of Hawkular Services documentation, not just a mere pointer to Hawkular metrics and let the user deal with the differences.

Thomas > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On Tue, Jul 5, 2016 at 5:35 PM, Stefan Negrea <snegrea(a)redhat.com&gt; wrote: > > On Tue, Jul 5, 2016 at 9:13 AM, Thomas Heute <theute(a)redhat.com&gt; wrote: > >> >> >> >> On Tue, Jul 5, 2016 at 4:05 PM, Stefan Negrea <snegrea(a)redhat.com&gt; >> wrote: >> >>> On Tue, Jul 5, 2016 at 8:03 AM, Thomas Segismont <tsegismo(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> Le 05/07/2016 à 14:59, Heiko W.Rupp a écrit : >>>> >> 2) The Grafana plugin should be moved under Metrics because is for >>>> Metrics >>>> >> > and only Metrics. >>>> > If this is true - can we make it work with H-services as well? >>>> > >>>> >>>> The Grafana plugin works with all active flavors of Metrics: >>>> standalone, >>>> Openshift-Metrics and Hawkular-Services. >>>> >>>> I'm not sure what Stefan meant. >>>> >>> >>> The Grafana plugins works with Metrics deployed on all distributions >>> however, the plugin itself can only be used with the Metrics project, there >>> are no projects (such as Alerts, or Inventory) that will ever integrate >>> with it. That is why I think it should be under the Metrics project and not >>> in another place. The integration itself is very specific to just Metrics, >>> not the entire Hawkular Services. >>> >> >> >> But then it applies to Hawkular services (the most important Hawkular >> project) and then should really shine there as much as for Metrics. >> >> We really need to think of Hawkular Metrics as a core part of Hawkular >> Services, not as a side project. >> >> Same for the documentation, the documentation to use metrics will need >> to be part of Hawkular Services documentation, not just a mere pointer to >> Hawkular metrics and let the user deal with the differences. >> > > > I am really not sure why the discussion took this turn, my comments were > not about Services vs Metrics. To refocus on the Grafana plugin, the plugin > is really specific to graphing actual metrics using the Metrics API only. > Let's not assume that people will take Hawkular Services and then combine themselves what is available to the metrics users with Hawkular Services. Hawkular Metrics really shines when used with Alerts and Inventory, let's have that package easy to use and consume. And if it makes sense to add alerts or inventory in the Grafana plugin, we should. Also if we have it along the other clients, it's more consistent. Thomas

> > > >> Thomas >> >> >> >> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

On Jul 5, 2016, at 10:21 AM, Thomas Segismont <tsegismo(a)redhat.com&gt; wrote: Le 05/07/2016 à 16:05, Stefan Negrea a écrit : > On Tue, Jul 5, 2016 at 8:03 AM, Thomas Segismont <tsegismo(a)redhat.com <mailto:tsegismo@redhat.com> > <mailto:tsegismo@redhat.com <mailto:tsegismo@redhat.com>>> wrote: > > > > Le 05/07/2016 à 14:59, Heiko W.Rupp a écrit : >>> 2) The Grafana plugin should be moved under Metrics because is for Metrics >>>> and only Metrics. >> If this is true - can we make it work with H-services as well? >> > > The Grafana plugin works with all active flavors of Metrics: standalone, > Openshift-Metrics and Hawkular-Services. > > I'm not sure what Stefan meant. > > > The Grafana plugins works with Metrics deployed on all distributions > however, the plugin itself can only be used with the Metrics project, > there are no projects (such as Alerts, or Inventory) that will ever > integrate with it. That is why I think it should be under the Metrics > project and not in another place. The integration itself is very > specific to just Metrics, not the entire Hawkular Services. I see what you meant now. But we can't presume anything about other services roadmaps. For example, the datasource plugin annotation feature could be implemented with requests to an event service. Anyway, since it should be able to connect to Metrics in different environments (H-Services, OS-Metrics and standalone), I err on the side of promoting it as a top level project.

So here is a very rough idea of how it would look like: http://209.132.178.114:10188/ Content need to be adapted, new pages to be created, but hopefully you get the idea On Tue, Jul 5, 2016 at 8:27 PM, John Sanda <jsanda(a)redhat.com&gt; wrote: > > On Jul 5, 2016, at 10:21 AM, Thomas Segismont <tsegismo(a)redhat.com&gt; > wrote: > > > > Le 05/07/2016 à 16:05, Stefan Negrea a écrit : > > On Tue, Jul 5, 2016 at 8:03 AM, Thomas Segismont <tsegismo(a)redhat.com > <mailto:tsegismo@redhat.com <tsegismo(a)redhat.com&gt;&gt;&gt; wrote: > > > > Le 05/07/2016 à 14:59, Heiko W.Rupp a écrit : > > 2) The Grafana plugin should be moved under Metrics because is for Metrics > > and only Metrics. > > If this is true - can we make it work with H-services as well? > > > The Grafana plugin works with all active flavors of Metrics: > standalone, > Openshift-Metrics and Hawkular-Services. > > I'm not sure what Stefan meant. > > > The Grafana plugins works with Metrics deployed on all distributions > however, the plugin itself can only be used with the Metrics project, > there are no projects (such as Alerts, or Inventory) that will ever > integrate with it. That is why I think it should be under the Metrics > project and not in another place. The integration itself is very > specific to just Metrics, not the entire Hawkular Services. > > > I see what you meant now. But we can't presume anything about other > services roadmaps. For example, the datasource plugin annotation feature > could be implemented with requests to an event service. > > Anyway, since it should be able to connect to Metrics in different > environments (H-Services, OS-Metrics and standalone), I err on the side > of promoting it as a top level project. > > > I think a top-level project makes the most sense. > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Thanks for the comments, I'm really looking more for feedback on the organization of the content, all the content is taken from the existing. For the 3rd point, the current website has 2 very similar pages (I only conserved one here as it was a quick shot, but the 2 needs to be merged) http://www.hawkular.org/community/index.html http://www.hawkular.org/community/join.html On Thu, Jul 7, 2016 at 11:37 AM, Alissa Bonas < abonas(a)redhat.com > wrote: Couple of suggestions: 1. In the "Hawkular features" section in homepage make the icons clickable. right now the only way to get more info is to click the "more" part. 2. Top level menu font color is a really pale grey so everything looks disabled. 3. Community-Connect leads to page named "Join". Perhaps it would more clear to make the link and the page name the same (and I would call it "Get involved" anyway) On Thu, Jul 7, 2016 at 11:58 AM, Thomas Heute < theute(a)redhat.com > wrote: So here is a very rough idea of how it would look like: http://209.132.178.114:10188/ Content need to be adapted, new pages to be created, but hopefully you get the idea On Tue, Jul 5, 2016 at 8:27 PM, John Sanda < jsanda(a)redhat.com > wrote: On Jul 5, 2016, at 10:21 AM, Thomas Segismont < tsegismo(a)redhat.com > wrote: Le 05/07/2016 à 16:05, Stefan Negrea a écrit : On Tue, Jul 5, 2016 at 8:03 AM, Thomas Segismont < tsegismo(a)redhat.com < mailto:tsegismo@redhat.com >> wrote: Le 05/07/2016 à 14:59, Heiko W.Rupp a écrit : 2) The Grafana plugin should be moved under Metrics because is for Metrics and only Metrics. If this is true - can we make it work with H-services as well? The Grafana plugin works with all active flavors of Metrics: standalone, Openshift-Metrics and Hawkular-Services. I'm not sure what Stefan meant. The Grafana plugins works with Metrics deployed on all distributions however, the plugin itself can only be used with the Metrics project, there are no projects (such as Alerts, or Inventory) that will ever integrate with it. That is why I think it should be under the Metrics project and not in another place. The integration itself is very specific to just Metrics, not the entire Hawkular Services. I see what you meant now. But we can't presume anything about other services roadmaps. For example, the datasource plugin annotation feature could be implemented with requests to an event service. Anyway, since it should be able to connect to Metrics in different environments (H-Services, OS-Metrics and standalone), I err on the side of promoting it as a top level project. I think a top-level project makes the most sense. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

I'm fine leaving the 3 top level projects, and it should definitely not grow. Note that I didn't expose Alerts there to not add confusion even though it can run on its own.

Thanks for the comments, I'm really looking more for feedback on the organization of the content, all the content is taken from the existing. For the 3rd point, the current website has 2 very similar pages (I only conserved one here as it was a quick shot, but the 2 needs to be merged) http://www.hawkular.org/community/index.html http://www.hawkular.org/community/join.html On Thu, Jul 7, 2016 at 11:37 AM, Alissa Bonas <abonas(a)redhat.com&gt; wrote: > Couple of suggestions: > > 1. In the "Hawkular features" section in homepage make the icons > clickable. right now the only way to get more info is to click the "more" > part. > 2. Top level menu font color is a really pale grey so everything looks > disabled. > 3. Community-Connect leads to page named "Join". Perhaps it would more > clear to make the link and the page name the same (and I would call it "Get > involved" anyway) > > > > > On Thu, Jul 7, 2016 at 11:58 AM, Thomas Heute <theute(a)redhat.com&gt; wrote: > >> So here is a very rough idea of how it would look like: >> http://209.132.178.114:10188/ >> >> Content need to be adapted, new pages to be created, but hopefully you >> get the idea >> >> On Tue, Jul 5, 2016 at 8:27 PM, John Sanda <jsanda(a)redhat.com&gt; wrote: >> >>> >>> On Jul 5, 2016, at 10:21 AM, Thomas Segismont <tsegismo(a)redhat.com&gt; >>> wrote: >>> >>> >>> >>> Le 05/07/2016 à 16:05, Stefan Negrea a écrit : >>> >>> On Tue, Jul 5, 2016 at 8:03 AM, Thomas Segismont <tsegismo(a)redhat.com >>> <mailto:tsegismo@redhat.com <tsegismo(a)redhat.com&gt;&gt;&gt; wrote: >>> >>> >>> >>> Le 05/07/2016 à 14:59, Heiko W.Rupp a écrit : >>> >>> 2) The Grafana plugin should be moved under Metrics because is for >>> Metrics >>> >>> and only Metrics. >>> >>> If this is true - can we make it work with H-services as well? >>> >>> >>> The Grafana plugin works with all active flavors of Metrics: >>> standalone, >>> Openshift-Metrics and Hawkular-Services. >>> >>> I'm not sure what Stefan meant. >>> >>> >>> The Grafana plugins works with Metrics deployed on all distributions >>> however, the plugin itself can only be used with the Metrics project, >>> there are no projects (such as Alerts, or Inventory) that will ever >>> integrate with it. That is why I think it should be under the Metrics >>> project and not in another place. The integration itself is very >>> specific to just Metrics, not the entire Hawkular Services. >>> >>> >>> I see what you meant now. But we can't presume anything about other >>> services roadmaps. For example, the datasource plugin annotation feature >>> >>> could be implemented with requests to an event service. >>> >>> Anyway, since it should be able to connect to Metrics in different >>> environments (H-Services, OS-Metrics and standalone), I err on the side >>> >>> of promoting it as a top level project. >>> >>> >>> I think a top-level project makes the most sense. >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Yes, I didn't rework the content of the pages, only the structure, but we'll definitely add with the project page links to the supported clients. Thomas On Thu, Jul 7, 2016 at 5:15 PM, Alissa Bonas <abonas(a)redhat.com&gt; wrote: > iirc we discussed adding an Events section (events as in > meetups/conferences) somewhere visible like front page? > Also, a summary of version compatibility matrix of all components with > each other would be helpful imo. > > On Thu, Jul 7, 2016 at 12:48 PM, Thomas Heute <theute(a)redhat.com&gt; wrote: > >> Thanks for the comments, I'm really looking more for feedback on the >> organization of the content, all the content is taken from the existing. >> >> For the 3rd point, the current website has 2 very similar pages (I only >> conserved one here as it was a quick shot, but the 2 needs to be merged) >> http://www.hawkular.org/community/index.html >> http://www.hawkular.org/community/join.html >> >> >> On Thu, Jul 7, 2016 at 11:37 AM, Alissa Bonas <abonas(a)redhat.com&gt; wrote: >> >>> Couple of suggestions: >>> >>> 1. In the "Hawkular features" section in homepage make the icons >>> clickable. right now the only way to get more info is to click the "more" >>> part. >>> 2. Top level menu font color is a really pale grey so everything looks >>> disabled. >>> 3. Community-Connect leads to page named "Join". Perhaps it would more >>> clear to make the link and the page name the same (and I would call it "Get >>> involved" anyway) >>> >>> >>> >>> >>> On Thu, Jul 7, 2016 at 11:58 AM, Thomas Heute <theute(a)redhat.com&gt; >>> wrote: >>> >>>> So here is a very rough idea of how it would look like: >>>> http://209.132.178.114:10188/ >>>> >>>> Content need to be adapted, new pages to be created, but hopefully you >>>> get the idea >>>> >>>> On Tue, Jul 5, 2016 at 8:27 PM, John Sanda <jsanda(a)redhat.com&gt; wrote: >>>> >>>>> >>>>> On Jul 5, 2016, at 10:21 AM, Thomas Segismont <tsegismo(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>> >>>>> >>>>> Le 05/07/2016 à 16:05, Stefan Negrea a écrit : >>>>> >>>>> On Tue, Jul 5, 2016 at 8:03 AM, Thomas Segismont <tsegismo(a)redhat.com >>>>> <mailto:tsegismo@redhat.com <tsegismo(a)redhat.com&gt;&gt;&gt; wrote: >>>>> >>>>> >>>>> >>>>> Le 05/07/2016 à 14:59, Heiko W.Rupp a écrit : >>>>> >>>>> 2) The Grafana plugin should be moved under Metrics because is for >>>>> Metrics >>>>> >>>>> and only Metrics. >>>>> >>>>> If this is true - can we make it work with H-services as well? >>>>> >>>>> >>>>> The Grafana plugin works with all active flavors of Metrics: >>>>> standalone, >>>>> Openshift-Metrics and Hawkular-Services. >>>>> >>>>> I'm not sure what Stefan meant. >>>>> >>>>> >>>>> The Grafana plugins works with Metrics deployed on all distributions >>>>> however, the plugin itself can only be used with the Metrics project, >>>>> there are no projects (such as Alerts, or Inventory) that will ever >>>>> integrate with it. That is why I think it should be under the Metrics >>>>> project and not in another place. The integration itself is very >>>>> specific to just Metrics, not the entire Hawkular Services. >>>>> >>>>> >>>>> I see what you meant now. But we can't presume anything about other >>>>> services roadmaps. For example, the datasource plugin annotation >>>>> feature >>>>> could be implemented with requests to an event service. >>>>> >>>>> Anyway, since it should be able to connect to Metrics in different >>>>> environments (H-Services, OS-Metrics and standalone), I err on the >>>>> side >>>>> of promoting it as a top level project. >>>>> >>>>> >>>>> I think a top-level project makes the most sense. >>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>>> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >>> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > >

Based on that suggestion, here is another proposal. Rectangle means a page Underline is more likely a section on a page Green arrows mean links (To Travis, to gitbook.io...) Let me know what you think of that updated section Thomas On Tue, Jun 14, 2016 at 10:32 PM, Stefan Negrea <snegrea(a)redhat.com&gt; wrote: > I do not see the idea proposed yet, but why not structure the website > around major projects? We have Hawkular community, Hawkular Services, > Hawkular Metrics, and APM. Projects like Inventory or the clients would > fall under Hawkular Services umbrella. So rather than designing a generic > structure with everything make individual sub-sites and then apply the > structure you proposed. > > The current website was designed when the direction of the community was > different so a re-org along the previous structure is not sufficient. > > Thank you, > Stefan Negrea > > On Tue, Jun 14, 2016 at 12:08 PM, Michael Burman <miburman(a)redhat.com&gt; > wrote: > >> Currently Heapster stores in internal memory few minutes of data and >> allows queries that request this data (through its REST-interface). The >> consume part will just request the data from the HWKMETRICS instead. >> >> - Micke >> >> ----- Original Message ----- >> From: "Thomas Heute" <theute(a)redhat.com&gt; >> To: "Discussions around Hawkular development" < >> hawkular-dev(a)lists.jboss.org&gt; >> Sent: Tuesday, June 14, 2016 4:09:40 PM >> Subject: Re: [Hawkular-dev] Hawkular.org >> >> >> >> On Tue, Jun 14, 2016 at 3:06 PM, Michael Burman < miburman(a)redhat.com > >> wrote: >> >> >> Consumers is terrible word for any client, as they both consume as well >> as produce the data. >> >> Well that was actually reflecting the current state, we have "things" >> that feed data to the server and "things" that consume data from the >> server. The client libraries provide an API to feed and consume. >> >> >> For example for Heapster, we currently produce the data, however at the >> moment I'm creating a change that will consume the data from HWKMETRICS. >> >> Why does it consume data now ? >> >> Thomas >> >> >> >> >> Integration / clients is far more used and known word, while >> consumer/producer is something more specific and implies a design pattern. >> >> - Micke >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Hi Currently only have one observation - under User Guide it has Hawkular Server and Hawkular Metrics - however I believe Metrics is part of Hawkular Server.

be based on packaging, as I guess that its usage will be the same (mostly) whether standalone or packaged? And where differences occur, then the guide can highlight the differences?

If this change is appropriate, then it might be possible for some/all of the 'clients' to be described under the functionality area they are related to.

Regards Gary ----- Original Message ----- > With the recent repackaging effort + the ManageIQ UI, we need to rethink > hawkular.org . > > It's tricky to keep it simple, what to download, for what usecase... And at > the moment it's getting outdated. > > IMO, it should be trivial for end users to figure out: > - What to download > - where to download and how to install the server > - find/browse/download the various options to feed the server with data (WF > agent, ptrans supported protocoles, ...) > - find/browse/download options to use/read the data: (ManageIQ, Grafana...) > > and for the developers > - find/browse/download the client libraries (Ruby, Python...) > - Find client libraries documentation > - Find examples... > > We should probably not separate/fork Hawkular Services from Hawkular > "community" too much, beside the installation procedure and few things that > we would mention as only available in the "larger" package. I use the term > "Hawkular Server" in the mind map for the 2 "flavors". > > Please propose improvements to the draft attached that represents the website > structure. (A square is not necessarily a page, it may be a section of a > page) > > Thomas > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

How will the common content between the Hawkular Server and Hawkular Metrics user guides be managed?

Although not related to structure - if we do continue to use gitbook for docs, I assume there will actually be a separate doc then for the installation and user guide - so in terms of the APM gitbook I will need to move the installation and API sections out? If so, could you create the repo for the APM installation guide, and also an agent guide.

Regards Gary ----- Original Message ----- > > On Tue, Jun 14, 2016 at 2:12 PM, Gary Brown < gbrown(a)redhat.com > wrote: > > > Hi > > Currently only have one observation - under User Guide it has Hawkular Server > and Hawkular Metrics - however I believe Metrics is part of Hawkular Server. > > is *also* part of Hawkular server, yes. > > > > So should the User Guide be broken down into functional areas, rather than be > based on packaging, as I guess that its usage will be the same (mostly) > whether standalone or packaged? And where differences occur, then the guide > can highlight the differences? > > Yes that the dilemma. As a user I think I would prefer based on packaging as > I want to have the documentation for what I am running, today there is a > split per functional area (actually it's per "component"), it makes it > harder to grasp what one can do and how, plus it's missing the link between > the components, as how to use them together. > > > Thomas. > > > If this change is appropriate, then it might be possible for some/all of the > 'clients' to be described under the functionality area they are related to. > > > > > > Regards > Gary > > ----- Original Message ----- > > With the recent repackaging effort + the ManageIQ UI, we need to rethink > > hawkular.org . > > > > It's tricky to keep it simple, what to download, for what usecase... And at > > the moment it's getting outdated. > > > > IMO, it should be trivial for end users to figure out: > > - What to download > > - where to download and how to install the server > > - find/browse/download the various options to feed the server with data (WF > > agent, ptrans supported protocoles, ...) > > - find/browse/download options to use/read the data: (ManageIQ, Grafana...) > > > > and for the developers > > - find/browse/download the client libraries (Ruby, Python...) > > - Find client libraries documentation > > - Find examples... > > > > We should probably not separate/fork Hawkular Services from Hawkular > > "community" too much, beside the installation procedure and few things that > > we would mention as only available in the "larger" package. I use the term > > "Hawkular Server" in the mind map for the 2 "flavors". > > > > Please propose improvements to the draft attached that represents the > > website > > structure. (A square is not necessarily a page, it may be a section of a > > page) > > > > Thomas > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > > > > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev