Re: [foreman-dev] Discourse - next steps / actions
Although I prefer to only migrate users list, if we decide to migrate both I would actually like to see foreman-announce to be migrated as well. We previously had issues sending plugin announcements into this low-volume list, it's a chance to change this and split it into announce-core and announce-plugins or something like that. I assume there would be an easy way of subscribing to those tags via RSS or email. LZ On Thu, Nov 23, 2017 at 5:31 PM, Greg Sutcliffe wrote: > Hi all, > > I'll try to keep this brief, at least by my standards :) > > Firstly, I think it's clear that the discussion is leaning towards > implementing Discourse for at least one, and possibly both, of the > mailing lists. Many people have contributed - I'd like to thank them all > for keeping this from descending into a flamewar :) > > We do need to give the users list a little longer for feedback (it's > only been a week), but I think here we can start to talk about the > migration planning. > > Since we all (or most?) need to start getting used to Discourse, I've > written up a draft migration plan there: > > https://community.theforeman.org/t/draft-migration-plan-theoretical/7550 > > I've just updated it to reflect the latest discussions. No doubt I have > missed something though, so I've made it into a wiki post - feel free to > edit with suggestions. > > There are two things I'd like to get input from people on: > > # Moderators > > I need a small team of moderators to deal with running the forum. I > don't expect it to take up much time, but it is important that more > people than just me know how things work. 3-4 people (including me) is > probably enough to start with. > > So, volunteers needed! Don't make me start picking on people :) > > # Choice of lists to migrate > > As above, we have to decide if we migrate both lists or just one. I see > significant benefits on having everyone on the same platform (top 2 - > the @groups feature is very useful for discussions, and the > discoverability of dev discussions for users helps them to get involved > and grow our dev community). However, I know others are more cautious > than I. > > Again, since we'll all likely be using Discourse in some capacity, I've > gone ahead and created a poll on Discourse for us. Please do leave your > feedback! Votes by email-response (here or on Discourse) are of course > acceptable for those allergic to UIs, I will add them in ;) > > https://community.theforeman.org/t/poll-which-lists-should-migrate-to-discourse/7598 > > I've not covered foreman-announce - we use this so infrequently, and > posting rights are heavily restricted, so I think we can decide what to > do with it later. > > Hang in there, we're getting to the fun bit! :) > Greg > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status
On Mon, Nov 20, 2017 at 05:36:29PM +, Ivan Necas wrote: po 20. 11. 2017 v 13:36 odesÃlatel Daniel Lobato Garcia napsal: On 11/20, Ohad Levy wrote: > On Sun, Nov 19, 2017 at 10:35 PM, Ewoud Kohl van Wijngaarden < > ew...@kohlvanwijngaarden.nl> wrote: > > > On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote: > > > >> > >> Can anyone shed some light on ETA for 1.16 GA? > >> > >> > > I should have given an update earlier. > > > > So far we've been wanting to include the foreman tasks as a service from > > core rather than from foreman-tasks. As always we want that change to first > > land in develop but we've been struggling with broken nightlies for quite > > some time. It loked like it was fixed since the builds started to pass > > aagin but we have no validation on the actual UI. Turns out that's broken > > and we have no automated testing for this. > > > > Would it be an option to ship 1.16 without dynflow service in the core or > > would that break things? > > > AFAIU - nothing uses it atm as we were uncertain if it can really be > used.. there is some code in core regarding that, so I'm not sure if that > matters... Daniel? It definitely can be used as proven by: https://github.com/theforeman/foreman/pull/4240 https://github.com/Katello/katello/pull/6750 https://github.com/Katello/katello/pull/6752 https://github.com/theforeman/foreman/pull/4717 Not having a separate service to run Dynflow doesn't have many implications now that nothing is using it. If foreman-tasks still ships the service to start/stop the dynflow executor, we're still fine (same as 1.15). Even without tasks, there's always a dynflow executor running with Foreman ( https://github.com/theforeman/foreman/blob/1.16-stable/config/application.rb#L245 ) but this one cannot be stopped or started without restarting Passenger too. If we decide for releasing without that, we need to put the files back into foreman tasks for 1.16: I would definitely rather see this resolved properly. Anythink we can help with? Right now we have verified it works on EL7 and are working on Debian. When that works, we will merge it to nightly. IMHO it's up to Daniel to make the call if we want to backport it to 1.16 since he's the release manager. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status
On Fri, 24 Nov 2017 at 14:12, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: > On Mon, Nov 20, 2017 at 05:36:29PM +, Ivan Necas wrote: > >po 20. 11. 2017 v 13:36 odesÃlatel Daniel Lobato Garcia < > elobat...@gmail.com> > >napsal: > > > >> On 11/20, Ohad Levy wrote: > >> > On Sun, Nov 19, 2017 at 10:35 PM, Ewoud Kohl van Wijngaarden < > >> > ew...@kohlvanwijngaarden.nl> wrote: > >> > > >> > > On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote: > >> > > > >> > >> > >> > >> Can anyone shed some light on ETA for 1.16 GA? > >> > >> > >> > >> > >> > > I should have given an update earlier. > >> > > > >> > > So far we've been wanting to include the foreman tasks as a service > >> from > >> > > core rather than from foreman-tasks. As always we want that change > to > >> first > >> > > land in develop but we've been struggling with broken nightlies for > >> quite > >> > > some time. It loked like it was fixed since the builds started to > pass > >> > > aagin but we have no validation on the actual UI. Turns out that's > >> broken > >> > > and we have no automated testing for this. > >> > > > >> > > Would it be an option to ship 1.16 without dynflow service in the > core > >> or > >> > > would that break things? > >> > > >> > > >> > AFAIU - nothing uses it atm as we were uncertain if it can really be > >> > used.. there is some code in core regarding that, so I'm not sure if > that > >> > matters... Daniel? > >> > >> It definitely can be used as proven by: > >> > >> https://github.com/theforeman/foreman/pull/4240 > >> https://github.com/Katello/katello/pull/6750 > >> https://github.com/Katello/katello/pull/6752 > >> https://github.com/theforeman/foreman/pull/4717 > >> > >> Not having a separate service to run Dynflow doesn't have many > >> implications now > >> that nothing is using it. > >> > >> If foreman-tasks still ships the service to start/stop the dynflow > >> executor, > >> we're still fine (same as 1.15). Even without tasks, there's always a > >> dynflow > >> executor running with Foreman > >> ( > >> > https://github.com/theforeman/foreman/blob/1.16-stable/config/application.rb#L245 > >> ) > >> but this one cannot be stopped or started without restarting Passenger > too. > > > > > >If we decide for releasing without that, we need to put the files back > into > >foreman tasks for 1.16: > >I would definitely rather see this resolved properly. Anythink we can help > >with? > > Right now we have verified it works on EL7 and are working on Debian. > When that works, we will merge it to nightly. IMHO it's up to Daniel to > make the call if we want to backport it to 1.16 since he's the release > manager. Glad to hear things got moving -- Ivan > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Foreman instrumentation for telemetry proposal
Glad to see this moving forward. Few questions: 1. what happened to the PCP approach we talked about in the past? 2. how would you integrate this to sosreport/foreman-debug? I'm thinking of storing the statsd data locally, collecting them with foreman-debug, and then, being able to import them later to the prometheus and other tools. Is this how this could work? Any other options? 3. does every host/runtime needs it's own statsd service, or there would be one shared process? Asking bith for multi-host and containers use-case The proposal of the telemetry api itself seems reasonable, let's discuss that on an actual PR -- Ivan On Tue, 21 Nov 2017 at 13:59, Lukas Zapletal wrote: > Thanks for question, this will be completely opt-in via > /etc/foreman/settings.yaml. You can turn off (default behavior when > not set), or on via prometheus, statsd or logging implementation (for > debugging purposes - sends stats to Rails log / production.log). > > On Mon, Nov 20, 2017 at 4:31 PM, Bryan Kearney > wrote: > > How would folks disable it opt out of sending this data? > > > > On Nov 20, 2017 9:46 AM, "Lukas Zapletal" wrote: > >> > >> Hey, > >> > >> on the last demo I presented my proposal for telemetry (it is actually > >> a separate video). I am looking for non-intrusive approach with broad > >> integration possibilities: > >> > >> https://www.youtube.com/watch?v=gCLSI9-4QpE > >> > >> This was also showed on our demo last week (the same content): > >> https://www.youtube.com/watch?v=QHzNIFjMpTM > >> > >> I am starting this thread to gather feedback before I open a PR with > >> this. Currently the code is mostly in Rails initializer and looks like > >> this: > >> > >> # get telemetry singleton instance and setup it > >> telemetry = Foreman::Telemetry.instance.setup(... some options ...) > >> > >> # register measurements > >> telemetry.add_counter(:http_requests, 'A counter of HTTP requests > >> made', [:controller, :action]) > >> telemetry.add_histogram(:http_request_total_duration, 'Total > >> duration', [:controller, :action]) > >> telemetry.add_counter(:activerecord_instances, 'Number of instances of > >> AR models', [:class]) > >> > >> # send measurements from Rails instrumentation or from code base > >> telemetry.increment_counter(:http_requests, 1, :controller => > >> controller, :action => action, :status => status) > >> telemetry.observe_histogram(:http_request_total_duration, duration, > >> :controller => controller, :action => action) > >> > >> The proposed API is a single class (a singleton actually) with three > >> registering methods and three measure methods. I don't think such a > >> simple class needs proper separation of concerns, but we can talk > >> about this in the PR. The registration part could be turned into some > >> kind of DSL, currently it takes metric name, description and list of > >> keys which will be part of an instance for those frameworks which do > >> not support arbitrary amount of key-value pairs. > >> > >> If there are no objections, I will add settings and better error > >> handling and file the PR. > >> > >> -- > >> Later, > >> Lukas @lzap Zapletal > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "foreman-dev" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to foreman-dev+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Later, > Lukas @lzap Zapletal > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] 1.17 branching - status update
On Thu, Nov 23, 2017 at 02:03:11PM +0100, Ondrej Prazak wrote: this is just a quick summary of where we stand with 1.17, please feel free to correct me if I got something wrong. #21546 is also blocking proxy registration on Debs. That's already on Rails 5 but EL7 is getting closer to switching over as well which means we'll likely be blocked on all platforms. https://projects.theforeman.org/issues/21564 -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Foreman instrumentation for telemetry proposal
> 1. what happened to the PCP approach we talked about in the past? Thats going in parallel, PCP is just a monitoring framework you can integrate with instrumentation data just like any other. > 2. how would you integrate this to sosreport/foreman-debug? I'm thinking of > storing the statsd data locally, collecting them with foreman-debug, and > then, being able to import them later to the prometheus and other tools. Is > this how this could work? Any other options? This is my ultimate goal to have working PCP deployment including telemetry data and archives could be collected by foreman-debug, they are pretty small (few MBs per day). > 3. does every host/runtime needs it's own statsd service, or there would be > one shared process? Asking bith for multi-host and containers use-case It is up to you if you want one statsd service per guest/container, host or subnet. Prometheus endpoint will not require any external daemon once sharing metrics is merged into upstream. For this reason, statsd will server as a temporary solution and alternative for the future. > The proposal of the telemetry api itself seems reasonable, let's discuss > that on an actual PR Thanks, I hope to finish it this year. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Discourse - next steps / actions
On 24/11/17 08:56, Lukas Zapletal wrote: > Although I prefer to only migrate users list, if we decide to migrate > both I would actually like to see foreman-announce to be migrated as > well. We previously had issues sending plugin announcements into this > low-volume list, it's a chance to change this and split it into > announce-core and announce-plugins or something like that. Completely agree. I'd like to see more use of whatever "announce channel" we end up going with - even if that's keeping the announce list and giving more people rights on it. > I assume there would be an easy way of subscribing to those tags via > RSS or email. Indeed there is, you can add ".rss" to any category, topic, or tag - we don't have an "announcement" tag yet, so here's an example for the "discussion" tag: https://community.theforeman.org/tags/discussion.rss Greg -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [foreman-dev] Discourse - next steps / actions
On 24/11/17 20:34, Greg Sutcliffe wrote: >> I assume there would be an easy way of subscribing to those tags >> via RSS or email. > > Indeed there is, you can add ".rss" to any category, topic, or tag.. Ugh, writing-emails-when-tired-- Forgot to add, email notifies for a tag are available from your user settings, just the same as for categories, so yes both RSS and email are possible. Greg -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
