Re: [foreman-dev] Propsing a move from Google Groups to Discourse

[Ivan Necas]

On Thu, 2 Nov 2017 at 19:35, Lukas Zapletal  wrote:

> Tried to reply with just few words and I am getting:
>
> We’re sorry, but your email message to
> [“theforeman.discourse+680bec16c469f36694d1ecef341e8...@gmail.com”]
> (titled Re: [TheForeman] [Testing Area] October newsletter) didn’t
> work.
> Reason:
> Body is too short (minimum is 20 characters)
> If you can correct the problem, please try again.
>
> I am gonna definitely hate this, can we turn this off? A reply of
> "yes" is still a valid one.


Hope so :)


>
> LZ
>
> On Wed, Nov 1, 2017 at 4:54 PM, Greg Sutcliffe 
> wrote:
> > Hi all,
> >
> > As ever from me, this is long. Sorry about that, it's a habit. Here's
> > the TL;DR:
> >
> > * What: move Google Groups -> Discourse
> > * Why: https://blog.discourse.org/category/use-cases/
> > * Can I try? - Scroll to the end for login details
> >
> > So, as some of you know, I'm a big fan of the Discourse[1] forum
> > software - I use it for another community, and it's just lovely. I've
> > been testing it out recently with a view to using it for Foreman, and
> > I think it's time to explain my reasoning and ask for your thoughts.
> >
> > # What?
> >
> > Firstly, the "what" - what do I want to do? Simply put, I want to
> > migrate from Google Groups to Discourse. That means locking the groups
> > from further emails and using Discourse for our "written" discussions.
> > Obviosuly there's data migration that needs to happen there, but we'll
> > get to that.
> >
> > Before all the die-hard mailing list fans stop reading here - please
> > keep reading. Discourse has options to interact entirely by email.
> > Your workflow may not be broken :)
> >
> > # Why?
> >
> > Why do I want this? The short version is "because anything is better
> > than Google Groups", but more seriously, I think Discourse is great.
> > The reasons are different for each of our mailing lists though, so let
> > me break it down:
> >
> > ## foreman-users
> >
> > When it comes to supporting our users, what matters is that they can
> > ask a question, get a reply, and feel confident in that reply. For
> > those who do the replying, they need to be highlight and in some way
> > rewarded for the work they do.
> >
> > The problem with a mailing list is that neither of these things is
> > really achievable. If a user (new to our list, who knows no-one) gets
> > 2 different replies, who is (s)he to trust? A forum can display user
> > levels, and badges, making the developer reply stand out from the
> > other new user's reply. A mailing list has nothing - and worse, the
> > Groups API is so bad that I barely know who our mailing list regulars
> > are (I have to webscrape it using a crawler ...) so I can reach out to
> > them for help, questions etc.
> >
> > Discourse also searches for likely similar topics *while* you're
> > typing yours. This should hopefully help users to find existing
> > support for their issue before they make duplicate posts :)
> >
> > For hard-working supporters, Discourse provides automatic "trust
> > levels" (in additional to manually promoting admins and moderators).
> > These trust levels allow you to unlock extra powers as you participate
> > in the community, which helps to reward the people who do help out on
> > the boards. Gamifying? yes, but it works. It'll also help me know who
> > to speak to when there's some swag to send out ...
> >
> > To make this worse (for Groups) there is a confounding of data in the
> > users-list today - we also use it for plugin announcements, and events
> > & CFPs, and so on. This is because making a new mailing list would
> > have a much smaller membership, making it not suitable for purpose.
> > Yes, you can say "hey we created a new mailing list for X, sign up!"
> > but the reality is that people just don't. Discourse gives us the
> > flexibility to create new boards for things as-and-when we feel the
> > need to.
> >
> > Discourse also supports plugins (its a rails app), so we can look at
> > things like templates for new support issues, and so on. It also has
> > bots which can be used to deal with some things (I have not
> > investigated the bots too much yet).
> >
> > ## foreman-dev
> >
> > In contrast to the -users list, which is primarily support and
> > notifications, dev is all about discussion. Here I think we'll see a
> > real benefit in a couple of areas.
> >
> > Firstly, back when we discussed how to handle RFCs, one of the
> > criticisms of a mailing list was the lack of rich format support
> > (markdown, images, code snippets etc) - Discourse supports all of
> > that. Quality of discussions should improve, I hope.
> >
> > Discourse also has "like" buttons which can be used in place of "+1"
> > emails, and hopefully would encourage some of the quiter voices in the
> > community to click the like button, even when they might not have
> > emailed a +1. There are also polling options, so taken together I
> > *hope* this will help us to resolve discussions better than we 

Re: [foreman-dev] Foreman instrumenting analysis

[Ivan Necas]

I lean towards the push model here. The main reason is
the simpler way to publish the instrumentation data from whatever
process we want to track. Also, my understanding is, that we don't care
only if the service is up or down (readiness and liveness) but also
about trends during the processing.

Eric: could you more describe the 5 web applications requiring 5
monitoring containers?
I might be missing where this implication came from?

-- Ivan

On Wed, Nov 1, 2017 at 4:54 PM, Lukas Zapletal  wrote:
>> Does Prometheus only not work in a multi-process Rails web server? Does it
>> work for a single process multi-threaded web server? This is an interesting
>> roadblock given you'd expect this to affect lots of webserver across
>> multiple languages out there.
>
> Any Rails app that has multiple processes needs currently to figure
> out how to deliver data to the HTTP endpoint. E.g. store it in a
> database or something, which is not the best approach.
>
> Absolutely, it lacks quite important feature right there. It stems
> from the design which is pull-based.
>
>> Yes, standard practice is to think about one container per pod (in a
>> Kubernetes environment). However, there are patterns for things like log
>> aggregation and monitoring such as doing a sidecar container that ensures
>> co-location. The part I don't entirely get with sidecars is if I scale the
>> pod to say 5, I get 5 web applications and 5 monitoring containers and that
>> seems odd. Which I why I think the tendency is towards models where your
>> single process/application is the end point for your metrics to be scrapped
>> by an outside agent or services.
>>
>> I agree you want the collector to be separate, but if your web application
>> is down what value would a monitoring endpoint being alive provide? The
>> application would be down, thus no metrics to serve up. The other exporters
>> such as the one exporting metrics about the underlying system would be
>> responsible for giving system metrics. In the Kube world, this is handled by
>> readiness and liveness probes for Kubenernetes to re-spin the container if
>> it stops responding.
>
> In container world, monitoring agents are running on hosts, not in
> containers themselves. And collector agents can be 1:1 or 1:N (e.g.
> for each container host). I am not sure I follow you here. Why you
> don't see added value again? Monitoring agent without any apps
> connected is as useful as ssh deamon waiting for connections.
>
> Let me put it this way - push approach seems to be more appropriate
> for multi process Ruby application than pull approach. That's what we
> are discussing here, unless there are better protocols/agents I am not
> aware of.
>
> Honestly, pull approach via simple HTTP REST API seems cleaner but it
> is just not good fit and also it creates other unnecessary
> responsibility on the app itself. You are working on containerizing
> Foreman, so it is also actually against this effort.
>
> Anyway, let me throw another integration. Collectd has an agent (or
> plugin) that opens a local socket which can be used to receive data
> from other applications. I wrote Ruby client library the other day
> (https://github.com/lzap/collectd-uxsock) but I believe this make no
> difference than statsd - you still need a local process to gather the
> data.
>
> --
> 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] Propsing a move from Google Groups to Discourse

[Lukas Zapletal]

Tried to reply with just few words and I am getting:

We’re sorry, but your email message to
[“theforeman.discourse+680bec16c469f36694d1ecef341e8...@gmail.com”]
(titled Re: [TheForeman] [Testing Area] October newsletter) didn’t
work.
Reason:
Body is too short (minimum is 20 characters)
If you can correct the problem, please try again.

I am gonna definitely hate this, can we turn this off? A reply of
"yes" is still a valid one.

LZ

On Wed, Nov 1, 2017 at 4:54 PM, Greg Sutcliffe  wrote:
> Hi all,
>
> As ever from me, this is long. Sorry about that, it's a habit. Here's
> the TL;DR:
>
> * What: move Google Groups -> Discourse
> * Why: https://blog.discourse.org/category/use-cases/
> * Can I try? - Scroll to the end for login details
>
> So, as some of you know, I'm a big fan of the Discourse[1] forum
> software - I use it for another community, and it's just lovely. I've
> been testing it out recently with a view to using it for Foreman, and
> I think it's time to explain my reasoning and ask for your thoughts.
>
> # What?
>
> Firstly, the "what" - what do I want to do? Simply put, I want to
> migrate from Google Groups to Discourse. That means locking the groups
> from further emails and using Discourse for our "written" discussions.
> Obviosuly there's data migration that needs to happen there, but we'll
> get to that.
>
> Before all the die-hard mailing list fans stop reading here - please
> keep reading. Discourse has options to interact entirely by email.
> Your workflow may not be broken :)
>
> # Why?
>
> Why do I want this? The short version is "because anything is better
> than Google Groups", but more seriously, I think Discourse is great.
> The reasons are different for each of our mailing lists though, so let
> me break it down:
>
> ## foreman-users
>
> When it comes to supporting our users, what matters is that they can
> ask a question, get a reply, and feel confident in that reply. For
> those who do the replying, they need to be highlight and in some way
> rewarded for the work they do.
>
> The problem with a mailing list is that neither of these things is
> really achievable. If a user (new to our list, who knows no-one) gets
> 2 different replies, who is (s)he to trust? A forum can display user
> levels, and badges, making the developer reply stand out from the
> other new user's reply. A mailing list has nothing - and worse, the
> Groups API is so bad that I barely know who our mailing list regulars
> are (I have to webscrape it using a crawler ...) so I can reach out to
> them for help, questions etc.
>
> Discourse also searches for likely similar topics *while* you're
> typing yours. This should hopefully help users to find existing
> support for their issue before they make duplicate posts :)
>
> For hard-working supporters, Discourse provides automatic "trust
> levels" (in additional to manually promoting admins and moderators).
> These trust levels allow you to unlock extra powers as you participate
> in the community, which helps to reward the people who do help out on
> the boards. Gamifying? yes, but it works. It'll also help me know who
> to speak to when there's some swag to send out ...
>
> To make this worse (for Groups) there is a confounding of data in the
> users-list today - we also use it for plugin announcements, and events
> & CFPs, and so on. This is because making a new mailing list would
> have a much smaller membership, making it not suitable for purpose.
> Yes, you can say "hey we created a new mailing list for X, sign up!"
> but the reality is that people just don't. Discourse gives us the
> flexibility to create new boards for things as-and-when we feel the
> need to.
>
> Discourse also supports plugins (its a rails app), so we can look at
> things like templates for new support issues, and so on. It also has
> bots which can be used to deal with some things (I have not
> investigated the bots too much yet).
>
> ## foreman-dev
>
> In contrast to the -users list, which is primarily support and
> notifications, dev is all about discussion. Here I think we'll see a
> real benefit in a couple of areas.
>
> Firstly, back when we discussed how to handle RFCs, one of the
> criticisms of a mailing list was the lack of rich format support
> (markdown, images, code snippets etc) - Discourse supports all of
> that. Quality of discussions should improve, I hope.
>
> Discourse also has "like" buttons which can be used in place of "+1"
> emails, and hopefully would encourage some of the quiter voices in the
> community to click the like button, even when they might not have
> emailed a +1. There are also polling options, so taken together I
> *hope* this will help us to resolve discussions better than we have
> historically.
>
> The ability to create dedicated boards for popular plugins is also
> pretty nice, if we decide to go that way.
>
> ## foreman-announce
>
> This list has historically been very low traffic. On Discourse, the
> most useful feature for this purpose is the 

AW: [foreman-dev] Propsing a move from Google Groups to Discourse

[Matthias Dellweg]

Hi Greg,
so you tested the happy flow. But as a scientist i must ask you, did you check
the opposite, too? Does someone not being the author nor a member of the 
mentioned
group not receive the notification?
cheers

Herzliche Grüße aus München

Matthias Dellweg

-Ursprüngliche Nachricht-
> Von:Greg Sutcliffe 
> Gesendet: Donnerstag 2 November 2017 17:51
> An: foreman-dev@googlegroups.com
> Betreff: Re: [foreman-dev] Propsing a move from Google Groups to Discourse
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> A quick update on some testing John Mitsch & I did today. It seems
> @groups support is pretty nice.
> 
> We created a Katello group with John in it, and then I created a post
> and mentioned @katello in the text. This correct notified John by both
> UI and email (as per his preferences, thats confiurable ofc).
> 
> In short, creating groups for plugins, packaging, UI, etc is very much
> possible and should work well.
> 
> Greg
> -BEGIN PGP SIGNATURE-
> 
> iHYEARECADYWIQT6/Mr3yf+h5OF468Tw7tE3ygrrkwUCWftNGBgcZ3JlZ0BlbWVy
> YWxkcmV2ZXJpZS5vcmcACgkQ8O7RN8oK65NKswCePsELYzE5f5F5Zws4tZ3MB2oe
> m1cAnRzsszjr/yXCiK3UVGA58uQUCmbz
> =9XBj
> -END PGP SIGNATURE-
> 
> -- 
> 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] Moving katello puppet modules to the foreman github namespace

[Eric D Helms]

I am ready to move them when you give the green light.

My inclination for permissions and team setup would be to maintain all
individual maintership on the modules to date. Further, to take the katello
installer team and add them to a similar installer team on theforeman
organization.

On Thu, Nov 2, 2017 at 12:38 PM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> Hello all,
>
> Previously this has been discussed in various threads but now we're ready
> to make it a reality. All modules should be ready to use a single
> modulesync repository and a pull request has been opened.
> https://github.com/theforeman/foreman-installer-modulesync/pull/78
> lists all tasks that need to be completed.
>
> Some important things to note:
>
> * We invite users to submit redmine issues to the foreman installer
> project. Previously we only pointed them to Redmine without specific
> directions.
> * We will continue to publish modules on the puppet forge under the
> katello user. Moving modules there requires a bit more effort for  little
> benefit.
> * This does (not yet) include merging the installers. For now
> foreman-installer won't ship the katello modules.
>
> --
> 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.
>



-- 
Eric D. Helms
Red Hat Engineering

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Propsing a move from Google Groups to Discourse

[Greg Sutcliffe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A quick update on some testing John Mitsch & I did today. It seems
@groups support is pretty nice.

We created a Katello group with John in it, and then I created a post
and mentioned @katello in the text. This correct notified John by both
UI and email (as per his preferences, thats confiurable ofc).

In short, creating groups for plugins, packaging, UI, etc is very much
possible and should work well.

Greg
-BEGIN PGP SIGNATURE-

iHYEARECADYWIQT6/Mr3yf+h5OF468Tw7tE3ygrrkwUCWftNGBgcZ3JlZ0BlbWVy
YWxkcmV2ZXJpZS5vcmcACgkQ8O7RN8oK65NKswCePsELYzE5f5F5Zws4tZ3MB2oe
m1cAnRzsszjr/yXCiK3UVGA58uQUCmbz
=9XBj
-END PGP SIGNATURE-

-- 
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.

[foreman-dev] Moving katello puppet modules to the foreman github namespace

[Ewoud Kohl van Wijngaarden]

Hello all,

Previously this has been discussed in various threads but now we're 
ready to make it a reality. All modules should be ready to use a single 
modulesync repository and a pull request has been opened.

https://github.com/theforeman/foreman-installer-modulesync/pull/78
lists all tasks that need to be completed.

Some important things to note:

* We invite users to submit redmine issues to the foreman installer 
 project. Previously we only pointed them to Redmine without specific 
 directions.
* We will continue to publish modules on the puppet forge under the 
 katello user. Moving modules there requires a bit more effort for 
 little benefit.
* This does (not yet) include merging the installers. For now 
 foreman-installer won't ship the katello modules.


--
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] Building a Rails 5.1 SCL

[Lukas Zapletal]

Big +1 to all of that.

I think COPR provides some own GPG keys and IIRC you can't override
those. It is possible to download packages from COPR and sign them
again with a custom key of course. That's perhaps your plan I guess.
Custom signatures is on COPR development TODO I think.

LZ

On Wed, Nov 1, 2017 at 7:00 PM, Eric D Helms  wrote:
> In a previous thread [1], we discussed building an SCL vs. vendorizing gems
> and the general consensus was to build an SCL. This thread is to outline a
> starting plan for how to build and maintain a Rails 5.1 SCL. I invite and
> appreciate comments towards this design.
>
> I'll begin by laying out some overall goals for the effort, a general
> proposal of information and finally a breakdown of the why for each of the
> proposal items to better explain my thinking.
>
>
> Goals
>
>  * Stand alone Rails 5.1 SCL and repository
>  * Owned and maintained by the Foreman community
>  * Easy to update and maintain
>  * Strive for automation and package tooling to reduce maintenance cost
>
>
> Proposal
>
> Build location: Copr
> SCL Name: tfm-ror51
> Git repository: theforeman/tfm-ror51-packaging
> Hosted: yum.theforeman.org/rails/tfm-ror51
> RPM Signing: signed by unique Foreman owned GPG key
> Tooling Repo: create package tooling repository separate from
> tfm-ror51-packaging repo
> Tooling Technology: Ansible
>
>
> Breakdown
>
> Build Location
>
> There has been discussion around moving our RPM builds to Copr and off of
> Koji. This will require shifting our configuration and setup, testing and
> working out kinks in Copr workflow. Building this Rails SCL provides us an
> opportunity to use Copr from the start, get familiar with it and workout
> tooling to interact with and manage a repository there. Therefore, I am
> proposing to start with Copr from the get go and avoid Koji.
>
> SCL Name
>
> Given the Foreman community will own the SCL, and our SCL namespace is 'tfm'
> I am suggesting we follow convention by naming it tfm-ror51. Previous Rails
> SCLs, were named similarly: rh-ror41, rh-ror42, sclo-ror42.
>
> Git Repository
>
> I am proposing we don't put this into foreman-packaging given the lifecycle
> of the SCL will not follow that of Foreman. Further, with the goal to create
> a stand-alone Rails SCL repository this should have its own lifecycle.
>
> Hosted
>
> We could point at the direct Copr repository, and reduce our bandwidth.
> However, since we own this Rails SCL I believe we should host it as such
> officially. Further, this would allow us to do some pre-flight testing by
> building a repository in Copr, running a test of either the SCL itself
> and/or Foreman against the SCL updates before promoting.
>
> RPM Signing
>
> I am recommending here that we sign the SCL RPMs with a new GPG key
> generated just for signing the SCL packages.
>
> Tooling
>
> With an eye towards foreman-packaging changes, I am proposing we create a
> separate git repository for all package tooling. The goal here would to
> build out new tooling to allow easier maintenance of the packaging and
> repository.  This will allow the tooling to evolve independently of either
> packaging repository.  Further, when applying this tooling to
> foreman-packaging later, the tooling would not have to be duplicated across
> branches.
>
> Tooling Technology
>
> I am proposing a centralization on Ansible as the tooling technology for a
> number of reasons. First, I feel that it has a low barrier to entry while
> providing a mix of high and low level interfaces. Secondly, Ansible allows
> orchestrating and building out more complex and directed tasks. Third, a
> team of us has some built out Ansible tooling that has been working well for
> us in another area that would be easy to port for packaging management. I
> personally think bash is complex to understand for complex actions and is
> too simple for building up a set of cohesive tooling.
>
> --
> Eric D. Helms
> Red Hat Engineering
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+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: [foreman-dev] Building a Rails 5.1 SCL

[Ewoud Kohl van Wijngaarden]

On Wed, Nov 01, 2017 at 02:00:29PM -0400, Eric D Helms wrote:

In a previous thread [1], we discussed building an SCL vs. vendorizing gems
and the general consensus was to build an SCL. This thread is to outline a
starting plan for how to build and maintain a Rails 5.1 SCL. I invite and
appreciate comments towards this design.

I'll begin by laying out some overall goals for the effort, a general
proposal of information and finally a breakdown of the why for each of the
proposal items to better explain my thinking.


Goals

* Stand alone Rails 5.1 SCL and repository
* Owned and maintained by the Foreman community
* Easy to update and maintain
* Strive for automation and package tooling to reduce maintenance cost


Proposal

Build location: Copr
SCL Name: tfm-ror51
Git repository: theforeman/tfm-ror51-packaging
Hosted: yum.theforeman.org/rails/tfm-ror51
RPM Signing: signed by unique Foreman owned GPG key
Tooling Repo: create package tooling repository separate from
tfm-ror51-packaging repo
Tooling Technology: Ansible


Breakdown

Build Location

There has been discussion around moving our RPM builds to Copr and off of
Koji. This will require shifting our configuration and setup, testing and
working out kinks in Copr workflow. Building this Rails SCL provides us an
opportunity to use Copr from the start, get familiar with it and workout
tooling to interact with and manage a repository there. Therefore, I am
proposing to start with Copr from the get go and avoid Koji.


+1


SCL Name

Given the Foreman community will own the SCL, and our SCL namespace is
'tfm' I am suggesting we follow convention by naming it tfm-ror51. Previous
Rails SCLs, were named similarly: rh-ror41, rh-ror42, sclo-ror42.


+1 though we could look at creating a CentOS SIG to do it under the sclo 
flag. IMHO this can be parallel to the development or even after the 
fact.



Git Repository

I am proposing we don't put this into foreman-packaging given the lifecycle
of the SCL will not follow that of Foreman. Further, with the goal to
create a stand-alone Rails SCL repository this should have its own
lifecycle.


+1


Hosted

We could point at the direct Copr repository, and reduce our bandwidth.
However, since we own this Rails SCL I believe we should host it as such
officially. Further, this would allow us to do some pre-flight testing by
building a repository in Copr, running a test of either the SCL itself
and/or Foreman against the SCL updates before promoting.


+1

This would be similar to how we now have koji: as a staging ground, we 
test against this and promote if it's stable with the added benefit that 
it's easier to consume.



RPM Signing

I am recommending here that we sign the SCL RPMs with a new GPG key
generated just for signing the SCL packages.


COPR signs repos by default with its own GPG key. Do you want a separate 
GPG key when we host it on yum.theforeman.org?



Tooling

With an eye towards foreman-packaging changes, I am proposing we create a
separate git repository for all package tooling. The goal here would to
build out new tooling to allow easier maintenance of the packaging and
repository.  This will allow the tooling to evolve independently of either
packaging repository.  Further, when applying this tooling to
foreman-packaging later, the tooling would not have to be duplicated across
branches.


+1


Tooling Technology

I am proposing a centralization on Ansible as the tooling technology for a
number of reasons. First, I feel that it has a low barrier to entry while
providing a mix of high and low level interfaces. Secondly, Ansible allows
orchestrating and building out more complex and directed tasks. Third, a
team of us has some built out Ansible tooling that has been working well
for us in another area that would be easy to port for packaging management.
I personally think bash is complex to understand for complex actions and is
too simple for building up a set of cohesive tooling.


For me this depends. If an ansible playbook is just a list of commands 
then IMHO it doesn't add much value over a shell script. If you use 
higher level tools (modules?) then there's a great benefit in both 
readability and maintainability. I could see us developing a copr module 
so we can use copr_build and such.


--
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] Building a Rails 5.1 SCL

[Ewoud Kohl van Wijngaarden]

On Thu, Nov 02, 2017 at 11:24:26AM +0100, Daniel Lobato Garcia wrote:

Just one question, my understanding is that you prefer to do this (SCL)
because we are uncertain of the time/effort required for vendoring the gems/npm
packages. Given that long-term we would have to keep up building SCLs
(which if I’m not wrong are going to be less used from EL8 onward) and 
maintaining
packages (which consumes a great deal of our time).


My expectation is that vendorizing RPMs would cost a similar time as 
building the SCL. Given separate packaging has a lot of benefits over 
bundling[1].


Thinking about this, we currently don't check the licenses of bundled 
npm modules in our existing packaging. It's possible we currently ship 
something we're not legally allowed to ship but we simply don't know.o


With regards to EL8 I think you're hinting at the modularization effort 
that's currently in Fedora. For those unaware: it's aimed to be a much 
better version of SCLs. Better integrated in the system but also allow 
easily producing containers. At the moment there's still little 
documentation and we'll likely support EL7 for a while so at this point 
I'm not planning much. What we do want to do is move from our own Koji 
instance to COPR. That should be prepared for modularization. Developing 
the SCL in COPR can be seen as a first step in this process.


[1]: 
https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries#Why_Bundled_Libraries_are_a_problem


Parallel to this effort, do you think it’s worth moving forward with the
vendorization of npm so that gems can follow suit?


Personally I'd say gems shouldn't follow suit unless maintaining the SCL 
proves too much work. In fact, the only reason I currently accept npm 
vendorization is that we currently can't keep up with the changes. If we 
can develop sufficient tooling I'd actually like to roll back npm 
vendorization too when we can provide the same developer flexibility.


--
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] Building a Rails 5.1 SCL

[Daniel Lobato Garcia]

I agree with all of that, definitely something to do in a different repository.

Just one question, my understanding is that you prefer to do this (SCL)
because we are uncertain of the time/effort required for vendoring the gems/npm
packages. Given that long-term we would have to keep up building SCLs
(which if I’m not wrong are going to be less used from EL8 onward) and 
maintaining
packages (which consumes a great deal of our time).

Parallel to this effort, do you think it’s worth moving forward with the
vendorization of npm so that gems can follow suit?

--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato

-- 
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: PGP signature

Re: [foreman-dev] Propsing a move from Google Groups to Discourse

[Greg Sutcliffe]

I appreciate I tend to write a thousand words when pictures might do.
Here's one shot from the metrics (which may or may not be accurate as
it depends on the MBOX importer being correct, but you get the idea),
one from the foreman-users list index, and one from the markdown
version of this post (to which I added a poll... because I can).

* Metrics (no, I don;t know what the y-axis is either, yet...)
  https://imgur.com/vpv15b1

* Foreman-users
  https://imgur.com/0Wetjo1

* This thread
  https://imgur.com/Umc3gaW

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: This is a digitally signed message part

Re: [foreman-dev] Propsing a move from Google Groups to Discourse

[Greg Sutcliffe]

On Wed, 2017-11-01 at 14:15 -0400, Andrew Kofink wrote:
> I admit, I skimmed the prior emails (they were tl). I just wanted to
> ask if discourse is searchable/is indexed from the wider internet.
> I've often found relevant mailing list discussions by searching from
> Google, and I really value that.

I thought about this some more overnight - we're actually gaining here.
We often see users quoting *old* posts which are no longer accurate
because the code has moved on - with a list we can't do anything about
that. With Discourse we can update or flag those posts in some way and
redirect users to a better/newer one.

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: This is a digitally signed message part

Re: [foreman-dev] Merge permission for theforemen/foreman-ansible-modules

[Evgeni Golov]

+1 here too

On Wed, Nov 1, 2017 at 8:29 PM, Eric D Helms  wrote:
> +1 from me as well (I'll aim to add you in the requisite 5 more days
> depending on the further outcome)
>
> On Wed, Nov 1, 2017 at 3:24 PM, Ewoud Kohl van Wijngaarden
>  wrote:
>>
>> +1 while I haven't looked at his ansible work that closely I have seen
>> that he's already behaving like an excellent maintainer: good reviews,
>> active and generally a good and friendly person to have around.
>>
>> On Mon, Oct 30, 2017 at 11:46:34AM -0400, Andrew Kofink wrote:
>>>
>>> +1 from me! We have benefited greatly from Matthias' contributions in
>>> foreman-ansible-modules. If you'd like to see some of his work, here are
>>> his merged PRs
>>>
>>> ,
>>> and here are all the PRs he has helped to review
>>>
>>> 
>>> .
>>>
>>> On Mon, Oct 30, 2017 at 11:34 AM, Matthias Dellweg 
>>> wrote:
>>>
 Hello,
 i was just encouraged, to ask for merge/push permission in
 theforeman/foreman-ansible-modules.
 I have contributed to this repository almost since the beginning (yes,
 it's a very young one),
 and did a hand full of reviews that lead to constructive discussions.
 The
 collaboration with
 Andrew, Eric and Evgeni have always been very fruitful from my
 perspective.
 For co-inventing the DRY glue layer 'cement' (with fobheb), github
 classifies me as the top
 garbage collector with by far the most removed lines.

 I ask you kindly to vote, whether i shall be entrusted with the power of
 the merge.
 Thanks for considering,
   Matthias
>>
>>
>> --
>> 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.
>
>
>
>
> --
> Eric D. Helms
> Red Hat Engineering
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Beste Grüße/Kind regards,

Evgeni Golov
Software Engineer

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander

-- 
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.