Re: [foreman-dev] Re: Discourse - upcoming dates

[Marek Hulán]

Dne neděle 10. prosince 2017 23:06:19 CET, Greg Sutcliffe napsal(a):
> Just a short update on this - tomorrow is the day on my date list for
> the announcement, but today is actually T-3weeks, so I'll be sending
> that out to both lists in just a few minutes.
> 
> The result, as I spoke about on the demo this week, is fairly clear -
> while we have some cautious voices (and I thank them for keeping our
> feet on the ground :P), we will be moving everything to Discourse. I've
> tried to make sure that the concerns we *can* address outside of the
> obvious "one list or two?" question are handled, but more suggestions
> are welcome as we go forward.
> 
> To Lukas' point about foreman-announce - I've created a Release
> Announcements category which can be used for this purpose, which
> currently only moderators can post to. I'm happy to widen those
> permissions, perhaps via a group that can post there - I agree we should
> announce more things. Thoughts on this are welcome.
> 
> Handily (for those that use RSS) you can also use this category via RSS,
> which is a nice bonus. Try:
> 
> https://community.theforeman.org/c/release-announcements.rss
> 
> Might be useful for the new RSS feature in core? :)

There's just one feed that people can add. I guess the blog one is still more 
important and I think we should announce releases there too. It seems we only 
cover it in newsletters.

--
Marek

> The migration plan is now being enacted, and anyone who wants to proof
> read it (or any of the forum docs I'm writing) will make me very
> grateful indeed!
> 
> Cheers
> 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.

Re: [foreman-dev] Kanban tools and redmine

[Marek Hulán]

Dne středa 29. listopadu 2017 9:05:28 CET, Lukas Zapletal napsal(a):
> Can you elaborate on why something does not make sense to track in
> RedMine? I am not following, RedMine is a generic ticketing system and
> you can create as many tickets as you want, e.g. Buy milk. It will
> work. This is a dogma I do not take as an argument. What's relevant is
> if you need to create private work items, but we do have a private
> feature in RedMine and we use it from time to time. And frankly, we
> don't need these very often (mostly security issues).

Sorry for answering someone else question, but from my experience, redmine is 
great for tracking dev stuff, including back traces, links to PR, BZ, release 
that includes the fix etc. Stuff like buy milk that does not hopefully have a 
backtrace is easier to track in some board as it's easier to manipulate. More 
realistically, things like "review PR $number" is easier to add and track in 
more lightweight system. I think these are simply two different use cases and 
I'm fine using two different tools for them.

So for me, I'd prefer to keep using what I need, redmine and some board and 
not trying to combine both together.

--
Marek

> If you look to the past, various scrum teams tried dozens off tools.
> But hey, you know what is still here? RedMine (and RHBZ of course :-)
> - those systems survived. My sole opinion is let's ditch RedMine and
> use RHBZ for everything, many open source projects do this. But I
> understand many people cannot live with Bugzilla, that's fine. OK!
> Let's just stick to RedMine then. If people want to try RedMine
> plugins, I totally do support that. What I really like is to have
> everything in one place - no copies.
> 
> Historically, there have been problems with RedMine plugins for scrum,
> it was overloading the server when whole team was moving tickets. But
> we might upgraded to better hosting how, if infrateam approves I am
> all for trying anything that is a RedMine plugin and works with
> regular issues.
> 
> This could be a chance to setup "staging" redmine, since we still have
> some knowledge from the migration. There we can test it on our current
> data and vote how we like it.
> 
> LZ
> 
> On Wed, Nov 29, 2017 at 8:00 AM, Ivan Necas  wrote:
> > My uderstanding of kanban is, that moving the cards manually on the signal
> > board is actually part of the kanban way of doing things. Another thing,
> > that is integrated part of the kanban process is
> > WIP limits, that I don't even see on the redmine plugin. Another reason
> > for
> > actually not using
> > redmine for this is the rasks, that don't make sense to actually track in
> > redmine.
> > 
> > I have a pr to nice Marek's tooling around automating some common actions
> > around
> > Kanboard https://github.com/ares/kansync/pull/5 and so far, I'm happy with
> > this.
> > 
> > -- Ivan
> > 
> > út 28. 11. 2017 v 22:37 odesílatel Andrew Kofink 
> > 
> > napsal:
> >> I'm open to using other kanban style tools. To me it doesn't really
> >> matter
> >> that much how we plan - it's the same information just in a different
> >> format. So, if people have reasons, then I'm fine with switching.
> >> 
> >> On Tue, Nov 28, 2017 at 4:29 PM, Walden Raines  
wrote:
> >>> Hey,
> >>> 
> >>> With several teams moving to kanban style tools for the visualization of
> >>> tasks I'm wondering if anyone has tried redmine's PluginKanban [1].
> >>> 
> >>> I really like the idea of a trello/kanboard like tool but I hate having
> >>> to update tasks in multiple places.  Another idea I had was to switch
> >>> (back) to using GH issues and use GH projects [2] as well.
> >>> 
> >>> Any other thoughts on how to make these kanban boards work better with
> >>> redmine?
> >>> 
> >>> Cheers,
> >>> Walden
> >>> 
> >>> [1] http://www.redmine.org/projects/redmine/wiki/PluginKanban
> >>> [2] https://help.github.com/articles/about-project-boards/
> >>> 
> >>> --
> >>> 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.
> >> 
> >> --
> >> Andrew Kofink
> >> akof...@redhat.com
> >> IRC: akofink
> >> Software Engineer
> >> Red Hat Satellite
> >> 
> >> --
> >> 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 

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Marek Hulán]

Dne středa 29. listopadu 2017 14:36:18 CET, Ewoud Kohl van Wijngaarden 
napsal(a):
> On Wed, Nov 29, 2017 at 02:18:35PM +0100, Lukas Zapletal wrote:
> >> Bikeshedding about SemVer aside, I'm good with doing a 2.0 release in
> >> the near future, but *please* lets use it to deprecate / drop stuff we
> >> no longer want to maintain. Otherwise there's no real point to it.
> >
> >I agree we can take this "opportunity" to drop some deprecated things
> >like V1 API, but I don't see many other things. We are pretty good in
> >deprecating things using our "two releases" rule which should be
> >followed no matter if we bump major version or not.
> 
> +1 this is very similar to Django's release policy: in 1.x it was x
> deprecated and x+2 removed. Starting 2.0 they'll follow semver. I'd
> suggest we do the same.
> 
> >Let's not block 2.0 with any feature, I wrote the reasons, if we fit
> >in some deprecation work why not. But's let's agree on 2.0 timeframe
> >regardless of any planning.
> 
> +1 on letting 2.0 drop block on dropping things rather than adding
> things.

Actually I'd prefer to use this opportunity to drop or rewrite stuff we know 
is problematic. E.g. taxonomies (especially nesting), API v1, hostgroup 
provisioning, extracting puppet to a plugin, smart variables merging with 
parameters (not smart class parameters), dropping unattended installation mode 
(or at least refactoring).

If the only reason is we the number is too high, I think it does not balance 
the missed chance and it would be a pity to not use such opportunity.

--
Marek

-- 
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] Re: [UX] Facets and Host UI - roadmap discussion.

[Marek Hulán]

You're right, there are cases where it's better to separate facets and cases 
where it's better to combine them. While we can define what page belongs to 
which category I think more natural approach is simply say that we need to 
allow both. For me, provisioning a host is a combination of workflow and data 
entry based on how you defined it. Even if we change it to kind of a wizard, 
some steps should be extended from facets.

But that's nothing that would contradict anything you said, I just think we 
need to have solution for both.

--
Marek

On středa 15. listopadu 2017 13:23:17 CET ssht...@redhat.com wrote:
> Marek, you lead me to an interesting conclusion:
> 
> I think we have to distinguish two things here - there are workflows (such
> as provisioning, config management, fact reporting) and there are
> information aspects.
> An information aspect is a set of properties that describe a host in
> different system. For example puppet facet would store all properties that
> are needed to describe a host in puppet. Ovirt facet would store all
> properties that describe the host in ovirt system.
> Workflow, on the other hand, is a set of actions that needed to be taken in
> a certain order to achieve some operational goal. Examples to that would be
> provisioning - a set of actions that involve different systems (dhcp, dns,
> vm infrastructure and OS installer) that result in a fully operational
> server. Another example would be monitoring - in this case we will want
> multiple systems (like puppet's facter, vm's power status e.t.c.) to report
> to the user.
> 
> Now, once we have those concepts, we can try and translate this into the
> UI: In my opinion, data entry should be done from screens centered on
> information aspects, regardless of the workflows where this information
> could be used. On the other hand each workflow deserves a "summary" read
> only screen, where we will combine data from multiple facets to show which
> data would be used for that particular workflow.
> 
> From a more practical  point of view, our current screens serve both
> workflows and data entry. It means that we have to establish for each
> screen what it tries to achieve - either it's a data entry page, such as
> host's new\edit form or it's a workflow preview/result page such as host
> show page. Data entry pages should be rigidly grouped by facets, but
> workflow pages should be extensible, so each facet will be able to show
> relevant information on the same page.
> 
> How does this sound to you?
> Roxanne, does it fit with your vision of form's next generation?
> 
> On Wednesday, November 15, 2017 at 8:33:35 AM UTC+2, Marek Hulan wrote:
> > I think these screenshots illustrate that pure option 2 can have negative
> > impact on usability. If I'm a puppet user, the puppet environment is one
> > of
> > the most important thing to set. Having it in last tab completely separate
> > from hostgroup does not feel right. If some field of facet is part of
> > provisioning workflow, it should be extending provisioning UI/facet.
> > Another example from content management, the content source is definitely
> > a
> > part provisioning, I want to be able to choose content view as an
> > installation medium.
> > 
> > On November 12, 2017 19:36:14 ssh...@redhat.com  wrote:
> > > OK, I have managed to create some screenshots of the before and after
> > > state. Please don't judge the styling - it's more about the technical
> > > abilities than the styling.
> > > 
> > > I will take Puppet as an example. Let's say we have puppet facet that
> > 
> > has
> > 
> > > the following data: puppet environment, puppet proxy and puppet ca proxy
> > > fields plus a list of puppet classes assigned to the host.
> > > 
> > > Before:
> > > The information is spread on multiple screens:
> > > Take a look at this screenshot: https://ibb.co/bsXT8G it shows where
> > 
> > this
> > 
> > > information is currently located on the main tab.
> > > This screenshot: https://ibb.co/ksuaoG shows the detailed puppet
> > 
> > classes
> > 
> > > view.
> > > 
> > > After:
> > > Everything related to puppet is presented on a single tab. This tab can
> > 
> > be
> > 
> > > enabled and disabled based on user's preference - the user can decide to
> > > turn puppet management on or off for this host.
> > > https://ibb.co/bNnd8G shows the tab when the fields are enabled, and
> > > https://ibb.co/eCJ72b shows all the fields disabled.
> > > 
> > > I hope it helps to visualize both options.
> > > 
> > > 
> > > On Wednesday, November 8, 2017 at 12:08:06 AM UTC+2, Walden Raines
> > 
> > wrote:
> > >> Hey Shim,
> > >> 
> > >> Can you please include screenshots (or, even better, a quick video or
> > 
> > gif)
> > 
> > >> of the new UI to make it easier for people to visualize who don't have
> > 
> > the
> > 
> > >> code checked out?
> > >> 
> > >> Assuming I'm understanding your description of the two options, I would
> > >> also vote for option #2 as option #1 sounds like it 

Re: [foreman-dev] speeding up tests

[Marek Hulán]

On úterý 7. listopadu 2017 11:12:31 CET Ivan Necas wrote:
> On Tue, Nov 7, 2017 at 9:19 AM, Ohad Levy  wrote:
> > Hi,
> > 
> > The challenge:
> > 
> > As a developer, I feel under utilized waiting for tests, the current test
> > suite for foreman core takes over an hour, multiply it by number of really
> > simple code fixes based on comment and it takes up a good chunk of a day.
> 
> Personally, I don't feel this issue: if it's 1 hour or 5 minutes: I'm
> already doing
> something else in the meantime, so I would not probably see much the
> difference. Locally, I usually run just the test file that touches the code
> I'm working on to have
> the immediate feedback on those. Waiting a bit longer on the PR is a
> price I'm willing to
> pay for increasing the chance that my code runs as much as possible.

I don't think it's any issue for me either.

> 
> > I would like to suggest a short and long term solution, and would
> > appreciate your feedback.
> > 
> > Short-term:
> > 
> > Break down test matrix into more specific groups, this will allow to
> > re-trigger just a smaller part of the tests vs. the entire suit today, for
> > example:
> > * API tests
> > * DB migrations
> > * UI Integration tests
> > * ...
> 
> Not opposed. Seems like valid request.

+1

> > Long term:
> > 
> > Break down core into smaller repositories - This is probably a bigger
> > topic
> > then just tests, but its worth raising in this context as well.. the
> 
> > benefits i see are:
> The question: would this speed-up the things moving, in terms of getting
> changes in? I would worry that the outcome would be just oposite of that.
> 
> > * smaller repos - faster tests per repo (we would still need a plugin
> > matrix kind of tests done at some point)
> 
> We should solve the pluign matrix first, ideally on PR level: I would
> recommend first mastering that before going with more split.

I don't like the idea. My ceoncern is we'd have more repos without reviews.
> 
> > * better review process - smaller repos would mean the maintainers of the
> > repo actually care for all/most of the pr's - today its not the case -
> > many
> > PR's are handled by sub groups (e.g. anything under webpack folder is
> > "someone else")
> 
> But still, most of the reviewers at least see, what's going on there. I know
> we could achieve this with more repos as well, but frankly, not sure it
> would work that much in the real life.
> 
> > * potentially better API between parts - e.g. we can create a schema
> > specific repo (not saying its a good idea) - which will always work with a
> > dummy rails app - in the long run - this will ensure our schema is
> > resilient to upgrades and model changes in core.
> 
> I miss the implication. Could you expand on the thoughts?
> 
> > I would even go further and enable auto merge after review + successful
> > tests, e.g.
> > 1. PR is sent
> > 2. repo tests are executed and pass
> > 3. reviewer approve the change
> > 4. larger test matrix is executed and pass
> > 5. code get auto merged.
> 
> This is ortogonal to any of the previous and makes sense to me.

Good idea

--
Marek

-- 
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] [Event] Foreman Community Demo Items - Thu 16 Nov 3pm [BST]

[Marek Hulán]

I think there are some demo worthy PRs merged, is there a volunteer to demo 
them if they don't appear on agenda? I could take some.

--
Marek

On čtvrtek 9. listopadu 2017 13:28:23 CET Ori Rabin wrote:
> Hi all,
> 
> Demo time! As always, have a think for items which have been completed since
> the last demo on 2017-10-26. There is a query that will show you items
> completed (i.e. marked as closed) since the last demo [2].  Please add demo
> items following the instructions on the agenda page [3].
> 
> If you can't be present but have something to show, add it to the
> agenda and let me know - I'll be happy to talk about the feature in your
> absence. Please do leave me enough time to familiarize myself with the
> content
> though :)
> 
> [1] https://www.youtube.com/watch?v=QHzNIFjMpTM
> [2] http://tinyurl.com/ydbo6a43
> [3]
> http://projects.theforeman.org/projects/foreman/wiki/Current_Sprint_Informat
> ion
> 
> --
> Ori
> IRC: orabin


-- 
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] Abandoned plugins under theforeman github org

[Marek Hulán]

Hello there

thanks to Tomer and Timo, we were able to fix most of plugins after 
FactoryGirl was renamed to FactoryBot, see [1] for current status. As part of 
that, I found two plugins where we didn't get any response and they seem 
abandoned. Would it make sense to remove them from the foreman org on github 
and perhaps remove their jenkins jobs or even redmine projects? Do you know 
about any other abandoned plugin?

The plugins:

rundeck [2] - last commit 12 Jul 2016
pipeline [3] - last commit 21 Sep 2016, author confirms it's no longer 
maintained [4]

[1] https://pad-katello.rhcloud.com/p/factory_bot_update
[2] https://github.com/theforeman/foreman_host_rundeck/
[3] https://github.com/theforeman/foreman_pipeline
[4] https://github.com/theforeman/foreman_pipeline/pull/
74#issuecomment-341057533

Thanks

--
Marek

-- 
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 instrumenting analysis

[Marek Hulán]

On úterý 7. listopadu 2017 14:56:05 CET Eric D Helms wrote:
> On Thu, Nov 2, 2017 at 5:05 PM, Ivan Necas  wrote:
> > 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.
> 
> In reading about push vs. pull, my biggest issue with it is that the
> application has to have knowledge of where it's pushing. Whereas the pull
> model allows an application to say I have metrics here and anything that
> knows how to scrape and interpret those metrics can grab them at their
> leisure. This provides nicer de-coupling and potentially more choice if
> there is a standard-ish data format used to expose the metrics.

Does that imply we'd need to keep that stored? This can generate huge amount 
of data, which I suppose would mean we need to implement some regular cleaning 
like logrotate etc. I'd prefer to just throw data away, whoever listens gets 
it.

--
Marek

> 
> > Eric: could you more describe the 5 web applications requiring 5
> > monitoring containers?
> > I might be missing where this implication came from?
> 
> This part comes from if you do the sidecar method of running something like
> a statsd process. A sidecar is essentially just running two containers in a
> pod where one container is considered the main application and the other an
> addon that provides some additional value or performs some actions without
> being baked into your main application container. If you picture this idea,
> and then think about pod scaling (in Kube), for every scale up you'd also
> be adding another statsd process container. This might be fine in practice,
> but could in theory be overkill.
> 
> Another method with statsd is simply to run it on the host itself and have
> the containers send data to it but this provides some security concerns
> from what I understand.
> 
> The biggest limiting factor appears to be how forking webservers are
> handled and probably constraints us the most. Lukas, have you seen anything
> related to being to define what the metrics are and how they get published
> being able to be separated from the publishing mechanism? My thinking being
> if we started with statsd and wrote code within the application generating
> statsd metrics, if at a later point one could simply say now publish this
> via HTTP endpoint in Prometheus data style for scraping?
> 
> Eric
> 
> > -- 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 

Re: [foreman-dev] FactoryGirl renamed to FactoryBot - plugin maintainer action needed

[Marek Hulán]

On středa 1. listopadu 2017 10:19:08 CET Tomer Brisker wrote:
> Hello,
> This has now been merged in Foreman core.
> All plugins should make sure that their respective PRs pass tests and
> merge them now. If you need assistance making this change in your
> plugin, please reach out to us and we would be happy to help.
> 
> Keep in mind that any PRs that include test changes that use
> FactoryGirl will need to be modified now to use FactoryBot, even if
> previously the tests passed.
> 

Hello all,

if you're uncertain whether your plugin is affected or there some action 
required from you, see the public pad [1]. We keep the status of the whole 
migration there. A lot of plugins have master branch tests broken because of 
rubocop update, for some plugins I sent a PR that should fix it too. This 
could reveal plugins that are no longer maintained :-)

[1] https://pad-katello.rhcloud.com/p/factory_bot_update

--
Marek

> Tomer
> 
> On Wed, Oct 25, 2017 at 4:52 PM, Marek Hulan  wrote:
> > Thanks for sending out the heads up. Please also note that such PRs will
> > get out of date very quickly so make sure you have them up to date just
> > before merge :-)
> > 
> > --
> > Marek
> > 
> > On October 25, 2017 3:23:29 PM Andrew Kofink  wrote:
> >> I went ahead and made an issue for Katello [1]. I'll submit a PR today
> >> with
> >> the changes.
> >> 
> >> [1] http://projects.theforeman.org/issues/21458
> >> 
> >> On Wed, Oct 25, 2017 at 9:12 AM, Tomer Brisker 
> >> 
> >> wrote:
> >>> Hello,
> >>> 
> >>> The Thoughtbot team have decided to rename the factory_girl gem, which
> >>> we
> >>> depend on for tests, to factory_bot [1]. This led to our CI breaking due
> >>> to
> >>> the name change. For now, we have pinned factory_girl to the last
> >>> working
> >>> version to unblock CI, but we should prepare to change to the new name.
> >>> 
> >>> This requires, basically, changing every occurrence of `FactoryGirl` to
> >>> `FactoryBot`, and every `factory_girl` to `factory_bot`. Other then the
> >>> name change, no other changes were made to the API.
> >>> 
> >>> Marek has opened a PR[2] for fixing this in foreman-core, however once
> >>> this is merged it will break tests for all plugins depending on the core
> >>> factory_girl. To prevent prolonged breakage, all plugin maintainers
> >>> should
> >>> work to prepare a PR making the above mentioned change, so that it can
> >>> be
> >>> merged once core PR is merged.
> >>> 
> >>> To give you some time to fix this and prevent breakage, the core PR will
> >>> be merged one week from today, on November 1st. Please make sure you are
> >>> prepared to correctly handle this change in your plugin. If needed, feel
> >>> free to reach out to me, Marek, or any of the other core maintainers.
> >>> 
> >>> ?[1] https://github.com/thoughtbot/factory_bot/issues/921?
> >>> ?[2] https://github.com/theforeman/foreman/pull/4935?
> >>> 
> >>> --
> >>> Have a nice day,
> >>> Tomer Brisker
> >>> 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.
> >> 
> >> --
> >> Andrew Kofink
> >> akof...@redhat.com
> >> IRC: akofink
> >> Software Engineer
> >> Red Hat Satellite
> >> 
> >> --
> >> 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.


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

[Marek Hulán]

I think the date is reasonable. Given we have 2-3 RCs per 2 weeks, we could 
expect 1.17 release early next year right? Which I think is good since we'll 
have time to fix potential blockers after we're back from Christmas time off.

--
Marek

On úterý 31. října 2017 12:59:12 CET Ohad Levy wrote:
> On Tue, Oct 31, 2017 at 1:48 PM, Ondrej Prazak  wrote:
> > Hi,
> > based on the Redmine release dates [1], 1.17 is supposed to be branched on
> > December 1st. Do we want to stick to this plan or do we want to take into
> > account that 1.16 was delayed?
> > 
> > Let me know what you think,
> 
> Given the fact that we already branched 1.16 in September, I personally
> would like to keep the dates.
> 
> Ondra
> 
> > [1] http://projects.theforeman.org/rb/releases/foreman
> > 
> > --
> > 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] Re: Database and Service Actions in RPM Post Scripts

[Marek Hulán]

I'd be in favor of a change and avoid running scripts in post scripts. This is 
the reason why we added "Optional Step 3 (C) - Run foreman-installer" to our 
manual [1] a long time ago. We recommend running installer after upgrade if 
users use it for initial setup. If this is too heavy step, maybe foreman-
maintain task could be added that would ensure all is up to date.

[1] https://theforeman.org/manuals/1.15/#UpgradingtoForeman1.15

--
Marek

On pondělí 25. září 2017 0:54:10 CEST Andrew Schofield wrote:
> [I'm a user, not a developer]
> 
> I'd suggest that the RPM's *simply* drop the files onto the file system and
> the installer then does the required actions. There are a lot of moving
> parts to foreman and restarting one component can have impact on other
> components. They also duplicate actions which take place in the installer.
> The actions taken by users are (should be) yum update then a run of the
> installer.
> 
> On Friday, September 22, 2017 at 4:19:46 PM UTC-4, Eric Helms wrote:
> > Howdy,
> > 
> > There have been recent conversations that have popped up on PRs, for
> > example [1], and IRC conversations around whether or not our RPM packages
> > should be performing database actions and restarting services. This thread
> > is intended to gather feedback and view points to arrive a community
> > decision on whether or not we should continue this behavior, alter it with
> > limitation or out right get rid of it.
> > 
> > This mostly happens within Foreman and some plugins, and the actions
> > 
> > performed today:
> >  * database migrations
> >  * database seeds
> >  * apipie cache
> >  * httpd restart
> >  * foreman-tasks restart
> > 
> > There may be others, these are the ones I am aware of. The history of
> > these actions, as I understand it, is so that in theory you can yum
> > install
> > a plugin and, without further action, the Foreman server continue to run
> > now with your plugin.
> > 
> > Now, for my personal view point. Our application stack is fairly complex,
> > and there are a decently large number high percentage install plugins and
> > ecosystem of plugins in general. Plugins performing these sorta actions as
> > part of yum install has the potential to create unintended consequences.
> > We
> > have created an idempotent installer to manage our server installations
> > for
> > a reason, to help orchestrate changes, provide a framework for known and
> > coordinated change. And that these types of actions should be strictly
> > relegated to it.
> > 
> > I encourage all Foreman and plugin developers to please weigh in so that
> > we may reach consensus.
> > 
> > Thanks for your time and consideration.
> > 
> > 
> > [1] https://github.com/theforeman/foreman-packaging/pull/1761


-- 
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] Help needed: Discovery develop broken (Rails 5)

[Marek Hulán]

On čtvrtek 21. září 2017 9:46:59 CEST Lukas Zapletal wrote:
> Hello,
> 
> we are getting errors in discovery develop due to Rails 5 update:
> 
> ActiveRecord::SubclassNotFound: Invalid single-table inheritance type:
> Host::Discovered is not a subclass of Host::Managed
> 
> http://ci.theforeman.org/job/test_plugin_matrix/3760/database=mysql,ruby=2.4
> ,slave=fast/testReport/junit/(root)/DiscoveredHostsControllerTest/test_updat
> e_inheritance/
> 
> If anyone have ideas, please help me to resolve this. There are couple
> of PRs pending review but I need to get tests green before. We do some
> weird magic in Host and some STI changes in Rails5 regressed. I have
> no idea.

Have you tried Ivan's PR? [1]

[1] https://github.com/theforeman/foreman/pull/4864

--
Marek

-- 
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] How to print a date/time in Foreman

[Marek Hulán]

Hello devs,

a PR that unifies the way how we print the date/time information in Foreman 
was merged recently [1], it will be present in 1.16 release. If you're a 
plugin author or will ever need to print a date/time please use one of the 
following helper

date_time_absolute(time, format = :short)
date_time_relative(time)

It will print the information in either absolute or relative way and hovering 
a mouse cursor over it will display the complementary information in a 
tooltip. Also by using this, it will ensure the format of the date is always 
the same.

For existing plugins, I'd ask you to consider changing existing code to start 
using these helpers. I've created tracking issues for plugins and linked them 
to original issue [3], please add more if I missed some plugin that needs it. 
The How to Create a Plugin wiki page was already updated [2].

Since the change seems trivial (except for Katello) I think it would be great 
if we could adopt it in releases aligned with 1.16.

[1] https://github.com/theforeman/foreman/pull/4820
[2] http://projects.theforeman.org/projects/foreman/wiki/
How_to_Create_a_Plugin#Printing-date-and-time
[3] http://projects.theforeman.org/issues/19047/

Please let me know if you have any questions

--
Marek

-- 
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] Plugin gems with a single author

[Marek Hulán]

On pondělí 11. září 2017 14:02:06 CEST Greg Sutcliffe wrote:
> On Sun, 2017-08-20 at 16:33 +0200, Timo Goebel wrote:
> > I'd also be interested in helping with foreman_bootdisk. Although
> > it's sad to see, it looks like Dominic isn't maintaining this at all
> > anymore.
> 
> On Mon, 2017-08-21 at 09:19 +0200, Lukas Zapletal wrote:
> > I also have some knowledge of bootdisk and hooks.
> 
> With no response here, or on various pull requests [1,2] in some
> months, would anyone object if I add Lukas and Timo to the bootdisk
> plugin on GitHub? They could then review each others work as we
> normally do.
> 
> [1] https://github.com/theforeman/foreman_bootdisk/pull/42#issuecomment
> -314787206
> [2] https://github.com/theforeman/foreman_bootdisk/pull/43#issuecomment
> -316937459
> 
> Greg

Makes sense to me

--
Marek

-- 
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] Permissions cleanup

[Marek Hulán]

On pondělí 11. září 2017 13:41:02 CEST Greg Sutcliffe wrote:
> Hi all,
> 
> In the context of the plugins-bus-factor discussion, etc, it occurred
> to me that we still have a lot of people with access who aren't really
> active any more - this can make it hard to see where action is needed.
> 
> We've never really done a permissions cleanup before, so I thought it
> might be time. Here's a list of people / things I found that I'd like
> to fix. I've tried to keep this to core and related stuff, as plugins
> are free to handle their own affairs, to a large extent (also the list
> would be huge). In vaguely alphabetical order then:
> 
> * Amos Benari:
>   * Github: no commits in over a year, remove commit on
> - community-templates
> - foreman
> - rfcs
> - smart-proxy
> - theforeman.org
> * Brian Gupta:
>   * Github: no commits in over a year, remove commit on
> - community-templates
> - foreman
> - foreman-selinux
> - hammer_cli
> - rfcs
> - smart-proxy
>   * Remove Admin level on Redmine, last login, Apr 2015
>   * Brandorr (Brian's org) also has an SSH key for the infra. Since we
> still host some stuff with them, let's leave that for now.
> * Dominic Cleal:
>   * GitHub - Owner status:
>   While commit access lasts for a year, Dom has not been seen on
>   the mailing lists, Redmine, or Github since May/June (with the
>   exception of a single commit in July). In the context of having
>   active owners that we discussed previously, I propose we demote
>   him from owner level.
> * Joseph Magen (istratrade):
>   * Github: no commits in over a year, remove commit on
> - community-templates
> - foreman
> - foreman-selinux
> - rfcs
> - smart-proxy
> * Corey Osman (logicminds):
>   * Github: no commits in over a year, remove commit on
> - community-templates
> - foreman
> - foreman-selinux
> - rfcs
> - smart-proxy
> * Sam Kottler:
>   * Github: no commits in over a year, remove commit on
> - foreman-installer
> - foreman-packaging
> - foreman-infra
> - community-templates
> - kafo
> - foreman-bats
> - redmine (our fork)
> - prprocessor
> - jenkins-job-builder (our fork)
>   * Remove SSH key on infra
> 
> There's probably more, but that's a first pass. Thoughts?
> 
> Greg

+1, thanks for doing this! At some point we should review plugins too, maybe 
just suggest changes to de facto maintainers.

--
Marek


-- 
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] What is the process to get new resources added to transifex?

[Marek Hulán]

I think we don't have to follow the full-blown nomination process here, any 
concerns regarding giving Bryan admin access? Please let me know here or 
privately, otherwise I'll add Bryan in few days.

--
Marek

On pátek 8. září 2017 22:31:48 CEST bk wrote:
> Also... hammer-cli-foreman-tasks.. could that get added as a resource?
> 
> On Thursday, September 7, 2017 at 3:48:05 PM UTC-4, bk wrote:
> > On 08/31/2017 07:49 AM, Bryan Kearney wrote:
> > > On 08/31/2017 05:36 AM, Daniel Lobato Garcia wrote:
> > >> On 08/30, Bryan Kearney wrote:
> > >>> I would like to see katello and katello-bastion added to transifex.
> > 
> > Once
> > 
> > >>> that is done, I can ask folks to add string syncing to the build
> > >>> process. I
> > >>> can translate, but I dont have access to add resources.
> > >>> 
> > >>> -- bk
> > >> 
> > >> I think you would need to gather the .po files for the projects you
> > 
> > want
> > 
> > >> to add, then upload them to
> > >> https://www.transifex.com/foreman/foreman/content/
> > >> 
> > >> The administrators at the moment according to
> > >> https://www.transifex.com/foreman/public/ are: lzap, ohadlevy,
> > 
> > domcleal
> > 
> > >> mhulan, Claer. They could add the .po files or add you as another
> > >> aministrator.
> > > 
> > > I have these, and I can either supply them or append them to
> > > 
> > > https://github.com/Katello/katello/pull/6929
> > > 
> > > which I put in to generate them. I am also happy to beg for admin
> > 
> > status.
> > 
> > > -- bk
> > 
> > ok.. third try. Can I get an admin to please upload these. Thanks!
> > 
> > -- bk


-- 
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] Foreman core tests broken

[Marek Hulán]

Hello

There's a new issue in core tests. Following failure can be observed in the 
whole matrix.

UserTest.test_0066_can search users by usergroup
ActiveRecord::StatementInvalid: PG::UndefinedColumn: ERROR:  column 
"member_type" does not exist...

It seems be caused by the new scoped_search release that was published 18 
hours ago. Interestingly enough, the only 2 new commits in this release were 
contribute by foreman devs [1]. Pinning the scoped_search version to 4.1.0 
workarounds the issue.

[1] https://github.com/wvanbergen/scoped_search/commits/master

--
Marek


-- 
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] [infra] Packaging reorganization

[Marek Hulán]

Perhaps the foreman_scap_client could be one. There's the gem itself [1] and 
configuring puppet module that we also package [2]

[1] 
https://github.com/theforeman/foreman-packaging/tree/rpm/1.16/rubygem-foreman_scap_client
[2] 
https://github.com/theforeman/foreman-packaging/tree/rpm/1.16/puppet-foreman_scap_client

--
Marek

On sobota 2. září 2017 16:22:36 CEST Timo Goebel wrote:
> I am wondering if we should name the katello-client repository either
> foreman-client or just client. I can think of more plugins that need a
> client package. Timo
> 
> > On 2. Sep 2017, at 01:48, Eric D Helms  wrote:
> > 
> > Howdy,
> > 
> > As a lead-in to being working towards migrating Katello's packages to the
> > foreman-packaging repository, I'd like to propose a slight
> > re-organization of the repository. As well, to seek any other ideas or
> > problems any might see with the proposal.
> > 
> > Currently, the packaging repository is a flat structure with all packages
> > being represented by a directory containing sources and a spec file. When
> > looking at it, I find it hard to think about them in an organized manner
> > given we separate by repository into foreman and foreman-plugins (and
> > eventually katello repositories). Thus, my proposal is to let the
> > packaging repository reflect the repository organization by moving things
> > into the following directories:
> > 
> > foreman-packaging
> > 
> >- foreman
> >- plugins
> >- katello
> >- katello-client
> > 
> > Thoughts?

-- 
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] [Infra] Proposal to Move Jenkins Job Configurations

[Marek Hulán]

On sobota 2. září 2017 1:27:23 CEST Eric D Helms wrote:
> Howdy,
> 
> Some quick background, for those that don't know a majority of our Jenkins
> job configuration are stored in git. I find our Jenkins job configuration
> to be important for developers to be able to understand and contribute
> changes. However, today, these configurations are stored deep inside the
> foreman-infra [1] repository. I am proposing one of two ideas to bring
> these to the forefront:
> 
>  1) Move them to the top of foreman-infra under a "jenkins" or "jobs" folder
> 2) Move them to their own repository (e.g. foreman-ci)
> 
> 
> [1]
> https://github.com/theforeman/foreman-infra/tree/master/puppet/modules/jenki
> ns_job_builder/files/theforeman.org

+1 to whatever new location. Since I already know they live in foreman-infra, 
I'm fine with keeping them there.

--
Marek

-- 
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] Test failures and merging PRs

[Marek Hulán]

Thanks Timo for your input. Please see my comment below in the text.

On čtvrtek 31. srpna 2017 23:08:34 CEST Timo Goebel wrote:
> Am 28.08.17 um 17:12 schrieb Marek Hulán:
> > 1) codeclimate is red
> > 
> > This can be ignored, we never agreed on using this as a hard metric for
> > the
> > PR. The motivation to introduce it was mainly to save some time to
> > reviewer. We don't have to run it manually to get indications whether
> > there's something introducing a big complexity [1]. From my experience it
> > sometimes leads to worse code, since author splits the logic into more
> > methods to lower e.g. cyclomatic complexity but it should be judged
> > separately in every case.
> +1
> I like it as a suggestion, but sometimes it's just off and better be
> ignored.
> 
> > 2) foreman is red
> > 
> > This can happen because of intermittent tests failures. If the PR is
> > clearly not causing new ones and commiter is aware of this error, the PR
> > is merged with message like "test unrelated" comments. If we are not
> > sure, we retrigger the run,
> > 
> > If Foreman develop branch is broken, we need to merge the PR to fix it so
> > this is another exception. Usually we trigger the jenkins job manually
> > first to see that the PR fixes the issue.
> 
> +1
> Yes, don't merge a PR with failing Foreman core tests.
> 
> > 3) katello is red
> > 
> > If katello becomes red only for this PR, we analyze what causes it.
> > Usually it means that we change some internal things that have impact on
> > Katello. In such case, we're doing our best to send a fixing PR to
> > Katello or we ping someone with better knowledge in this area. We don't
> > merge the PR until it's resolved, then usually we merge both parts at the
> > same time.
> 
> I think, this is totally unfair to all the "smaller" plugin maintainers
> and that's why I vote for removing the test completely or just keep it
> to test our public APIs.
> I believe, we should do the following:
> If the Foreman PR breaks some public API, e.g. facets, and the Katello
> tests show that, my suggestion is to fix the foreman PR to not break the
> public API and add proper depreciations if possible.
> If we change something inside Foreman - in the past we changed the host
> multiple actions from GET to POST or introduced strong parameters for
> example - the contributor or maintainer should send a mail to
> foreman-dev expaining what needs to be changed in plugins. I think it's
> also a good idea to fix the example plugin or the How to create a plugin
> wiki page if applicable.
> However I think, it's the plugin maintainer's responsibility to make
> sure his plugin works with Foreman. Everything else doesn't scale. In
> the past a lot of "my" plugins broke because of changes to Foreman core.
> Nobody cared to send a PR so far. But that's fine. I don't expect
> anybody to. It's my job to test the plugin and fix it if it breaks.
> I think, we should not block Foreman PRs because an additional parameter
> was added to some internal method, just because Katello happens to
> overwrite that method. It just doesn't make any sense to me why we
> should do that for Katello but not for all the other plugins out there.
> This is not against Katello, it's just the only plugin tested with
> Foreman core right now.
> Currently, we're developing a plugin to show system logfiles in Foreman.
> That requires a complete ELK-stack for development. I would not expect
> every developer to have that at hand.
> If we leave Katello in the matrix, I think it would be totally fair to
> also add our new plugin to Foreman's test matrix as well. But I wouldn't
> want to block Foreman development just because some test in that plugin
> breaks.
> I know, Katello is important for RedHat and it's one of the larger
> plugins. But that doesn't justify a special role in my opinion.

I understand your feeling. A "justification" for me is that Katello is the 
largest plugin we have and therefore is much more prone to be broken by 
changes in Foreman. The more code you touch from plugin the higher the chance 
is that new core PR breaks something. Also I think for core it's a good way to 
find out what impacts our changes have. By testing Katello we get early notice 
about something that can impact all plugins. The PR author can consider 
whether there's less breaking way of doing the change.

Having said that I still can understand that other plugin maintainers feel 
it's unfair. But instead of dropping Katello from matrix, I think the opposite 
approach would make more sense. I'd like to see many more plugins tested. I 
think plugin test sets are usually much smaller than core 

Re: [foreman-dev] [Infra] Reducing Test Matrix

[Marek Hulán]

+1

--
Marek

On středa 30. srpna 2017 12:36:01 CEST Ivan Necas wrote:
> +1
> 
> -- Ivan
> 
> On Wed, 30 Aug 2017 at 11:18, Lukas Zapletal  wrote:
> > Can we do similar for test_plugin_matrix?
> > 
> > I'd like to propose additional change for plugins - to only run core
> > tests for one Ruby version/db as well. For all other version/db
> > combinations we would only run plugin test suite and not core.
> > 
> > LZ
> > 
> > On Wed, Aug 23, 2017 at 1:44 AM, Eric D Helms 
> > 
> > wrote:
> > > I am beginning to look at updating some of our test infrastructure by
> > > re-writing Jenkins jobs into the pipeline plugin [1]. This is a new
> > 
> > style,
> > 
> > > with a different way of both writing and thinking about how jobs are
> > > crafted. I've started this work by attempting to write jobs for both
> > 
> > Foreman
> > 
> > > and Katello [2].
> > > 
> > > The current test_develop job for Foreman (which runs after pull requests
> > 
> > are
> > 
> > > merged) is a 4x3 matrix resulting in 12 different configurations
> > > running.
> > > 
> > > They are:
> > >  ruby: 2.1, 2.2, 2.3, 3.4
> > >  databases: mysql, postgresql, sqlite3
> > > 
> > > I would like to propose the following:
> > >  1) We drop sqlite3 entirely
> > >  2) We test all rubies on postgresql only
> > >  3) We pick the most widely used Ruby version and test mysql with that
> > > 
> > > This would effectively reduce the number of test runs in the matrix to 5
> > > which should in theory increase throughput of testing and keep things
> > > focused on the most important pieces to test. Further, sqlite3 is not a
> > > production database so I feel it not worth the resources (but it would
> > 
> > only
> > 
> > > add one more job to keep it). I also don't see how Ruby version should
> > > affect database choice and thus find no reason to run the full matrix
> > 
> > across
> > 
> > > all rubies for Mysql.
> > > 
> > > From what I think I know, of the Rubies:
> > >  2.2 -- used in RPM production
> > >  2.1, 2.3, 2.4 -- used by Debian production
> > > 
> > > [1] https://jenkins.io/doc/book/pipeline/
> > > [2] https://github.com/theforeman/foreman-infra/pull/321
> > > 
> > > --
> > > 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.


-- 
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] Test failures and merging PRs

[Marek Hulán]

Hello devs,

since there was a discussion on foreman-dev IRC channel recently about merging 
PRs in Foreman core even if there's some build failed, I talked to few people 
and decided to describe here what I think is current way of how it works. I'm 
also attaching one suggestion at the end that came up after the discussion.

Please, add questions, comments or simple +1 so we all know whether we're on 
the same page.

Core PR runs 7 checks - foreman, katello, codeclimate, hound, prprocessor, 
upgrade, continuous-integration/travis-ci/pr. In ideal case they are all green 
and after review, the PR is merged. There are several cases where we can merge 
even if the PR is red.

1) codeclimate is red

This can be ignored, we never agreed on using this as a hard metric for the 
PR. The motivation to introduce it was mainly to save some time to reviewer. 
We don't have to run it manually to get indications whether there's something 
introducing a big complexity [1]. From my experience it sometimes leads to 
worse code, since author splits the logic into more methods to lower e.g. 
cyclomatic complexity but it should be judged separately in every case.

2) foreman is red

This can happen because of intermittent tests failures. If the PR is clearly 
not causing new ones and commiter is aware of this error, the PR is merged 
with message like "test unrelated" comments. If we are not sure, we retrigger 
the run,

If Foreman develop branch is broken, we need to merge the PR to fix it so this 
is another exception. Usually we trigger the jenkins job manually first to see 
that the PR fixes the issue.

3) katello is red

If katello becomes red only for this PR, we analyze what causes it. Usually it 
means that we change some internal things that have impact on Katello. In such 
case, we're doing our best to send a fixing PR to Katello or we ping someone 
with better knowledge in this area. We don't merge the PR until it's resolved, 
then usually we merge both parts at the same time.

If it turns out there are more PRs that are failing with same errors, we merge 
PRs if we're sure they don't introduce new Katello failures. At this time, 
we're not blocking merges until Katello is green again. (*) here the 
suggestion applies

4) upgrade is red

this is very similar to katello job, if there's some issue in upgrade, we 
should not merge the PR. I remember though, there was a time when we knew the 
job is broken which fall under "known to be broken" category.

5) There's no 5, all the rest must be green. Sometimes hound service does not 
respond and remains in "running" state, then it's retriggered by the reviewer. 
prprocessor and travis must always be happy.

Now the promised suggestion. When we see katello/upgrade job is broken on 
multiple PRs, the first reviewer who spots it should notify the rest of 
developers about "from now on, we ignore tests XY". The ideal channel seems to 
be this list. This helps Katello devs to find out when it started, what were 
the commits that first induced it.

[1] https://groups.google.com/forum/#!topic/foreman-dev/p7ESagXwNwk

Thanks for comments

--
Marek

-- 
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] Plugin gems with a single author

[Marek Hulán]

On pátek 18. srpna 2017 13:48:06 CEST Greg Sutcliffe wrote:
> Hi all,
> 
> As per the newly-merged plugin policy, I've taken a quick pass over all
> the gems listed in the RPM packaging (which is more comprehensive than
> the Deb packaging), grepped for "foreman" and "proxy", and then used
> the Rubygems API to filter for gems with a single author.
> 
> This list was pretty long, so for brevity, I've also removed things
> which are (as far as I know) not in active use at the moment (we can
> always revisit that and run this again later).
> 
> Below is the list of gems that need an additional maintainer, grouped
> by owner. Could these people please add a second author to the gem,
> just in case? If you've got someone in mind just go for it, if you want
> help deciding who show be added, feel free to reply here.
> 
> Daniel Lobato Garcia:
> - foreman_ansible
> - foreman_ansible_core
> - foreman_azure
> - foreman_cockpit
> 
> Dominic Cleal:
> - foreman_bootdisk
> - foreman_hooks
> - foreman_setup
> - hammer_cli_foreman_bootdisk
> - smart_proxy_dns_route53
> 
> Ewoud Kohl van Wijngaarden:
> - smart_proxy_dns_powerdns
> 
> Greg Sutcliffe:
> - foreman_column_view
> - foreman_default_hostgroup
> 
> Marek Hulan:
> - foreman_chef
> - smart_proxy_chef

Anyone interested? I have no candidate. Btw there's also https://github.com/
theforeman/chef-handler-foreman which is related.

--
Marek

> Lukas Zapletal:
> - smart_proxy_discovery_image
> 
> Ohad Levy:
> - foreman_memcache
> 
> Since I'm on the list, who wants adding to my plugins? :)
> 
> Regards
> 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.

Re: [foreman-dev] Taking over plugins - do we need a policy?

[Marek Hulán]

On pondělí 14. srpna 2017 17:31:00 CEST Greg Sutcliffe wrote:
> Hi all,
> 
> This went fairly quiet, but we all seem largely in agreement. I'll
> draft something up for the website and send a PR tomorrow. I had a few
> side questions though:
> 
> On Wed, 2017-07-19 at 10:13 +0200, Marek Hulán wrote:
> > In general +1. I'm not sure if official policy changes anything,
> > probably does not do any harm either
> 
> Indeed, and helps us to remember to add maintainers when bringing a
> plugin into the GitHub org.
> 
> > It would be great if someone went over all plugins under theforeman
> > org on github, found projects with single owner and ask the owner to
> > extend the list. Or someone scritped a simple check so we would
> > avoid  this situation in future. I think what Dmitri described
> > is fair and should become a common practice for new repos/gems in our
> > org.
> 
> Is there a way to view that info on Rubygems? I can't see it on the gem
> pages themselves, is there an API I've missed?

I can see it on gem page, e.g. at https://rubygems.org/gems/foreman_chef 
search for OWNERS. There's just me. This is how to get this info through curl

curl https://rubygems.org/api/v1/gems/foreman_chef/owners.json

see http://guides.rubygems.org/rubygems-org-api/#owner-methods for more 
details.

--
Marek

> 
> On Tue, 2017-07-18 at 16:28 +0200, Daniel Lobato Garcia wrote:
> > +1 to this, I am stuck with foreman-docker where I want to give
> > publish
> 
> What's blocking you? Who owns the gem?
> 
> Regards
> 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.

Re: [foreman-dev] Aligning Foreman & Katello git repositories

[Marek Hulán]

+1 for every suggestion! Which would you like to start with? I'd be interested 
in helping with forklift being used in jenkins for running bats tests. Later I 
hope with installers merge.

--
Marek

On středa 2. srpna 2017 14:33:44 CEST Ewoud Kohl van Wijngaarden wrote:
> Hello all,
> 
> As many of you know we have some overlapping work between Foreman and
> Katello. This is an effort to reduce some of this. This is only
> focussing on git repositories but once this is in place this should be
> easier. It's all proposals and we will need to work out details.
> 
> One might notice that much of this has been talked about before but
> never reached a conclusion, which is something we tend to do a lot.
> Let's break the cycle and make some decisions.
> 
> # foreman-bats -> forklift merge
> 
> Currently we have foreman-bats[1] and forklift[2] which both include
> a vagrant config and bats tests. I'd propose we merge foreman-bats into
> forklift and deprecate foreman-bats. Most of bats (if not all) should
> already be there so I believe we just need to verify we can test Foreman
> using Forklift. Since I added Debian we need to make Ubuntu work and
> verify Jenkins can still test everything it used to.
> 
> This should be a relative easy task for which a lot of work has already
> been done.
> 
> Tasks/Challenges I can think of:
> 
> * Add Ubuntu to Forklift
> * Get bats passing on all supported configs
> * Verify foreman-bats is no longer used on CI
> * Add a deprecation warning in foreman-bats' README
> 
> # katello-packaging -> foreman-packaging
> 
> At the moment Foreman packages are maintained in foreman-packaging[3]
> with an RPM branch for every release (rpm/1.15, rpm/1.16, rpm/develop)
> and a the same with deb/ for obvious reasons. On the Katello side there
> is katello-packaging[4] with KATELLO-3.3, KATELLO-3.4 and master.
> 
> There was a discussion in #1541[5] about merging katello-packaging into
> foreman-packaging, but it didn't reach a conclusion. The general
> opinions were in favour but there might be space and traffic constraints
> when actually building the packages.
> 
> My proposal is to revive this effort. Given the practical constraints
> are related to the hosting it makes sense to me to start with just
> merging the git repositories. Is it possible to do the builds from a
> single git repository and end up on different servers for now?
> 
> If that's possible, we can look at finding proper hosting and which yum
> repositories we should offer.
> 
> # katello modules -> theforeman namespace (including modulesync)
> 
> Right now we have a foreman-installer-modulesync[6] and
> katello-installer-modulesync[7] to maintain the base layout of modules.
> These are all very similar and with little effort we can maintain all
> modules with the same layout.
> 
> The bigger impact is that we need to migrate all modules at least on the
> github level to the theforeman github namespace. It also implies that
> when you make changes to modulesync that needs to be applied to about
> double the modules which can be more effort. The upside is that the
> overall quality will be higher.
> 
> If this all works well we can look at moving the katello modules to the
> foreman namespace on the Puppet forge as well but I think that benefit
> is smaller and will take effort on the (direct) users since the forge
> doesn't support redirects.
> 
> # katello-installer -> foreman-installer
> 
> Currently the katello-installer[8] builds on the foreman-installer[9]
> with additional modules and scenarios. Sometimes the katello build
> breaks on dependencies and then the cache gets out of sync with the
> foreman thus breaking on older builds as well.
> 
> I'd like to merge this in a single installer with one set of modules and
> multiple scenarios. The impact is that the installer will be bigger but
> the katello-installer should be less fragile. It can also simplify
> packaging.
> 
> Care will need to be taken that the needed repositories are present but
> there are multiple ways of fixing this. Currently we assume the user has
> installed the katello release RPM which enables the needed yum
> repositories but that will not be true anymore if we ship it within
> foreman-installer.
> 
> We'll also want to remove/disable the katello scenarios on
> Debian/Ubuntu.
> 
> You may notice I haven't thought this through too much and it may depend
> on a unified Yum repository structure but there are big usability and
> reliability wins we can gain.
> 
> [1]: https://github.com/theforeman/foreman-bats
> [2]: https://github.com/theforeman/forklift
> [3]: https://github.com/theforeman/foreman-packaging
> [4]: https://github.com/katello/katello-packaging
> [5]: https://github.com/theforeman/foreman-packaging/pull/1541
> [6]: https://github.com/theforeman/foreman-installer-modulesync
> [7]: https://github.com/katello/foreman-installer-modulesync
> [8]: https://github.com/katello/katello-installer
> [9]: 

Re: [foreman-dev] Taking over plugins - do we need a policy?

[Marek Hulán]

On úterý 18. července 2017 13:15:22 CEST Greg Sutcliffe wrote:
> Hi all,
> 
> I've been thinking for a while about plugins, and how to continue them
> when original authors move on. It's only natural that developers will
> come and go, so we need to think about how to deal with this. We've got
> a few examples of this now, and have had others in the past.
> 
> 1) I'm playing with Salt in my spare time at the moment, with a view to
> (maybe) taking on the foreman_salt plugin, since Stephen is no longer
> working on it. However, it's only chance that I know this fact -
> there's no easy way for an author to mark a plugin as "orphaned".
> 
> 2) Some plugins are awaiting changes but the author hasn't responded
> (yet!). Foreman_bootdisk has some open PRs at the moment that fall into
> this category (PRs 42, 43 for example), and default_hostgroup has pen
> issues (oops!). Presumably we need a way to ping authors and find out
> if they're just AFK or have stepped away from the plugin entirely.
> 
> 3) Some plugins are definitely abandoned. I recall Chris Pisano taking
> over the foreman_banner plugin last year and struggling to get in touch
> with the original author at all.
> 
> For context, Fedora does have a policy for this that makes some sense:
> 
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintai
> ners
> 
> That's quite heavy, but some of the points make sense. So, do we need
> to add something to our docs about this. My gut feeling is:
> 
> * Yes, we do
> * Only applies to plugins in "theforeman" GitHub repo
> * We need to add extra maintainers to the Rubygems *before* the author
> leaves - Chris had a real issue here. This could be a requirement of
> getting aplugin packaged, for example.
> * We need to allow authors to "abandon" a plugin clearly (something
> like how the Arch User Repository does it maybe?)
> 
> Thoughts?
> Greg

In general +1. I'm not sure if official policy changes anything, probably does 
not do any harm either. It would be great if someone went over all plugins 
under theforeman org on github, found projects with single owner and ask the 
owner to extend the list. Or someone scritped a simple check so we would avoid 
this situation in future. I think what Dmitri described is fair and should 
become a common practice for new repos/gems in our org.

--
Marek

-- 
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] Re: plugin configuration management

[Marek Hulán]

On úterý 18. července 2017 12:15:37 CEST Fairouz el ouazi wrote:
> HI,
>PLease howa can make  GET or Post request on my new plugin ?
> 
> Le mercredi 12 juillet 2017 17:21:49 UTC+2, Fairouz el ouazi a écrit :
> > Hi ,
> > 
> > I want to know if foreman plugin (ansible or chef )   communicate
> > 
> > with the configuration management server or platform (chef or ansible )
> > using theirs rest Api  ?
> > 
> > Thanks

You can use any Ruby library but I would recommend using Rest client as it's 
used elsewhere already. See rest-client documentation [1] for more details. 
Alternatively you can use Net::HTTP library which is built-in Ruby stdlib [2].

However this is not Foreman related so I suggest you consult generic Ruby 
related queries at Ruby support channels.

[1] https://github.com/rest-client/rest-client
[2] http://ruby-doc.org/stdlib-2.4.1/libdoc/net/http/rdoc/Net/HTTP.html

Hope this helps

--
Marek

-- 
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] plugin configuration management

[Marek Hulán]

Hello,

ansible plugin does not contact any external service to my knowledge except 
for smart proxy, chef plugin uses REST API to talk to smart proxy which then 
uses REST API to talk to chef server.

Hope this helps

--
Marek

On středa 12. července 2017 17:21:49 CEST Fairouz el ouazi wrote:
> Hi ,
> 
> I want to know if foreman plugin (ansible or chef )   communicate
> with the configuration management server or platform (chef or ansible )
> using theirs rest Api  ?
> 
> Thanks


-- 
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] Re: Plugins configuration managment platform

[Marek Hulán]

Thanks for the information. I think in this case, it would be good if smart 
proxy plugin would communicate with platform then. But for easier start you 
might start with the foreman plugin only and move the code from foreman plugin 
to smart proxy later if you find the need to proxy the communication. I 
suppose the plugin would be only talking to the platform and not specific 
devices/things.

--
Marek

On pondělí 3. července 2017 10:11:34 CEST Fairouz el ouazi wrote:
> Hello ,
> 
> 
> My platform  is a software suite for IoT / M2M solution integrators
> offering a set of tools to facilitate the interconnection between *devices*
> (or connected *« things »*) and *business applications*:
> 
>-
> 
>*Connectivity Interfaces* (public and private) to collect data, send
>command or notification from/to IoT/M2M devices,
>-
> 
>*Device Management* (supervision, configuration, resources, firmware,
>etc.),
>-
> 
>*Message Routing* between devices and business applications,
>-
> 
>*Data Management*: *Data Storage* with *Advanced Search* features.
> 
> Every device has a particular parameters with a mix of communication modes
> . The devices use MQTT protocol to communicate with  the platform .
> 
> I m looking for a device management that can offer me more functionalities
> so the clients can have more visibility for their  devices . For example i
> want to modify a parameter on multiple devices at the same time : ex:
> device Group . I want to manage different devices with different constraint
> , I want to supervise my devices and  their evolution and it will be just
> great if i could do auto-provisioning (my devices get  automatically an
> existent  configuration and having inventory .
> 
> Le lundi 3 juillet 2017 09:16:05 UTC+2, Marek Hulán a écrit :
> > Hello
> > 
> > the smart proxy chef plugin is only a proxy between Foreman - chef-client
> > and
> > Foreman - chef-server. Most of Foreman functionality proxies the
> > communication
> > through smart-proxy, the idea is that Foreman is running on one place e.g.
> > in
> > office while you need to talk to many hosts in datacenters. These hosts
> > might
> > not be accessible from outside network so you put smart-proxy to the
> > datacenter and make this as the only available endpoint.
> > 
> > It's totally up to you if you decide to go this path, if this is not your
> > case, you can just add one plugin on foreman side. For iot devices it
> > really
> > depends on what you're trying to achieve. Describing that on few examples
> > would help me understand what you need.
> > 
> > On pátek 30. června 2017 14:40:53 CEST Fairouz el ouazi wrote:
> > > Hi , it's me again im really sorry for asking a lot of question but when
> > > take a look to the documetation i didn't get a clear idea about the real
> > > job of smart proxy chef plugin and why on chef we have a client plugin
> >  
> >  and
> >  
> > > on salt we don't have it ?? and if my platform is not agent less would
> > 
> > it
> > 
> > > be necessary to have 3 plugin one on foreman and other one on smart
> > 
> > proxy
> > 
> > > foreman and the third on my  iot devices ?
> > > 
> > > Le mercredi 28 juin 2017 11:50:40 UTC+2, Fairouz el ouazi a écrit :
> > > > Hi everyone ,
> > > > 
> > > >  I'm a beginner in using foreman ,So before in take the adventure
> > 
> > i
> > 
> > > > want to know if the fact that it exists a plugin for managing chef is
> > > > there
> > > > any chance to develop a new one that will manage my own platform  X
> > > > (PLatform that manage IOT  devices ) . So  at place of having chef
> > 
> > client
> > 
> > > > i
> > > > will have foreman dealing with the devices of my X platform . ???
> > > > 
> > > > I really need your help or some ideas or if anyone has face the
> > 
> > same
> > 
> > > > uses cases ?


-- 
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] Re: Plugins configuration managment platform

[Marek Hulán]

Hello

the smart proxy chef plugin is only a proxy between Foreman - chef-client and 
Foreman - chef-server. Most of Foreman functionality proxies the communication 
through smart-proxy, the idea is that Foreman is running on one place e.g. in 
office while you need to talk to many hosts in datacenters. These hosts might 
not be accessible from outside network so you put smart-proxy to the 
datacenter and make this as the only available endpoint.

It's totally up to you if you decide to go this path, if this is not your 
case, you can just add one plugin on foreman side. For iot devices it really 
depends on what you're trying to achieve. Describing that on few examples 
would help me understand what you need.

--
Marek

On pátek 30. června 2017 14:40:53 CEST Fairouz el ouazi wrote:
> Hi , it's me again im really sorry for asking a lot of question but when
> take a look to the documetation i didn't get a clear idea about the real
> job of smart proxy chef plugin and why on chef we have a client plugin  and
> on salt we don't have it ?? and if my platform is not agent less would it
> be necessary to have 3 plugin one on foreman and other one on smart proxy
> foreman and the third on my  iot devices ?
> 
> Le mercredi 28 juin 2017 11:50:40 UTC+2, Fairouz el ouazi a écrit :
> > Hi everyone ,
> > 
> >  I'm a beginner in using foreman ,So before in take the adventure i
> > 
> > want to know if the fact that it exists a plugin for managing chef is
> > there
> > any chance to develop a new one that will manage my own platform  X
> > (PLatform that manage IOT  devices ) . So  at place of having chef client
> > i
> > will have foreman dealing with the devices of my X platform . ???
> > 
> > I really need your help or some ideas or if anyone has face the same
> > 
> > uses cases ?


-- 
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] Plugins configuration managment platform

[Marek Hulán]

Hello,

please see responses below in text

On čtvrtek 29. června 2017 15:07:20 CEST Fairouz el ouazi wrote:
> I m really so greatful for the help taht you give me as a beginner  that's
> why i have just a few questions that seems stupids .
> 1- if i wants to benefits of the functionalities and dashboard of foreman
> do i need to keep smart proxies with puppet or i need to create a new one
> for my (IOT x platform)

Usually plugin creates their own extensions (plugins) for smart proxy. In such 
case you wouldn't need a smart proxy with puppet feature. Smart proxy can 
combine multiple features and it's up to its configuration, which are active. 

You can avoid going through smart proxy completely, but I'd recommend to have 
support for proxying to follow the usual flow of communication in Foreman 
world.

> 2-from documentation i see  that  plugins of cfgmngt can receive data
> (facts ) from client but is there any possibility to take the opposite
> direction is the plugins  capable to send data to clients . for example
> when on foreman i  would like to change the value of one parametres of
> group of node  : does the  clients have  the capability to get it and apply
> the changes .

Plugins can extend Foreman code entirely introducing completely new logic, so 
the answer is yes, you can do that. Depending on your use case, you might be 
interested in remote execution plugin that allows you to run any command on 
any target through SSH. If your devices provides REST API, you might have 
simple job templates (scripts to be executed) using curl and being run on 
smart proxies. See [1] for more details

[1] https://www.theforeman.org/plugins/foreman_remote_execution/0.3/index.html

--
Marek

> 
> Le jeudi 29 juin 2017 13:09:53 UTC+2, Marek Hulán a écrit :
> > Hello,
> > 
> > a good start is reading this [1], looking at [2][3][4][5] and asking
> > questions
> > on #theforeman-dev irc channel on freenode.
> > 
> > [1] http://projects.theforeman.org/projects/foreman/wiki/
> > How_to_Create_a_Plugin
> > [2] https://github.com/theforeman/foreman_chef/blob/master/app/models/
> > foreman_chef/fact_importer.rb
> > <https://github.com/theforeman/foreman_chef/blob/master/app/models/foreman
> > _chef/fact_importer.rb> [3]
> > https://github.com/theforeman/foreman_chef/blob/master/app/models/
> > foreman_chef/fact_name.rb
> > <https://github.com/theforeman/foreman_chef/blob/master/app/models/foreman
> > _chef/fact_name.rb> [4]
> > https://github.com/theforeman/foreman_chef/blob/master/app/models/
> > foreman_chef/fact_parser.rb
> > <https://github.com/theforeman/foreman_chef/blob/master/app/models/foreman
> > _chef/fact_parser.rb> [5]
> > https://github.com/theforeman/foreman_chef/blob/master/lib/foreman_chef/
> > 
> > engine.rb#L81-L83
> > <https://github.com/theforeman/foreman_chef/blob/master/lib/foreman_chef/e
> > ngine.rb#L81-L83>
> > 
> > Hope this helps
> > 
> > On čtvrtek 29. června 2017 10:44:28 CEST Fairouz el ouazi wrote:
> > > Hi, thank for  your answer , my  platform  can communicate over REST API
> > 
> > .
> > 
> > > you said that it would be quite easy to develop a plugin for my cfgmgmt
> > 
> > .
> > 
> > > Can you give me a point from where to start . or documentation .
> > > 
> > > Le mercredi 28 juin 2017 13:58:10 UTC+2, Marek Hulán a écrit :
> > > > On středa 28. června 2017 11:34:00 CEST Fairouz el ouazi wrote:
> > > > > Hi everyone ,
> > > > > 
> > > > >  I'm a beginner in using foreman ,So before in take the
> > 
> > adventure i
> > 
> > > > > want to know if the fact that it exists a plugin for managing chef
> > 
> > is
> > 
> > > > there
> > > > 
> > > > > any chance to develop a new one that will manage my own platform  X
> > > > > (PLatform that manage IOT  devices ) . So  at place of having chef
> > > > 
> > > > client i
> > > > 
> > > > > will have foreman dealing with the devices of my X platform . ???
> > > > > 
> > > > > I really need your help or some ideas or if anyone has face the
> > 
> > same
> > 
> > > > > uses cases ?
> > > > 
> > > > I'm not sure if I understand the question but maybe a generic answer
> > 
> > will
> > 
> > > > help. You can create a plugin that introduces any kind of new object
> > 
> > in
> > 
> > > > Foreman. The simple plugins such as chef/salt/ansible adds new cfgmgmt
> > &

Re: [foreman-dev] Plugins configuration managment platform

[Marek Hulán]

On středa 28. června 2017 11:34:00 CEST Fairouz el ouazi wrote:
> Hi everyone ,
> 
>  I'm a beginner in using foreman ,So before in take the adventure i
> want to know if the fact that it exists a plugin for managing chef is there
> any chance to develop a new one that will manage my own platform  X
> (PLatform that manage IOT  devices ) . So  at place of having chef client i
> will have foreman dealing with the devices of my X platform . ???
> 
> I really need your help or some ideas or if anyone has face the same
> uses cases ?

I'm not sure if I understand the question but maybe a generic answer will 
help. You can create a plugin that introduces any kind of new object in 
Foreman. The simple plugins such as chef/salt/ansible adds new cfgmgmt support 
and can be used as an example how to parse reports and facts of any new 
similar tool. If your IOT device can send some kind of report, it should be 
quite easy to add a plugin for that.

If you want to go futher and let's say create IOT devices as different objects 
than hosts, it's also entirely possible but obviously more complicated.

Hope this helps

--
Marek

-- 
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] [Infra] Service accounts and secret storage

[Marek Hulán]

On pondělí 26. června 2017 14:31:32 CEST Greg Sutcliffe wrote:
> Hey all,
> 
> Continuing the theme of "reducing the bus factor", I want to talk about
> the accounts we use for things like Rackspace, Scaleway, etc.
> 
> Currently the rackspace account actually sends emails to a Red Hat
> address - whilst this is "ok" I'd rather the community had its own
> email address in there. Likewise I'm about to create an account on
> Scaleway and I'd like to avoid using my own Red Hat account.
> 
> We don't have a mailserver for "*@theforeman.org" currently, and it's
> probably overkill to run one. My solution would be to register a new
> GMail account for infra stuff (thefore...@gmail.com or similar) and use
> that for this kind of thing - does that work?
> 
> Then there's the matter of passwords - I don't want to be the only one
> who can access this stuff (really bad bus factor :P). It also needs to
> be easy to add/remove people who can see it. My thoughts turn to GPG -
> perhaps a simple private Gist of the the encrypted data, encrypted with
> all the keys of the people who are allowed to read it? That's easy to
> re-encrypt later if the list of people/keys changes. Or we could host
> the textfile somewhere (on the foreman.org?) I guess...
> 
> Thoughts?

Thanks for doing this. I'd suggest the easiest way possible, just create the 
accounts and share passwords with the rest who should have access. But if 
others prefer GPG, then secret gist sounds reasonable.

--
Marek

-- 
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] Re: Unit test jenkins job with all plugins enabled

[Marek Hulán]

While I agree, one thing that properly defined plugin DSL does not solve is 
the fact, that plugins now depend on each other. Few examples

openscap, katello depends on remote execution
katello, remote execution, ansible, chef, ... depends on foreman tasks
remote execution depends on foreman templates (to some degree)
virt-who-configure depends on katello

Recently, I was lucky to spot that one Katello PR was changing the Hypervisors 
task API while virt-who plugin was subscribed to it, which would cause a 
breakage. We managed to solve that before the PR was merged. Another example 
is that foreman_templates changed import method interface, which caused remote 
execution to fail importing templates so it needed to be fixed. The fix made 
openscap and katello broken because they seed job templates. Openscap was 
fixed in time but Katello 3.4 is now uninstallable if people have remote 
execution enabled and we'll need 3.4.1 to fix it.

I think we need to treat some plugins as core. If we can't merge them to core, 
we should make sure, that their changes don't break other plugins. Therefore I 
think we need some job that verifies that as many plugins as possible are 
continuously green. In my opinion, people working on core usually can avoid 
breaking changes if they know about it. If not, they should provide fixes or 
at least guidance for affected plugins.

--
Marek

On čtvrtek 1. června 2017 18:47:05 CEST Eric D Helms wrote:
> On Thu, Jun 1, 2017 at 10:18 AM, Tomer Brisker  wrote:
> > Hello,
> > 
> > While it is plugin maintainers responsibility to keep their plugins up to
> > date, one of the most common frustrations they face is "core changed and
> > broke something AGAIN". I wouldn't want to slow down core's already slow
> > merge process, but at the same time core contributors should try to
> > minimize breaking plugins as much as possible - for example, by
> > deprecating
> > functions before removing them completely. We could make these tests
> > optional - i.e. not block merge if plugin tests fail, but just take
> > advantage of the tests to fix whatever is needed in the plugins sooner
> > rather then later. I know that in certain cases having katello test run on
> > every PR let us find and fix issues we wouldn't have known about
> > otherwise.
> > Right now contributors (and reviewers) don't have any visibility to
> > whether a PR will cause problems to other plugins. If breaking is
> > unavoidable, at least having plugin tests run on PRs will allow giving a
> > "heads up" to plugin maintainers that they need to fix something, rather
> > then realizing after the next release that something broke.
> > During the past couple of months we had several cases of core PRs leading
> > to broken plugins, which could have been prevented or at least handled
> > better had we known that a certain change requires changes in plugins.
> 
> Agree! If I had to sum it up, developer happiness and innovation at speed
> (core and plugins) is key! One option we've mentioned before that goes
> directly to Tomer's point is a stable plugin API. We as a community both
> develop and tell other developers, come, build a plugin. We have a vibrant
> plugin community. We say plugins are central to the community and project
> yet CI/CD tells a different story. Do we have a defined contract for
> plugins? That would solve a lot of the issues IMO. If we had a supported
> interface (for ALL major use cases of extension, including the UI, since we
> do have a Foreman::Plugin today) then core could make changes at will as
> long as the interface passed testing. Any plugin using functionality not in
> the interface would be SOL but it would be explicitly stated and known.
> 
> Once we get to installation, running in production mode, scenario testing
> things get dicier, less stable and with less testing. A good place to
> invest and bring in other communities (hint: Satlelite QE) to bolster. I'm
> writing a lot of words without action items which I typically try to avoid.
> I want to get our testing and matrices there and am working to bring about
> more time for myself and others to do so. We need to actively invest in
> this area, make it a priority, and a first class citizen of our community
> to make an impact.
> 
> We have wiki pages on creating and releasing plugins. But maybe we need to
> step back and define what a plugin is to our community. I think it would
> also be a fruitful effort to examine the landscape of plugins and see how
> and where they are creating "interfaces" to Foreman.
> 
> 
> Eric
> 
> > As for which plugins to test - I think the best criteria would be to test
> > the 5 or 10 most downloaded plugins or most used plugins according to the
> > community survey.
> > 
> > On Thu, Jun 1, 2017 at 4:50 PM, Lukas Zapletal  wrote:
> >> On Thu, Jun 1, 2017 at 2:55 PM, Eric D Helms 
> >> 
> >> wrote:
> >> > This sounds good in theory, but I'll refresh the 

Re: [foreman-dev] Unit test jenkins job with all plugins enabled

[Marek Hulán]

On čtvrtek 1. června 2017 12:17:25 CEST Lukas Zapletal wrote:
> Hello,
> 
> I would like to open discussion about having a unit test job of
> foreman with all major plugins enabled (katello, discovery, bootdisk,
> rex, openscap). Some of the bugs we found in Discovery 9.0 would have
> been found just by executing unit tests with all the plugins enabled.
> 
> If this is a problem of compute time, let's simply schedule a daily
> job, so at least we know if nightly is stable or not with all the
> plugins enabled.

I agree this became a must. Since 1.15 compose, foreman_templates relies on 
remote_execution template import method which was changed in last version. 
foreman_openscap seeds remote execution job templates, again affected by 
recent change. Result was installer fails with openscap activated, because 
seed failed. Luckily we found it our dev setups before the release but we 
should know whether plugins work together. Otherwise after new stable core 
version is released, we're fixing all plugin for another month.

Based on community survey [1], 89% of our users use plugins. We should treat 
at least most popular ones as part of the core. We already have a way for 
plugins to disable tests, that can't run when the plugin is active. I know 
that e.g. Katello breaks ~200 of Foreman tests so we'd need to fix this first, 
but I definitely support this and I'm happy to help with it.

[1] https://theforeman.org/2017/03/2017-foreman-survey-analysis.html#page2

--
Marek

-- 
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] Re: [RFC] HTTP proxy for requests

[Marek Hulán]

Sorry for being late to the party, sending my 2c:

I agree with having more complicated solution where users could have separate 
proxies per service is good long-term goal. AFAIK we don't the solution atm. 
Therefore I think introducing support for single, global proxy sounds as 
improvement already to what we have now (nothing). What's good on this, 
migrating to specific proxies should be easy, the RFC explicitly[1] mentions 
it. The global proxy can have granular rules of what communication should be 
passed through untouched and what should be sent through maybe other proxies. 
Another advantage I see is that the global proxy offloads the configuration 
from Foreman/Katello, which does not really belongs into our domain.

Later, when the RFC is implemented via foreman_http_proxies plugin, I'm happy 
to stop using global proxy and improve plugins to use foreman_http_proxies if 
it makes sense. It will take some time before everyone adopts it. But 
meanwhile we'd still have the option to let user configure their master proxy 
according to their needs.

[1] https://github.com/theforeman/rfcs/pull/18/
files#diff-12584a6580dac145ae55c2b5d67088dfR45

--
Marek

On středa 17. května 2017 14:22:28 CEST Justin Sherrill wrote:
> On 05/17/2017 07:57 AM, Tom McKay wrote:
> > After reading the RFC I think that more robust and adaptable solution
> > would be better. A single env var is not going to cover the needs of
> > all the scenarios. A simple example may be accessing both
> > registry.access.redhat.com 
> > (through proxy) and myopenshift:5000 (no proxy).
> > 
> > As @jlsherrill noted on the PR, the temporary solution for the
> > foreman-docker plugin is alright for the moment.
> 
> I'd like to echo what tom said, we've had many users that want to access
> content externally through a proxy and internally (where the proxy is
> not controlled by them and does not properly proxy internal requests).
> Its happened enough for me to say that a simple solution is not good
> enough long term.
> 
> > On Wed, May 17, 2017 at 3:08 AM, Sebastian Gräßl
> > 
> > > wrote:
> > There was some feedback regarding this on the PR[1] mentioned in
> > the beginning.
> > There is already a RFC[2] regarding this and a plugin[3] to
> > implement the solution proposed in the RFC.
> > 
> > The solution proposed by jlsherrill allows to add multiple
> > HTTP-proxies in Foreman and use these in plugins and allow to
> > configure what HTTP-proxy should be used for what requests.
> > So far the plugin only adds the ability to add HTTP proxies and
> > misses a essential part, which is applying the HTTP proxies to
> > requests.
> > 
> > While looking at how other applications handle this and also
> > considering typical HTTP proxy configurations, it feels that such
> > a solution would make it rather complex in practice to apply.
> > Configuring rules for requests or just ensuring the proper request
> > is using the right HTTP proxy is better configurable in the HTTP
> > proxy itself.
> > 
> > I believe a very bold simple solution would be the better, which
> > in my opinion would be to ensure all parts respect a HTTP proxy
> > configuration and have good documentation around it to advice on
> > how to configure the HTTP proxy correctly. Taken other
> > applications in the same area the HTTP_PROXY environment variable
> > seems to be the common standard to use.
> > 
> > Please, I would love to hear more feedback on this and what are
> > common HTTP proxy setups.
> > 
> > [1] https://github.com/theforeman/foreman-docker/pull/189
> > 
> > [2] https://github.com/theforeman/rfcs/pull/18
> > 
> > [3] https://github.com/jlsherrill/foreman_http_proxies
> > 
> > 
> > On Thursday, April 20, 2017 at 1:07:33 PM UTC+2, Sebastian Gräßl
> > 
> > wrote:
> > Hej,
> > 
> > at the moment there is a PR[1] open on foreman-docker to set a
> > HTTP proxy for requests to registries.
> > The PR allows to set a HTTP proxy on the HTTP client, in this
> > case deep down Excon, only for registry requests.
> > 
> > A HTTP proxy won't be set on requests if a `HTTP_PROXY`
> > environment variable is available, since it is an unlikely
> > setup to have registry request routed over a different proxy
> > than other requests. However setting it via the environment
> > variable will allow requests to succeed to resources available
> > by the HTTP proxy, but will fail for those inside and possible
> > blocked.
> > 
> > The `HTTP_PROXY` environment variable seems 

Re: [foreman-dev] [RFC] Proposal: make foreman STI to work even when an inherited class is not found in Ruby.

[Marek Hulán]

Thanks for bringing this up. I think the right approach is to have plugin 
uninstallation or rather clean up rake tasks. The clean up should IMHO delete 
all data that would case problems after code removal. It shouldn't try to 
revert the schema changes, but destroy all data that can cause problems.

This was added recently to foreman_templates [1] and it would be great if 
other plugins would follow the same pattern. I think core could provide a 
helper for common clean tasks, such as removing custom settings, but only 
plugin author knows what needs to be cleaned so custom task will always be 
required.

The complete plugin uninstallation means running clean up task and then 
removing the plugin package or bundler dependency. If we inform user that 
clean up task will destroy data and they should do a backup I think we can 
avoid all hacks to make STI work even without class definitions. From my 
experience this only leads to hard to debug issues.

So looking at options Tomas listed, I'd prefer a). In terms of where they 
should live, I'd prefer plugin repos since only maintainers of plugin knows 
what needs to be cleared. Core could provide common helpers that plugin rake 
tasks could use. We'll see after we have it for few plugins what would be a 
good candidate. Foreman maintain could have checks and options for 
uninstalling the plugins using these rake tasks. I'd like to avoid introducing 
this in the installer, puppet does not seems to be the tool that is good fit 
for uninstallation and adding it via hooks sounds like hack.

[1] https://github.com/theforeman/foreman_templates/pull/44

--
Marek

On středa 3. května 2017 11:16:54 CEST Tomas Strachota wrote:
> This issue is tightly coupled with plugin uninstallation and I think
> we should solve the two problems together. At the moment there's no
> standard plugin uninstallation procedure that would take care of
> cleaning up the system. This is something each plugin should provide.
> One thing (imho the less important in this context) is where we put
> such code. Should it be a rake task, part of installer, part of
> maintanance script, somewhere else?
> 
> What I see as more important is to decide what data will the
> uninstallation process remove (keep all vs. keep only settings vs.
> wipe all) and how we want the plugin to behave if it's installed
> again. This will affect how we approach missing STI classes.
> 
> I can see 3 options:
> 
> a) Remove all data
> Plugin would remove all tables and records it created. In such case we
> probably don't need to change the STI behavior. Plugin uninstallation
> should take care of removing the data correctly. If it fails it's fine
> to throw exception to indicate the system integrity is broken. This
> approach is imho safer for us as developers and requires less
> defensive coding.
> 
> b) Keep all the data
> In this case the original data should be present when the plugin is
> installed again. STI records without classes should be completely
> hidden in the default scope. If all records are listed we should
> return either instances of base class or some special class for the
> missing types. I'm afraid this approach is quite fragile and can lead
> to many surprises when a plugin is uninstalled, the foreman lives
> without it for some time and then you install it again. I'm also not
> sure how common is such usecase.
> 
> c) Combination of a) and b)
> We can keep data where it's safe (like settings) and delete the rest.
> 
> I'm in favor of a) or c)
> 
> T.
> 
> On Sun, Apr 30, 2017 at 10:05 AM,   wrote:
> > Hello,
> > 
> > lately I was switching plugins on and off, and I stumbled upon an annoying
> > issue: Many plugins that add some STI classes (for example Katello that
> > adds settings, or Discovery that adds DiscoveredHost).
> > A problem starts when such a plugin is removed from the system, since
> > default STI implementation will throw an error if it can't load a class
> > that corresponds to the :type column in the DB.
> > 
> > I propose a custom handling for such cases, since they are not exactly
> > exceptions in our system design.
> > I was thinking about one of the following options to handle this case, and
> > would like to see a voting which one you prefer. Of course other options
> > can be proposed too.
> > 
> > 1. Return a base class for such records (Maybe with an error already set)
> > 2. Return nil/some kind of special AR object for such records (will
> > require
> > defensive coding while handling heterogeneous lists)
> > 3. Filter those records out with default scope (will require more
> > declaration in plugins, or more DB queries on system startup)
> > 
> > Any thoughts in this area will be much appreciated,
> > 
> > Shim
> > 
> > --
> > 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 

Re: [foreman-dev] Nominating Daniel Lobato for commiter to release related tasks

[Marek Hulán]

On úterý 25. dubna 2017 9:19:40 CEST Dominic Cleal wrote:
> On 24/04/17 12:59, Marek Hulán wrote:
> > based on our handbook [1]. I'd like to nominate Daniel for commit access
> > to
> > 
> > the following repositories:
> >  - foreman-infra
> >  - foreman-installer
> >  - foreman-packaging ( to branch and cherry-pick to the release branch )
> > 
> > Daniel contributes to the project for a long time, also in this area
> > [2][3][4] and always has only the best intentions. He worked on 1.15 RC1
> > and I think there's no reason why he shouldn't have access to places
> > which are needed to update during the release process.
> 
> These repos all have active maintainers and so making a pull request (as
> Daniel's done on two of them) is a better way to make changes. I don't
> think commit access is necessary to submit updates to these repos and
> shouldn't be encouraged here for Foreman releases.

I'm happy to hear that there are active maintainers. I'm not sure whether you 
suggest that it is the reason why commit access should not be granted? I think 
the more active committers the better. Doing this through PR is fine and as 
you say, it can find issues. But if other devs send PRs, I think it makes 
sense if Daniel can merge them. Commit access is also required to create 
branches and tags which I don't think needs any form of reviewing.

I'm sorry if it seemed like I'm encouraging pushing commits directly without 
PR during release process. That was not subject of this nomination.

> Reviews have found a few issues, so I'd suggest continuing to submit
> commits through pull requests.

I'm not sure how it worked for previous releases but I think that it should 
not change and PRs are preferred way unless there's direct commit required in 
rare situations. IMHO that does not change by Daniel becoming a committer.

--
Marek


-- 
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] Nominating Daniel Lobato for commiter to release related tasks

[Marek Hulán]

Hello devs,

based on our handbook [1]. I'd like to nominate Daniel for commit access to 
the following repositories:

 - foreman-infra
 - foreman-installer
 - foreman-packaging ( to branch and cherry-pick to the release branch )

Daniel contributes to the project for a long time, also in this area [2][3][4] 
and always has only the best intentions. He worked on 1.15 RC1 and I think 
there's no reason why he shouldn't have access to places which are needed to 
update during the release process.

Also I'd like to nominate him for the following.

 - access to deb.theforeman.org to change stable, clone repos, and
run freight cache
 - add tags and build targets in koji
 - access to koji.katello.org to copy the mash scripts and configuration
 - access to downloads.theforeman.org to upload signed tarballs
 - permission to set /topic on IRC
 - redmine permissions to modify fields http://projects.theforeman.org/
custom_fields/4/edit (I think administrator permission is required)

The process for getting this is not documented anywhere, but I think it's 
clear that Daniel would only use all of this to improve Foreman.

Please thumbs up in the thread. I'll update the thread in one week in case 
there were some private concerns.

[1] https://theforeman.org/handbook.html#Becomingamaintainer
[2] https://github.com/theforeman/foreman-packaging/pulls?q=is%3Apr+is
%3Aclosed+author%3Adlobatog
[3] https://github.com/theforeman/foreman-installer/pulls?q=is%3Apr+is
%3Aclosed+author%3Adlobatog
[4] https://github.com/theforeman/foreman-infra/pulls?q=is%3Apr+is%3Aclosed
+author%3Adlobatog

--
Marek

-- 
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] omnibus packaging

[Marek Hulán]

Hello

while it would made the packaging easier I don't think it's a very good 
approach. If there's some security issue found in one of deps, we'd need to 
build new version of the whole stack because of that. Btw on rpm based systems 
we use isolated ruby through software collection so it should not interfere 
with your system ruby. I wonder how you install newer system ruby on your 
system, if you use tools like rvm/rbenv it's usually explicitly activated only 
in user shell.

--
Marek

On čtvrtek 20. dubna 2017 0:22:24 CEST jake.plimack via foreman-dev wrote:
> would it be possible to move towards using omnibus packing for theforeman?
> i would love it if TF was self-contained with its own ruby and gems in
> /opt/foreman much like chef/sensu/etc do.
> 
> i have newer system-ruby on my machines than theforeman requires, so
> self-containing all the deps seems like a win-win-win-win as it'll make the
> installer platform agnostic and decouple the dependencies from everything
> else on the system.
> 
> https://github.com/chef/omnibus


-- 
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] Re: Revert removal of @host.params for host_param

[Marek Hulán]

On pondělí 17. dubna 2017 11:22:07 CEST Daniel Lobato wrote:
> Sorry to relive the topic but
> https://github.com/theforeman/foreman/pull/4219 didn't get in,
> and it's time to update the documentation for 1.15 including deprecations.
> 
> Since reverting the change is probably something not to be done during RC,
> I wonder what to do.
> The options are:
> 
> 1. Keep the code as-is - which forces people to change their templates for
> 1.17 for little benefit imo
> 2. Support both options - this would just require to remove the
> deprecations for the next RC which is not a problem
> 3. Support both options and reconsider to remove the helpers?
> 
> Let me know what you think, I lean towards 2 or 3 as I explained in here
> previously.

1. or 2., if we release 1.15 with those macros, I think 3. is not an option.

--
Marek

> 
> 2017年1月11日水曜日 17時05分42秒 UTC+1 Daniel Lobato:
> > Hi foreman devs,
> > 
> > Just noticed today https://github.com/theforeman/foreman/pull/3983/files
> > after some comments on IRC. What's the background behind this change?
> > 
> > As far as I can see, this merely moves
> > 
> > @host.param to host_param
> > @host.param_true? to host_param_true?
> > @host.param_false? to host_param_false?
> > @host.info to host_enc
> > 
> > without gaining anything from the change. This will force people to
> > change their templates (including our community templates) when the
> > deprecation is removed, and there's nothing to gain.
> > 
> > Does someone know what's the rationale behind this change? As it stands
> > right now, I propose reverting that commit entirely to avoid inflicting
> > that pain on users - which include many devs who maintain templates.
> > 
> > Best,
> > 
> > 
> > @dLobatog
> > blog.daniellobato.me
> > daniellobato.me
> > 
> > GPG: http://keys.gnupg.net/pks/lookup?op=get=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.

Re: [foreman-dev] Unify date format in Foreman and plugins

[Marek Hulán]

On čtvrtek 13. dubna 2017 8:13:11 CEST Timo Goebel wrote:
> Am 12.04.17 um 18:21 schrieb Ewoud Kohl van Wijngaarden:
> > On Wed, Apr 12, 2017 at 06:02:34PM +0200, Marek Hulán wrote:
> >> Thanks guys so far, I'm sending comments below in text that are also
> >> relevant for lzap's comments in previous email.
> >> 
> >> On středa 12. dubna 2017 16:56:52 CEST Ewoud Kohl van Wijngaarden wrote:
> >>> I second that there are cases where "ago" is preferred. For the last
> >>> puppet run on the host page it's much easier to know if it was an hour
> >>> ago. Then I don't have to try and remember what day and time it is.
> >>> However, in a table of all puppet reports then the exact date is the
> >>> correct unit. The table of reports with a list of "about 1 month ago"
> >>> has been an annoyance
> >> 
> >> I agree that sometime it's more convenient. On reports page it might be
> >> interesting only for reports that arrived withing last few hours though.
> >> IMHO the consistency is the key here, I'd like to avoid showing 15
> >> minutes ago for times < few hours and full info for the rest. Most of
> >> reports on the page (older than few hours) would benefit from the full
> >> format. Therefore I think full format with "ago" information as tooltip
> >> might be the best compromise?> 
> > On the reports (where you see multiple) then I think the "ago" format
> > isn't useful because the granularity is too low so it's hard to compare.
> > IMHO in a list they should all have the same format. On a host page
> > where you see "Last report: 1 hour ago" it does make sense. I hope that
> > clarifies it.
> 
> I totally agree. Let's not drop the "time ago in words" format entirely.
> It does make sense in a lot of places, especially reports or
> certificates or when a host was created. As a user you probably don't
> care for the exact time. You just want to know approximately when it
> happened.
> E.g. when you push new puppet code to your production servers and start
> to get calls that something is broken, it's enough to know that there
> are puppet reports that indicate a change happend to your servers within
> the last hour. As puppet runs happen, when they happen (and the time
> when puppet applies changes is hard to predict) an exact timestamp isn't
> useful as your cluster slowly starts to degrade over time.

Right, there are places where it makes sense. How about there was always a 
tooltip so when you hover over "ago" it would display timestamp and vice 
versa?

Also I should have separated two things. At some pages (e.g. reports list) I'd 
like to change "ago" to timestamp. We can discuss every occurrence 
individually, when I send a PR, I'll post a link here. Based on above, I won't 
change e.g. smart proxy ca expiration.

Second thing is what the format of timestamp there (and everywhere where we 
use it) should be. And that's something I'd like to unify everywhere including 
plugins. Maybe the core should provide a helper that plugins should use to 
format the date.

--
Marek

-- 
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] Unify date format in Foreman and plugins

[Marek Hulán]

On středa 12. dubna 2017 17:55:21 CEST Marek Hulán wrote:
> On středa 12. dubna 2017 16:14:36 CEST Bryan Kearney wrote:
> > +1 on the format
> > 
> > To make sure I am clear:
> > 
> > 1) Dates will be stored in the DB as UTC.
> 
> yes, but should not matter since the TZ info part of the value and we'd
> always convert it according to current user locale

Sorry, just to clarify what I meant. You were correct, DB will store the time 
info in UTC without TZ info. The input value should contain the TZ info so we 
can always convert it to UTC. Rubocop warns us when DateTime is used without 
TZ in mind. If the input is not in UTC, the easiest way to convert it is 
probably this

  DateTime.now.utc.to_s(:db)

--
Marek

> 
> > 2) Dates will be shown to the user based on their locale.
> 
> yes
> 
> > Questions i have:
> > 
> > a) If I enter a new date, am I entering it in my time zone? Assume
> > serrver is in UTC +1 and I am in UTC -1. If I enter it in at 23:00 on 12
> > April, what is stored in the DB?
> 
> I'm not sure if we enter the time somewhere. AFACT, rex has some time input
> but I'm not sure how it deals with TZs exactly. I think we should use some
> time picker in these cases where users would use their TZ and we should
> convert it to UTC.
> 
> > b) What preference/setting controls (2)
> 
> go to editting form of your profile
> $username in top right corner -> My account
> see Timezone field which defaults to "Browser timezone" but can be set to
> any time zone
> 
> --
> Marek
> 
> > -- bk
> > 
> > On 04/12/2017 09:39 AM, Marek Hulán wrote:
> > > Hello,
> > > 
> > > I'd like to suggest one recommended way of displaying date/time
> > > information on all pages. We started a discussion in a PR [1] that would
> > > change the format for config reports, please take a look there for
> > > possible solutions.
> > > 
> > > After a discussion with Roxanne (cc) on another page we agreed on
> > > following
> > > form to be the best "April 10, 2017 17:08". So no timezone, no seconds,
> > > time is localized in current user timezone. Users can quickly see how
> > > long it was before so we didn't display the "x y ago" information. We
> > > could add it to tooltip if needed.
> > > 
> > > Once nice thing about this format is that Rails provide helper to
> > > generate
> > > it. One could use something like
> > > 
> > > <%= l(report.last_report_at, :format => :long) %>
> > > 
> > > which prints "April 10, 2017 17:08". The month name and potentially the
> > > format is localized based on current user locale.
> > > 
> > > So before I start sending PRs to various places, I'd like to know if we
> > > can
> > > all agree on one form, ideally the suggested one, and try to use it
> > > where
> > > it make sense. Please vote either in here or in the linked PR.
> > > 
> > > The list of various places and formats in Foreman and plugins:
> > > 
> > > * Core *
> > > reports page - reported at column: "about 1 month ago"
> > > dashboard page: "Generated at 12 Apr 12:41"
> > > facts - reported at columns: "about 1 year ago"
> > > trends page: "Last updated 1 day ago"
> > > audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25"
> > > hosts - last report column: 2 months ago
> > > smart proxy - logs - time column: "11. 4. 2017 18:52:31"
> > > smart proxy - puppet ca - ca certificate expiry date: "in almost 4
> > > years"
> > > 
> > > * Plugins*
> > > discovery - last facts upload: "1 day ago"
> > > openscap reports: "about 1 month ago"
> > > tasks - task details info: "2 minutes ago" with tooltip "2017-04-12
> > > 12:49:00 UTC"
> > > rex - jobs: "about 19 hours ago"
> > > rex - logs: "2017-04-11 19:48:09 +0200"
> > > katello - last checking, registered at: "2017-04-12 11:42:06 UTC"
> > > katello - content host tasks: 4/12/17 1:42 PM
> > > 
> > > Katello would probably need to implement the rails helper (or whatever
> > > format we chose) in their UI helpers. Hopefully that's something easy to
> > > do.
> > > 
> > > [1] https://github.com/theforeman/foreman/pull/4419#issue-217527751
> > > 
> > > Thanks for reading and sorry for the long email
> > > 
> > > --
> > > Marek

-- 
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] Unify date format in Foreman and plugins

[Marek Hulán]

Thanks guys so far, I'm sending comments below in text that are also relevant 
for lzap's comments in previous email.

On středa 12. dubna 2017 16:56:52 CEST Ewoud Kohl van Wijngaarden wrote:
> I second that there are cases where "ago" is preferred. For the last
> puppet run on the host page it's much easier to know if it was an hour
> ago. Then I don't have to try and remember what day and time it is.
> However, in a table of all puppet reports then the exact date is the
> correct unit. The table of reports with a list of "about 1 month ago"
> has been an annoyance

I agree that sometime it's more convenient. On reports page it might be 
interesting only for reports that arrived withing last few hours though. IMHO 
the consistency is the key here, I'd like to avoid showing 15 minutes ago for 
times < few hours and full info for the rest. Most of reports on the page 
(older than few hours) would benefit from the full format. Therefore I think 
full format with "ago" information as tooltip might be the best compromise?

> The same goes for the future value, like the puppet ca expiration date.
> Knowing it's in about 4 years is sufficient knowledge. Whether it's in
> May or December isn't that relevent at first sight because I know I
> don't have to worry about it for some time.

Fair enough, in this case we can keep the format we have. Hopefully noone 
starts to replace the certificate when they see "in about 1 hour" :-)

> Regarding the long format I find it much easier to read a table of
> 2017-04-12 rows than April. The length of each record should be constant
> for easy visual comparison. If there is just one value then a
> standardized long format would be preferable.

Understood. I think the change of month in 30 rows is more visible so you 
visually see where one month starts and another begins. Also all April rows 
will have the info of same length. But I don't insist, we'll see when we have 
opinions from more.

--
Marek

> 
> On Wed, Apr 12, 2017 at 04:18:30PM +0200, Lukas Zapletal wrote:
> > I like "ago" format with hover full date value. Thanks for putting
> > effort in this!
> > 
> > LZ
> > 
> > On Wed, Apr 12, 2017 at 3:39 PM, Marek Hulán <mhu...@redhat.com> wrote:
> > > Hello,
> > > 
> > > I'd like to suggest one recommended way of displaying date/time
> > > information on all pages. We started a discussion in a PR [1] that
> > > would change the format for config reports, please take a look there
> > > for possible solutions.
> > > 
> > > After a discussion with Roxanne (cc) on another page we agreed on
> > > following
> > > form to be the best "April 10, 2017 17:08". So no timezone, no seconds,
> > > time is localized in current user timezone. Users can quickly see how
> > > long it was before so we didn't display the "x y ago" information. We
> > > could add it to tooltip if needed.
> > > 
> > > Once nice thing about this format is that Rails provide helper to
> > > generate it. One could use something like
> > > 
> > > <%= l(report.last_report_at, :format => :long) %>
> > > 
> > > which prints "April 10, 2017 17:08". The month name and potentially the
> > > format is localized based on current user locale.
> > > 
> > > So before I start sending PRs to various places, I'd like to know if we
> > > can
> > > all agree on one form, ideally the suggested one, and try to use it
> > > where it make sense. Please vote either in here or in the linked PR.
> > > 
> > > The list of various places and formats in Foreman and plugins:
> > > 
> > > * Core *
> > > reports page - reported at column: "about 1 month ago"
> > > dashboard page: "Generated at 12 Apr 12:41"
> > > facts - reported at columns: "about 1 year ago"
> > > trends page: "Last updated 1 day ago"
> > > audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25"
> > > hosts - last report column: 2 months ago
> > > smart proxy - logs - time column: "11. 4. 2017 18:52:31"
> > > smart proxy - puppet ca - ca certificate expiry date: "in almost 4
> > > years"
> > > 
> > > * Plugins*
> > > discovery - last facts upload: "1 day ago"
> > > openscap reports: "about 1 month ago"
> > > tasks - task details info: "2 minutes ago" with tooltip "2017-04-12
> > > 12:49:00 UTC"
> > > rex - jobs: "about 19 hours ago"
> > > r

Re: [foreman-dev] Unify date format in Foreman and plugins

[Marek Hulán]

On středa 12. dubna 2017 16:14:36 CEST Bryan Kearney wrote:
> +1 on the format
> 
> To make sure I am clear:
> 
> 1) Dates will be stored in the DB as UTC.
yes, but should not matter since the TZ info part of the value and we'd always 
convert it according to current user locale

> 2) Dates will be shown to the user based on their locale.
yes

> Questions i have:
> 
> a) If I enter a new date, am I entering it in my time zone? Assume
> serrver is in UTC +1 and I am in UTC -1. If I enter it in at 23:00 on 12
> April, what is stored in the DB?

I'm not sure if we enter the time somewhere. AFACT, rex has some time input 
but I'm not sure how it deals with TZs exactly. I think we should use some 
time picker in these cases where users would use their TZ and we should 
convert it to UTC.

> b) What preference/setting controls (2)

go to editting form of your profile
$username in top right corner -> My account
see Timezone field which defaults to "Browser timezone" but can be set to any 
time zone

--
Marek


> 
> -- bk
> 
> On 04/12/2017 09:39 AM, Marek Hulán wrote:
> > Hello,
> > 
> > I'd like to suggest one recommended way of displaying date/time
> > information on all pages. We started a discussion in a PR [1] that would
> > change the format for config reports, please take a look there for
> > possible solutions.
> > 
> > After a discussion with Roxanne (cc) on another page we agreed on
> > following
> > form to be the best "April 10, 2017 17:08". So no timezone, no seconds,
> > time is localized in current user timezone. Users can quickly see how
> > long it was before so we didn't display the "x y ago" information. We
> > could add it to tooltip if needed.
> > 
> > Once nice thing about this format is that Rails provide helper to generate
> > it. One could use something like
> > 
> > <%= l(report.last_report_at, :format => :long) %>
> > 
> > which prints "April 10, 2017 17:08". The month name and potentially the
> > format is localized based on current user locale.
> > 
> > So before I start sending PRs to various places, I'd like to know if we
> > can
> > all agree on one form, ideally the suggested one, and try to use it where
> > it make sense. Please vote either in here or in the linked PR.
> > 
> > The list of various places and formats in Foreman and plugins:
> > 
> > * Core *
> > reports page - reported at column: "about 1 month ago"
> > dashboard page: "Generated at 12 Apr 12:41"
> > facts - reported at columns: "about 1 year ago"
> > trends page: "Last updated 1 day ago"
> > audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25"
> > hosts - last report column: 2 months ago
> > smart proxy - logs - time column: "11. 4. 2017 18:52:31"
> > smart proxy - puppet ca - ca certificate expiry date: "in almost 4 years"
> > 
> > * Plugins*
> > discovery - last facts upload: "1 day ago"
> > openscap reports: "about 1 month ago"
> > tasks - task details info: "2 minutes ago" with tooltip "2017-04-12
> > 12:49:00 UTC"
> > rex - jobs: "about 19 hours ago"
> > rex - logs: "2017-04-11 19:48:09 +0200"
> > katello - last checking, registered at: "2017-04-12 11:42:06 UTC"
> > katello - content host tasks: 4/12/17 1:42 PM
> > 
> > Katello would probably need to implement the rails helper (or whatever
> > format we chose) in their UI helpers. Hopefully that's something easy to
> > do.
> > 
> > [1] https://github.com/theforeman/foreman/pull/4419#issue-217527751
> > 
> > Thanks for reading and sorry for the long email
> > 
> > --
> > Marek


-- 
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] Unify date format in Foreman and plugins

[Marek Hulán]

Hello,

I'd like to suggest one recommended way of displaying date/time information on 
all pages. We started a discussion in a PR [1] that would change the format 
for config reports, please take a look there for possible solutions.

After a discussion with Roxanne (cc) on another page we agreed on following 
form to be the best "April 10, 2017 17:08". So no timezone, no seconds, time 
is localized in current user timezone. Users can quickly see how long it was 
before so we didn't display the "x y ago" information. We could add it to 
tooltip if needed.

Once nice thing about this format is that Rails provide helper to generate it. 
One could use something like

<%= l(report.last_report_at, :format => :long) %>

which prints "April 10, 2017 17:08". The month name and potentially the format 
is localized based on current user locale.

So before I start sending PRs to various places, I'd like to know if we can 
all agree on one form, ideally the suggested one, and try to use it where it 
make sense. Please vote either in here or in the linked PR.

The list of various places and formats in Foreman and plugins:

* Core *
reports page - reported at column: "about 1 month ago"
dashboard page: "Generated at 12 Apr 12:41"
facts - reported at columns: "about 1 year ago"
trends page: "Last updated 1 day ago"
audit: "about 1 hour ago" with tooltip saying "April 12, 2017 11:25"
hosts - last report column: 2 months ago
smart proxy - logs - time column: "11. 4. 2017 18:52:31"
smart proxy - puppet ca - ca certificate expiry date: "in almost 4 years"

* Plugins*
discovery - last facts upload: "1 day ago"
openscap reports: "about 1 month ago"
tasks - task details info: "2 minutes ago" with tooltip "2017-04-12 12:49:00 
UTC"
rex - jobs: "about 19 hours ago"
rex - logs: "2017-04-11 19:48:09 +0200"
katello - last checking, registered at: "2017-04-12 11:42:06 UTC"
katello - content host tasks: 4/12/17 1:42 PM

Katello would probably need to implement the rails helper (or whatever format 
we chose) in their UI helpers. Hopefully that's something easy to do.

[1] https://github.com/theforeman/foreman/pull/4419#issue-217527751

Thanks for reading and sorry for the long email

--
Marek

-- 
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] Organization titles in CLI

[Marek Hulán]

On úterý 11. dubna 2017 14:30:50 CEST Tomas Strachota wrote:
> Thanks, i get it now. It's also viable solution.
> One complication is that we would need to find a way how to deprecate
> current usage of --parent in update commands and replace it with
> --new-parent. But it's probably more consistent with how katello works

Sounds reasonable to me

--
Marek

> 
> On Tue, Apr 11, 2017 at 1:51 PM, Andrew Kofink  wrote:
> > Correct. If there are 2 orgs with the same name under different parents,
> > then not specifying `--parent` would result in an error such as "More than
> > one record found".
> > 
> > On Tue, Apr 11, 2017 at 7:08 AM, Tomas Strachota 
> > 
> > wrote:
> >> I'm not sure I understand. It is currently possible to update parents
> >> of organizations. Did you mean to use the parent parameter as a
> >> compound identifier together with names?
> >> 
> >> i.e. for changing a name and a parent you would use:
> >> $ hammer organization update --name Brno --parent EMEA --new-name Krno
> >> --new-parent ...
> >> 
> >> and for info:
> >> $ hammer organization info --name Brno --parent EMEA
> >> 
> >> Did I understand it correctly?
> >> 
> >> On Mon, Apr 10, 2017 at 6:12 PM, Andrew Kofink  
wrote:
> >> > Tomas,
> >> > 
> >> > Would it be easier to print the parent with list/info commands and
> >> > allow
> >> > updating that attribute (i.e. --parent/--parent-id)? We already have a
> >> > handler in the ID resolver when multiple records are returned when only
> >> > one
> >> > is expected, though the error message does not tell the user how to
> >> > further
> >> > filter the results.
> >> > 
> >> > - Andrew
> >> > 
> >> > On Mon, Apr 10, 2017 at 11:09 AM, Tomas Strachota 
> >> > 
> >> > wrote:
> >> >> I recently found out hammer uses only short names for identifying
> >> >> organizations. Names aren't globally unique, which makes it impossible
> >> >> to modify or delete an org when there are two of the same name but
> >> >> nested under a different parent org. See [1] for details.
> >> >> 
> >> >> I opened a preliminary PR [2] that adds option --organization-title to
> >> >> all commands that consume taxonomies and a column "Title" to output of
> >> >> the list command. This is simple solution, consistent with how it
> >> >> works in hostgroups, but I don't think it's the best from the
> >> >> usability point of view. Both options --name and --title as well as
> >> >> table column labels feel redundant (columns contain the same data if
> >> >> orgs aren't nested).
> >> >> 
> >> >> An alternative approach is to completely replace names with labels in
> >> >> hammer internally. We would have to change id resolver and let the
> >> >> list commands print titles (in a column labeled "Name"). That's how
> >> >> it's displayed in UI.
> >> >> 
> >> >> Pros:
> >> >>   - users wouldn't notice the change, it should be seamless in most
> >> >> 
> >> >> cases
> >> >> 
> >> >>   - no need to add extra options
> >> >>   - consistent with the UI, where column labeled "Name" contains
> >> >> 
> >> >> titles in taxonomy tables
> >> >> 
> >> >> Cons:
> >> >>   - name isn't the same as title and it might not feel natural to
> >> >> 
> >> >> update
> >> >> 
> >> >> as:
> >> >> hammer location update --name 'emea/brno' --new-name 'krno' which
> >> >> 
> >> >> would then be displayed as 'emea/krno'
> >> >> 
> >> >> The con I mentioned could be fixed by checking if a user passed a name
> >> >> containing '/' and using only last part of title in such cases. That
> >> >> would make even --new-name 'emea/krno' work.
> >> >> 
> >> >> Theoretically it could be used also for changing organizations parent.
> >> >> --name 'emea/brno' --new-name 'europe/krno' would change parent to an
> >> >> organization with title 'europe' and rename to 'krno'. But that's
> >> >> maybe too much.
> >> >> 
> >> >> How do you find the alternative approach? Do you see any other options
> >> >> how the commands could work? Any idea is welcome.
> >> >> I'd like to change hostgroup commands to use the same style and make
> >> >> it consistent across the whole cli when we find a good solution. Are
> >> >> there any commands in plugins (looking mainly at hammer-cli-katello)
> >> >> that use resources with nested names?
> >> >> 
> >> >> T.
> >> >> 
> >> >> [1] http://projects.theforeman.org/issues/19157/
> >> >> [2] https://github.com/theforeman/hammer-cli-foreman/pull/299
> >> >> 
> >> >> --
> >> >> 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.
> >> > 
> >> > --
> >> > Andrew Kofink
> >> > akof...@redhat.com
> >> > IRC: akofink
> >> > Associate Software Engineer
> >> > Red Hat Satellite
> >> > 
> 

Re: [foreman-dev] Link to redmine issues using prprocessor

[Marek Hulán]

On pátek 7. dubna 2017 14:35:41 CEST John Mitsch wrote:
> The greasmonkey script works great! Really helpful, thanks for sharing. For
> those who are wondering (like I was), it requires the greasemonkey browser
> plugin:
> 
> https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/ or
> 
> ttps://
> chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobf
> kfo?hl=en
> 
> 
> That being said, I don't think we should have developers relying on a
>  script to have links to issues on a PR, I think we should have a way of
> making that link available to everyone like Andrew suggested.

I agree, it would be useful for everyone. +1 if it won't generate extra mail 
notification, +0.5 if it will :-)

--
Marek

> 
> -John
> 
> John Mitsch
> Red Hat Engineering
> (860)-967-7285
> irc: jomitsch
> 
> On Fri, Apr 7, 2017 at 4:17 AM, Ivan Necas  wrote:
> > Ivan Necas  writes:
> > > Walden Raines  writes:
> > >> I do it manually although I probably should just write a commit hook to
> > 
> > do
> > 
> > >> it.
> > >> 
> > >> I put it in the message itself because I think it's useful to have
> > 
> > there in
> > 
> > >> case anyone is browsing the git log or in case we ever move away from
> > >> github.
> > > 
> > > Interesting idea. Before it gets in (+ idea for other places outside of
> > > prprocessor scope), I'm using Tomas's grease monkey script and has been
> > > very helpful in past :)
> > 
> > Forgot to put a link:
> > https://gist.github.com/tstrachota/012d1518a08d5a9d441f
> > 
> > -- Ivan
> > 
> > > -- Ivan
> > > 
> > >> Walden
> > >> 
> > >> On Thu, Apr 6, 2017 at 5:33 PM, Andrew Kofink 
> > 
> > wrote:
> > >>> Walden, you have a script that adds it, or do you do it manually for
> > 
> > every
> > 
> > >>> issue? If the latter, then wouldn't this save you some time? ;)
> > >>> 
> > >>> On Thu, Apr 6, 2017 at 5:24 PM, Walden Raines 
> > 
> > wrote:
> >  I like it although I include the links to the issues in my actual
> > 
> > commit
> > 
> >  message so it will be doubled up in my case.
> >  
> >  
> >  
> >  On Thu, Apr 6, 2017 at 4:18 PM, John Mitsch 
> > 
> > wrote:
> > > +1 from me :)
> > > 
> > > John Mitsch
> > > Red Hat Engineering
> > > (860)-967-7285 <(860)%20967-7285>
> > > irc: jomitsch
> > > 
> > > On Thu, Apr 6, 2017 at 3:05 PM, Andrew Kofink 
> > > 
> > > wrote:
> > >> I find myself copying/pasting issue numbers from GitHub PRs to a
> > >> redmine url way too much every day. It takes a bit of time, and
> > >> it's
> > >> annoying as well as easy to fix.
> > >> 
> > >> I've submitted this PR to comment on a newly submitted PR with
> > 
> > links to
> > 
> > >> the associated issues in redmine: https://github.com/th
> > >> eforeman/prprocessor/pull/59 I'd like to hear your thoughts if you
> > >> have something to say about it.
> > >> 
> > >> - Andrew
> > >> 
> > >> --
> > >> Andrew Kofink
> > >> akof...@redhat.com
> > >> IRC: akofink
> > >> Associate Software Engineer
> > >> Red Hat Satellite
> > >> 
> > >> --
> > >> 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.
> >  
> >  --
> >  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.
> > >>> 
> > >>> --
> > >>> Andrew Kofink
> > >>> akof...@redhat.com
> > >>> IRC: akofink
> > >>> Associate Software Engineer
> > >>> Red Hat Satellite
> > >>> 
> > >>> --
> > >>> 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 

Re: [foreman-dev] Dev/Design Weekly Meeting - Subscriptions

[Marek Hulán]

Hello Sean,

I'm sorry if we created a feeling that we're doing something behind closed 
doors.

Let me explain the background. When Roxanne started to look at the UI/UX 
improvements we quickly realized that Foreman with all its plugins is a big 
application and it seemed as too much to digest at once. So we decided to 
start introducing smaller, isolated parts of the whole thing to her once a 
week. Each week we sit and talk about specific area. I hope that it helps 
Roxanne to understand how the project is interconnected so she can suggest 
larger changes consistent across the whole app after some time.

Also as part of these demos, she takes notes of small items that we can fix 
right away, such as "this inline help does not provide a value", "this button 
should not be red". So it's not really a discussion or designing of new stuff, 
it's rather a demo for a certain area.

Roxanne provides the notes from these sessions for what could be improved. If 
those are low hanging fruit we try to fix it right away. Since she shares 
notes during these sessions and share them with everyone so people who are 
interested could also add their comments. All changes are going through PRs 
and the discussion, if necessary, happens there.

I think sharing these notes is also useful for people who'd like to contribute 
with code and are looking for something small.

I hope it makes better sense now.

--
Marek

On úterý 14. března 2017 22:43:39 CET Sean O'Keeffe wrote:
> Firstly thanks for all the valuable input Roxanne, I'm just a bit concerned
> about discussions that to me at least appear to be happening behind closed
> doors.
> 
> When do these "Dev/Design Weekly Meeting" take place?
> Have they ever been advertised on this mailing list or anywhere publicly? I
> haven't seen anything, maybe I missed it?
> If not, why not?
> 
> Having conversations behind closed doors that have such a large impact on
> the project is not a good thing.
> To me, sending notes about a meeting that I can only assume happens within
> redhat every week is quite inappropriate. Not only does it make people in
> the community feel excluded from important discussions, but it also shows
> the sway and power redhat has within this community, which in my opinion
> shouldn't be the case.
> 
> I get that redhat will want to make suggestions that benefit itself and us
> and maybe sometimes just itself but this is not the right way to go about
> it. We need to have open discussions.
> 
> Sean
> 
> On Mon, Mar 13, 2017 at 3:02 PM, Roxanne Hoover  wrote:
> > https://docs.google.com/document/d/1zqK49SNLMA2t8SHen4M2z6-Z
> > gsVk3oKEQsCwxcK6d6A/edit
> > 
> > 
> > Subscription Management
> > 
> > Presented by Thomas McKay
> > 
> > 
> > Subscription Manifest -- no manifest yet
> > 
> >-
> >
> >Manifest history -- no message/time… it should state as much.
> >-
> >
> >More direct route to Upload… entire page not necessary because it has
> >no data.
> >-
> >
> >Upload success inline messaging lacks icon.
> > 
> > Subscription Manifest - already manifest
> > 
> >-
> >
> >Delete Manifest is a big deal.
> >-
> >
> >IMport History tab might not be necessary
> >-
> >
> >“Upstream Subscription Management Application” - wraps to 4 lines,
> >creates awkward empty space and could be confused for independant
> >labels.
> >-
> >
> >Can the Upload button Delete and then Upload… Tom says no.
> >-
> >
> >Page doesn’t refresh after delete. Delete is nuclear with no warning.
> >-
> >
> >Inline messaging is all over the place, grey is at bottom, red is in
> >the middle (from bad upload), and success delete was at the top.
> >-
> >
> >Also - error on upload was in an inline messaging pattern vs. form
> >error which is typical in other areas of forum.
> > 
> > Product Content Tab
> > 
> >-
> >
> >Items are added/removed from another page… integration would be nice,
> >content could at least be formatted for Patternfly as the negative
> >positive
> >accordion is not standard.
> > 
> > --
> > 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] No provisioning templates in dev foreman

[Marek Hulán]

Hello,

You can run rake db:seed multiple times and it should always only seed missing 
data (non-destructive). If you want to be extra sure, just do the db backup 
beforehand. And yes, the file that you linked should create template kinds and 
templates.

Hope this helps

--
Marek

On čtvrtek 9. března 2017 14:12:42 CET Tyler Gregory wrote:
> Yes, I did that when setting up the environment initially. I assume this
>  ng_templates.rb> is the seed file which populates the DB with the templates
> and their types? Is it possible to run that independently of the other seed
> tasks? If I were to run db:seed again would it be non-destructive to data
> I've entered already, such as compute resources?
> 
> On Thursday, March 9, 2017 at 3:37:52 PM UTC-6, ohadlevy wrote:
> > On Thu, Mar 9, 2017 at 10:46 PM, Tyler Gregory  > 
> > > wrote:
> >> Hello all,
> >> 
> >> I'm developing a plugin so that foreman can use Azure Resource Manager,
> >> and I'm at the point where I would like to start deploying some VMs. I've
> >> set up a development environment as described here
> >> ,
> >> however there are no provisioning templates available. When I try to
> >> create
> >> them, the "Type" field is empty, and when I try to use the templates
> >> plugin  to sync
> >> templates I get errors about the templates being of an unrecognized type,
> >> eg:
> >> 
> >> Skipping: 'Community Alterator default finish' - Unknown template kind
> >> 'finish'
> >> Skipping: 'Community Alterator default' - Unknown template kind
> >> 'provision'
> >> Skipping: 'Community Alterator default PXELinux' - Unknown template kind
> >> 'PXELinux'
> >> Skipping: 'Community AutoYaST default iPXE' - Unknown template kind
> >> 'iPXE'
> >> 
> >> I assume there's a rake task I need to run or some such, but being
> >> unfamiliar with Foreman itself and only slightly more familiar with RoR
> >> development I thought I'd ask instead of risking trashing my environment.
> >> 
> >> Platform Configuration:
> >>- MacOS 10.12.3
> >>- Ruby 2.1.9
> >>- Using SQLite db
> >>- Developing against 1.14-stable
> >>- Only change to Foreman itself has been to update fog-core to 1.43
> >>to satisfy a dependency of fog-azure-rm
> > 
> > Just double checking, did you rake db:seed ?
> > 
> > Ohad
> > 
> >> Any help is much appreciated


-- 
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] Form labels help icon change

[Marek Hulán]

Hello

a PR [1] changing the form labels help icons was merged yesterday and will be 
part of upcoming 1.15 release. The change moved icons with popover help from 
right of the form field to the field label. If you're author of plugin that 
extends Foreman UI by fields with such help, you might want to update your 
plugin to avoid UI mismatches, see screen shot [2] for illustration.

Good examples can be found at the original PR or plugin PRs I sent to REX [3], 
discovery [4] and tasks [5]. Openscap, docker did not seem to need it. Katello 
seems to have such help next to value (subscription info) and does not use 
core helpers.

If you need help with you plugin, please let me know.

[1] https://github.com/theforeman/foreman/pull/4358
[2] https://cloud.githubusercontent.com/assets/109773/23611108/
eb2a3bb2-0275-11e7-901f-047b861fa885.png
[3] https://github.com/theforeman/foreman_remote_execution/pull/234
[4] https://github.com/theforeman/foreman_discovery/pull/333
[5] https://github.com/theforeman/foreman-tasks/pull/240

--
Marek

-- 
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] Seeding templates overrides custom changes - should we lock templates we ship?

[Marek Hulán]

I don't think that would fix it. The attribute can be used to limit the base 
of audits that we are searching for - e.g. only templates which content has 
changed, but the method still checks whether name has changed at the end.

So it seems we have +1 from everyone so far, I'll try to find some time and 
send a PR this week.

Thanks everyone involved

--
Marek

On úterý 21. února 2017 8:56:15 CET Stephen Benjamin wrote:
> Oh :-(
> 
> It looks like the fix would be just to pass the `template` attribute
> to  audit_modified?, it can check other attributes than name.
> 
> But locking the templates we ship would be preferable to me.
> 
> 
> - Stephen
> 
> On Fri, Feb 17, 2017 at 9:04 AM, Marek Hulán <mhu...@redhat.com> wrote:
> > Hello foreman-devs,
> > 
> > recently I was told about the bug that we override all templates in
> > database whenever we run db:seed. From the code [1] and commit message
> > [2], it was not the intended behavior. It was supposed to check whether
> > user made some changes and only apply the new version if the template was
> > not touched. Sadly, the method only checks the name attribute for changes
> > [3], so if "only" template content was changed, we still override it.
> > 
> > While I can try to fix it to originally intended behavior, I'd like to ask
> > whether it wouldn't be better to use this opportunity and start locking
> > templates we ship by default. The recommended workflow for users would be
> > to clone the template if custom changes are needed. We'd always update
> > locked templates. Obviously, user would need to merge new version to
> > cloned template on his own. With foreman_templates plugin it should be
> > easy enough to export templates and see the diff between default and
> > customized template, apply the changes user wants and then reimport them
> > back.
> > 
> > I think this would be overall better user experience and safer workflow.
> > The originally intended behavior would never update a template that user
> > modified. That means after update user ends up with template from old
> > Foreman version (with custom changes) that might not be compatible with
> > the new Foreman version. This is more likely to happen than before
> > because we now version templates in community-repo and we don't keep
> > backward compatibility as we did before.
> > 
> > Thanks for reading, thoughts?
> > 
> > [1]
> > https://github.com/theforeman/foreman/blob/1.14.0/db/seeds.d/07-provision
> > ing_templates.rb#L98 [2] https://github.com/theforeman/foreman/commit/
> > d4ed70154fa9f6c83597adc784240e3865845563
> > [3] https://github.com/theforeman/foreman/blob/1.14-stable/db/seeds.rb#L33
> > 
> > --
> > Marek
> > 
> > --
> > 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] Re: Seeding templates overrides custom changes - should we lock templates we ship?

[Marek Hulán]

Since we override all templates atm, I think it's not a big change. We're 
(sadly) not dropping backwards compatibility. Templates can be unlocked by 
admin or users with proper permission, but it would be opt-in now. And we 
should document this workflow in release notes and manual ofc.

--
Marek

On pondělí 20. února 2017 17:35:59 CET Ohad Levy wrote:
> On Mon, Feb 20, 2017 at 4:58 PM, Ivan Necas <ine...@redhat.com> wrote:
> > Timo Goebel <m...@timogoebel.name> writes:
> > > +1 to locking. This is the only workflow that makes sense imho.
> > > Please note, that we need [1] merged first.
> > 
> > +1 - let's set the right expectations
> 
> I think its +1 across, the main question i have is is a minor Y version
> bump is enough or does this fall into the category of 2.0 release?
> 
> Ohad
> 
> > -- Ivan
> > 
> > > - Timo
> > > 
> > > [1] https://github.com/theforeman/foreman/pull/4283
> > > 
> > > Am Freitag, 17. Februar 2017 15:05:13 UTC+1 schrieb Marek Hulán:
> > >> Hello foreman-devs,
> > >> 
> > >> recently I was told about the bug that we override all templates in
> > >> database
> > >> whenever we run db:seed. From the code [1] and commit message [2], it
> > 
> > was
> > 
> > >> not
> > >> the intended behavior. It was supposed to check whether user made some
> > >> changes
> > >> and only apply the new version if the template was not touched. Sadly,
> > 
> > the
> > 
> > >> method only checks the name attribute for changes [3], so if "only"
> > >> template
> > >> content was changed, we still override it.
> > >> 
> > >> While I can try to fix it to originally intended behavior, I'd like to
> > 
> > ask
> > 
> > >> whether it wouldn't be better to use this opportunity and start locking
> > >> templates we ship by default. The recommended workflow for users would
> > 
> > be
> > 
> > >> to
> > >> clone the template if custom changes are needed. We'd always update
> > 
> > locked
> > 
> > >> templates. Obviously, user would need to merge new version to cloned
> > >> template
> > >> on his own. With foreman_templates plugin it should be easy enough to
> > >> export
> > >> templates and see the diff between default and customized template,
> > 
> > apply
> > 
> > >> the
> > >> changes user wants and then reimport them back.
> > >> 
> > >> I think this would be overall better user experience and safer
> > >> workflow.
> > >> The
> > >> originally intended behavior would never update a template that user
> > >> modified.
> > >> That means after update user ends up with template from old Foreman
> > >> version
> > >> (with custom changes) that might not be compatible with the new Foreman
> > >> version. This is more likely to happen than before because we now
> > 
> > version
> > 
> > >> templates in community-repo and we don't keep backward compatibility as
> > 
> > we
> > 
> > >> did
> > >> before.
> > >> 
> > >> Thanks for reading, thoughts?
> > >> 
> > >> [1]
> > >> https://github.com/theforeman/foreman/blob/1.14.0/db/seeds.
> > 
> > d/07-provisioning_templates.rb#L98
> > 
> > >> [2] https://github.com/theforeman/foreman/commit/
> > >> d4ed70154fa9f6c83597adc784240e3865845563
> > >> <https://github.com/theforeman/foreman/commit/
> > 
> > d4ed70154fa9f6c83597adc784240e3865845563>
> > 
> > >> [3] https://github.com/theforeman/foreman/blob/1.14-stable/db/
> > 
> > seeds.rb#L33
> > 
> > >> --
> > >> Marek
> > > 
> > > --
> > > 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.


-- 
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] Opinions from plugin maintainers wanted: permissions and roles

[Marek Hulán]

Thaks for summary, just one quick comment where I think it needs clarification

On středa 25. ledna 2017 13:59:57 CET Lukas Zapletal wrote:
> Corrections.
> 
> > Why you don't like explicit lock actions?
> 
> I misinterpreted your statements above, looks like we both like
> explicit locking.
> 
> > add_permission_to_provisioning_manager (also adds to "manager" role)
> > add_permission_to_provisioning_reader (also adds to "reader" role)
> > add_permission_to_configuration_manager (also adds to "manager" role)
> > add_permission_to_configuration_reader (also adds to "reader" role)
> 
> This was just a copy and paste error ^ anyway.
> 
> I think I was throwing ideas too much, let me summarize my attitude on
> the PR and filter out ideas that are nice to have but not part of the
> PR effort. What I think the PR should do:
> 
> - the API makes sure we can declaratively identify all permissions
> which were added by plugins (for comparison, currently "default_roles"
> hash) (*)
> - the API deprecates "default_roles" hash providing alternative list
> of default plugin roles and permissions
> - the API provides a way to work with plugin roles (so Discovery
> Manager/Reader will work with the new PAI)
> - the comparison "plugin:validate_roles" rake task is modified to work
> with the new API (it depends on "default_roles" hash)
> 
> (*) the only change in the worst case is to keep track of plugin names
> which are adding permissions so we have a list of plugins and
> permissions added
> 
> Nice to have:
> 
> - the API can work fine with locking and cloning proposal
> - the API is used both for plugins and core (currently seed script)
> - the API can be easily extended to what Ivan proposed (I like the
> concept of fine-grained roles)
> 
> I still have strong opinion on modifying main Manager/Reader role, I
> don't think the original assumption from the RFE that Manager must
> have all permissions is not valid. IMHO if user really expect manager
> of everything, then there's this Administrator flag, "a manager user"
> is required to have "Manager" role plus "Plugin Manager" for all
> plugins. We could provide an example (locked) user called Site Manager
> as an example if the issue is understanding that. But this is
> non-blocking statement. It's a different view of what is best for the
> customer.

Manager is not Administrator (common misunderstanding). Administrator can 
modify settings which is more or less application configuration. We don't 
allow any non-admin user to do this, there's no permission for it and we 
explicitly check "user.admin?" in there. There are more exceptions like this, 
e.g. "Any context" behavior. Also we need to address the use case where you 
want to have "Manager of Organization A". We allow that by cloning Manager 
role and assigning the organization to this clone.

--
Marek

> If we implement a way to automatically add all possible permissions to
> Manager (and read permissions to Reader), we could automatically make
> sure that Manager/Reader have all the require permissions and adding
> to the main two roles is irrelevant. If we take the declaration
> approach we are not closing doors to this I believe.


-- 
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] Opinions from plugin maintainers wanted: permissions and roles

[Marek Hulán]

On pondělí 23. ledna 2017 17:07:30 CET Lukas Zapletal wrote:
> > If you're concerned about the permissions table, this does not help.
> > Permission are created there by plugin. If the permission is removed
> > later, it should be removed from all roles anyway, user could already
> > assign it to both core and plugin role.
> 
> Down below.
> 
> > I suppose you wrote a migration that unassigned this permission from all
> > filters and removed the permission from permissions table. Why does this
> > not work for core?
> 
> I agree that technically no difference, but ability to have a list of
> default roles and permissions (what I call "pull mechanism" but
> basically its a list or hash of these) allows us to audit this. It's
> something we already have today (hashes for core is in seeds, hashes
> for plugins can be added via the existing API hash mentioned). I
> simply think that we lost track of this when we will be creating new
> permissions for existing roles via this call (usually in engine.rb).
> 
> >> I really think we need to say "this is by design, add required roles
> >> which are provided by plugins" here. Not all RFEs are valid.
> > 
> > IMHO this is usability issue. And therefore valid RFE.
> 
> Sure, I made it to extreme, but I am trying to put the requirement
> from the RFE on weights together with above.
> 
> > I read your counter-proposal (I don't think it's "counter" :-) If I
> > understand it correctly, we could break i down into following steps.
> > 1) add DSL to extend core roles
> > 2) make core roles locked for editing
> 
> Locking is indeed nice, but it does not solve my concerns above - lost
> track. But I like it, let me build on top of that: what if the API was
> adding the permission twice - once into the core (locked) role and
> once into "PluginName Manager/Reader" (locked) role as a copy. So
> users could decide what to include for their Users or UserGroups. This
> could keep some flexibility and also enable better audit. The API
> would be responsible for copying them so plugin authors would not
> care.

Yup, that was the plan from the very beginning, just without locking. Locking 
can be added and everyone is happy.

> 
> > 3) add DSL to remove permissions from roles
> 
> I don't insist on this one, removing permissions can be done via
> migrations as you noted. This only makes sense if it's actually better
> to have such an API method(s). It might end up in situation when
> migration would have been much more easier and cleaner - then this is
> a no go of course.
> 
> > I find the locking better since it's similar concept to templates where we
> > have the same problem. But I like the proposal in general for future
> > plugin
> > uninstallation. If audit can't give us the answer we should start tracking
> > it, ideally the same way for all resources created by plugin.
> 
> Sure, locking is a good start, my biggest concern was to have a role
> (e.g. Manager) modified by core, plugins, users. Three individual
> subjects, locking should help here.
> 
> If locking is the thing we agreed here, I vote for implementing it
> with the new API so we are clean from the day one. Technically we can
> make the upgrade easier if we decide to create new locked roles with
> names like "Default Manager" and "Default Reader" (or Viewer not sure)
> keeping the original "Manager" and "Reader" unchanged. If we also
> implement a comparison tool, that is huge improvement in user
> experience IMHO.

Ok, we discussed the migration path. We should be (with small changes*) able 
to detect whether users modified existing Manager role. In case they did, we 
would rename them to "Customized Manager" and create new Manager role with 
default permissions but locked. Locked means no changes to filters and 
attributes can be made by user, plugin can extend via plugin DSL. If existing 
Manager role was not changed we just lock it. The same for the Viewer. No 
locking/unlocking actions as we have for templates. If this is acceptable 
migration path, then I think we can start working on it.

Ivan had also a good point with task oriented roles. Once we have locking we 
can add more locked roles like "Provisioning capabilities". And potentially 
revisit automatic adding permissions to locked Manager and Viewer roles so 
they won't get out of sync.

Sounds as a plan?

*small changes means we extract hashes of permissions in seeds to some 
constant so it's available without running seeds and extending existing plugin 
DSL method "role" so we know whether plugin extends existing Manager/Viewer 
role or user did it manually.

--
Marek


-- 
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] Opinions from plugin maintainers wanted: permissions and roles

[Marek Hulán]

On úterý 24. ledna 2017 0:02:15 CET Ivan Necas wrote:
> Lukas Zapletal  writes:
> >> If you're concerned about the permissions table, this does not help.
> >> Permission are created there by plugin. If the permission is removed
> >> later, it should be removed from all roles anyway, user could already
> >> assign it to both core and plugin role.
> > 
> > Down below.
> > 
> >> I suppose you wrote a migration that unassigned this permission from all
> >> filters and removed the permission from permissions table. Why does this
> >> not work for core?
> > 
> > I agree that technically no difference, but ability to have a list of
> > default roles and permissions (what I call "pull mechanism" but
> > basically its a list or hash of these) allows us to audit this. It's
> > something we already have today (hashes for core is in seeds, hashes
> > for plugins can be added via the existing API hash mentioned). I
> > simply think that we lost track of this when we will be creating new
> > permissions for existing roles via this call (usually in engine.rb).
> > 
> >>> I really think we need to say "this is by design, add required roles
> >>> which are provided by plugins" here. Not all RFEs are valid.
> >> 
> >> IMHO this is usability issue. And therefore valid RFE.
> > 
> > Sure, I made it to extreme, but I am trying to put the requirement
> > from the RFE on weights together with above.
> > 
> >> I read your counter-proposal (I don't think it's "counter" :-) If I
> >> understand it correctly, we could break i down into following steps.
> >> 1) add DSL to extend core roles
> >> 2) make core roles locked for editing
> > 
> > Locking is indeed nice, but it does not solve my concerns above - lost
> > track. But I like it, let me build on top of that: what if the API was
> > adding the permission twice - once into the core (locked) role and
> > once into "PluginName Manager/Reader" (locked) role as a copy. So
> > users could decide what to include for their Users or UserGroups. This
> > could keep some flexibility and also enable better audit. The API
> > would be responsible for copying them so plugin authors would not
> > care.
> > 
> >> 3) add DSL to remove permissions from roles
> > 
> > I don't insist on this one, removing permissions can be done via
> > migrations as you noted. This only makes sense if it's actually better
> > to have such an API method(s). It might end up in situation when
> > migration would have been much more easier and cleaner - then this is
> > a no go of course.
> > 
> >> I find the locking better since it's similar concept to templates where
> >> we
> >> have the same problem. But I like the proposal in general for future
> >> plugin
> >> uninstallation. If audit can't give us the answer we should start
> >> tracking it, ideally the same way for all resources created by plugin.
> > 
> > Sure, locking is a good start, my biggest concern was to have a role
> > (e.g. Manager) modified by core, plugins, users. Three individual
> > subjects, locking should help here.
> > 
> > If locking is the thing we agreed here, I vote for implementing it
> > with the new API so we are clean from the day one. Technically we can
> > make the upgrade easier if we decide to create new locked roles with
> > names like "Default Manager" and "Default Reader" (or Viewer not sure)
> > keeping the original "Manager" and "Reader" unchanged. If we also
> > implement a comparison tool, that is huge improvement in user
> > experience IMHO.
> 
> Let me offer a bit different view on this. When looking at the
> permissions from user perspective, they are very granular. This is great
> when you need to achieve something really specific, but most of the
> time, viewer (read only access), user (use the feature) and manager
> (configure the feature) could work for 80% of users that need something
> more than just admin.
> 
> Therefore, I wonder if we should not start thinking about grouping
> permissions based on features they are related to and scope of power,
> and then let the roles to be build using this metadata.
> 
> Example: provisioning permission group would contain Host, Domain, Compute
> Resource, Image… permissions. Orthogonal to the feature, the permissions
> would also have a flag, if they are meant for viewer, user or manager
> (the same decision you make if you put the permission in core/plugin
> viewer/manager role)
> 
> In a role, instead of putting the individual permissions there directly,
> I would say, using this role, I want to be able to use provisioning, so
> including the viewer and user permission from provision group. The
> permission groups would be controlled by the code (not users). What
> users could do, when including a specific permissions group, would be to
> say if they want opt-in/opt-out specific permission. I expect, most of
> the time people would trust the developers to put the right permissions
> into the features and scopes.
> 
> The similar way, I could add OpenSCAP 

Re: [foreman-dev] Opinions from plugin maintainers wanted: permissions and roles

[Marek Hulán]

Thanks for update, sending few more comments below in text

On pondělí 23. ledna 2017 12:48:46 CET Lukas Zapletal wrote:
> > Sorry I don't get it, especially the price. What's the difference between
> > core and plugins in terms of permissions upgrades? If you rename plugin
> > permission you need to provide the same migration as if you renamed it in
> > core.
> Once we merge everything into core roles, there is no easy way back. I
> described above why I think a pull-mechanism (with separated roles) is
> better that the proposal.

If you're concerned about the permissions table, this does not help. 
Permission are created there by plugin. If the permission is removed later, it 
should be removed from all roles anyway, user could already assign it to both 
core and plugin role.

> > Currently we don't support plugin uninstallation, when we do we'll likely
> > have a tool to say which permission should be removed.
> 
> We had a need of removing a permission for existing plugin, this had
> nothing to do with uninstallation. We added it by mistake basically.
> But what happens if we decide to implement plugin uninstallation? The
> proposal only makes it more tough.

I suppose you wrote a migration that unassigned this permission from all 
filters and removed the permission from permissions table. Why does this not 
work for core?

> > The only other option I see to make this usable is to precreate user group
> > that plugins would assign their roles to. But I'd say that's the same
> > thing
> > just in different model. The user reports (see the mirroring BZ [1]) and
> > especially the way they were reported convinces me we need to change the
> > current status. If users open issues because they can't see a button even
> > when they have role "viewers" then I think it's our fault.
> 
> I think we need to improve how we report missing permissions overall,
> that it will not be such a pain in finding particular role or
> permissions and we can keep it separate.
> 
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1304608
> 
> I really think we need to say "this is by design, add required roles
> which are provided by plugins" here. Not all RFEs are valid.

IMHO this is usability issue. And therefore valid RFE.

> Anyway, summary of my opinion:
> 
> * I am not against adding an API call to add permissions to roles in
> general.
> * I'd prefer pull mechanism rather than push.
> * I do not like particularly modifications of core roles, I think we
> should keep it separate and more focus on improving usability,
> reporting and documentation around.
> * I described my counter-proposal in the PR comment from this morning.

I read your counter-proposal (I don't think it's "counter" :-) If I understand 
it correctly, we could break i down into following steps.
1) add DSL to extend core roles
2) make core roles locked for editing
3) add DSL to remove permissions from roles

This thread started by discussion on automatically adding plugin permissions 
to core roles. So I guess that could only happen if we had 1-3. I'm fine with 
skipping automatically extending core roles until we're ready.

> > There is one alternative proposal that comes to my mind - what if we
> start tracking what created permissions. It could be core permission
> installed during seed, plugin permission created by plugin API or
> user-defined permission. This could help with permission deletion (if
> it is not user-defined it will be less likely intrusive change to
> delete it), it can possibly help with plugin uninstallation in the
> future, it can improve debugging (ability to compare current state
> with expected permission list). But I still think a pull mechanism API
> would be better (that separates core and plugin permissions clearly
> from user-defined).

I find the locking better since it's similar concept to templates where we 
have the same problem. But I like the proposal in general for future plugin 
uninstallation. If audit can't give us the answer we should start tracking it, 
ideally the same way for all resources created by plugin.

> Please do not understand this as hard-blocking your PR, I am trying to
> write constructive notes on how to take a different approach. If you
> think what is proposed in the PR is better, then just go ahead and I
> will simply put my hands off from the review. I would love to hear
> other opinions on that topic, I am surprised it's just us three/four
> discussing this as everyone is using permissions and roles as
> developers or as users.

+1

--
Marek


-- 
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 foreman-tasks to the core: the plan

[Marek Hulán]

On pátek 20. ledna 2017 2:51:06 CET Ewoud Kohl van Wijngaarden wrote:
> On Thu, Jan 19, 2017 at 06:04:58PM +0100, Ivan Necas wrote:
> > Lukas Zapletal  writes:
> > >> I'm not sure I follow what you mean by administrative tasks. Note that
> > >> reports
> > >> import and puppet envs import are core actiones that now run as a
> > >> foreman
> > >> task
> > >> (both synchronous and asynchronous variants). By making the UI part
> > >> optional
> > >> users would not be able to monitor their progress, cancel them etc if
> > >> they
> > >> don't install the plugin. What would be the benefit of such setup?
> > > 
> > > I am not telling not to ship it, but making it optional (but installed
> > > by
> > > default). Assuming that processes would work normally without the UI
> > > part.
> > > 
> > > Other option is to simply move the UI into core, I don't think we should
> > > make our decomposition effort a dogma. Let's be realistic.
> > > 
> > > Benefit? Solving the stalemate perhaps :-)
> > 
> > So the latest updates updates if you don't follow the packaging PR [1]
> > 
> > The goal right now is to:
> >   1. unblock the nightlies
> >   2. keep the async operations possible
> >   3. prefer proper way over hacks
> > 
> > Although the goal is to get the foreman-tasks functionality to the core,
> > I don't think we can effort blocking nightlies much longer. To preserve
> > the async possibility there.
> > 
> > I'm looking into leveraging ActiveJob interface to define the async
> > operations we added. The idea is: when there is no foreman-tasks, the
> > in-thread executor, that already is build into Rails, will be used, and
> > from the end user, it will behave as before.
> > 
> > However, when foreman-tasks will be around and configured to be used for
> > async processing, the operation will go though that.
> > 
> > Once this would be done, we could start adding the UI around async
> > operations directly to the core: so the foreman-tasks functionality
> > would be gradually moved to the core this way: once the core is given
> > certain functionality, it can be removed from the tasks.
> > 
> > The important thing here is we could work on enhancing tasking
> > infrastructure in core while still supporting the current foreman-tasks
> > users and delivering enhancements there in the meantime.
> > 
> > I'm setting the deadline for this on Monday EOB. If by that time turns
> > our this plan is not feasible, we would need to sacrifice goal 1., 2. or
> > 3.
> 
> To me this sounds like a good plan.

+1

If active job does not work we could also fallback to something like 
`if defined?(ForemanTask)` and keep working on active job alternative.

--
Marek


-- 
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] Opinions from plugin maintainers wanted: permissions and roles

[Marek Hulán]

On úterý 17. ledna 2017 14:45:53 CET Ondrej Prazak wrote:
> On Tue, Jan 17, 2017 at 12:08 PM, Tomas Strachota 
> 
> wrote:
> > On Mon, Jan 16, 2017 at 6:55 PM, oprazak  wrote:
> > > Hi,
> > > I recently started identifying problematic areas in Permissions and
> > 
> > Roles,
> > 
> > > especially with regard to plugins. Foreman provides 'Viewer' and
> > 
> > 'Manager'
> > 
> > > roles out of the box and users expect these roles to work for plugins as
> > > well. But plugins generally do not add their permissions to core's
> > > roles,
> > > some of them just have their own plugin-specific roles, some not. So if
> > > a
> > > plugin is installed, user has to go and find what role/permission is
> > 
> > missing
> > 
> > > or ask someone who can grant permissions.
> > > 
> > > After a brief discussion in team C, it was decided that plugins should
> > 
> > add
> > 
> > > their permissions to 'Manager' role and their 'view_' permissions to
> > > 'Viewer' role. They should also keep their plugin-specific roles (or
> > 
> > create
> > 
> > > them) for higher granularity and backward compatibility.
> > > I started initial work which should allow plugin maintainers to do this,
> > 
> > it
> > 
> > > can be found at [1]. I decided to create 2 methods that would be called
> > 
> > from
> > 
> > > Engine, but we could take a different approach and add permissions from
> > > plugins automatically by modifying the 'permission' method that is
> > > called
> > > from 'security_block'.
> > > 
> > > The way I see things:
> > > 
> > > * adding permissions explicitly, using DSL
> > > 
> > >   - extra work for plugin maintainers
> > >   - permissions can be ommited/forgotten
> > >   
> > >  # can be covered with tests? something like the already existing
> > > 
> > > AccessPermissionsTest
> > > 
> > >   - extra code in Engine
> > >   - better control, can handle special cases
> > > 
> > > * adding permissions automatically without plugin knowing about it by
> > > modifying 'permission' method
> > > 
> > >   - no need for plugin maintainers to do anything
> > >   - cannot handle special cases
> > >   - if user removes permission from these default roles, there is no way
> > 
> > to
> > 
> > > detect it and permissions get added again on server restart
> > 
> > I'm afraid this could be quite frustrating if you try to modify your
> > roles. I'm not entirely sure what part of permissions is stored in the
> > db and what is in the code, but would it be possible to add
> > permissions during seed and don't touch it on server start?
> 
>All permissions are in db and plugins get loaded before migration runs,
> so it should be possible I think. Seems much better (and less frustrating
> for users) than resetting to initial state on each restart,
>   the downside is you will need a migration each time you introduce new
> permissions.

Or use the flag the same way as you describe below so it would happen only 
once, basically when you install the plugin?

> 
> > > # users do not modify default roles, they can clone it and modify
> > > the
> > > 
> > > cloned one
> > > 
> > > # if the default roles are not meant to be modified, they should be
> > > 
> > > 'frozen' and user should not be able to modify them, implementing this
> > 
> > would
> > 
> > > add code and complexity
> > 
> > Even though it's more work for plugin maintainers I prefer option A
> > because it gives you more control over what gets added.
> > 
> > BTW how would both approaches behave on migration of existing
> > installations? Would it add the permissions too?
> 
>   Yes, both would add the permissions, forgot to mention that they are
> added on each restart for the case A as well :-(
>   Maybe we could add some sort of 'dirty' flag on the role, as in: when
> modified by user, do not touch this role. But then it would not add
> permissions when plugins were installed after role was modified. Tricky.

The flag would have to be on the permission - role association I guess and it 
would have to persist even after it's removal. For other resources in seeds we 
abuse audits for this, if audit exists, we don't touch the resource.

> 
> > > Anything that I have missed? Where do you stand as a plugin maintainers?
> > 
> > Can
> > 
> > > you think of other ways to go?
> > > 
> > > Ondra
> > > 
> > > [1] https://github.com/theforeman/foreman/pull/4168
> > > 
> > > --
> > > 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 

Re: [foreman-dev] Opinions from plugin maintainers wanted: permissions and roles

[Marek Hulán]

On úterý 17. ledna 2017 15:46:56 CET Lukas Zapletal wrote:
> On Mon, Jan 16, 2017 at 6:55 PM, oprazak  wrote:
> > So if a plugin is installed, user has to go and find what role/permission
> > is missing or ask someone who can grant permissions.
> 
> I do not think the proposed approach is the best, here is my lengthy
> explanation:
> 
> https://github.com/theforeman/foreman/pull/4168#issuecomment-273187422

Let's continue the discussion here since it might read more people. I think 
that as a user I don't care that my installation consists of core and several 
plugins and I want to have Viewer role that gathers all view permission for 
the whole app.

This does not in conflict with also providing "$plugin Viewer" and "$plugin 
Manager" roles so if user wants to create a user group from subset of 
permission he can still do it.

If you want to keep current Viewer and Manager roles to contain only core 
permissions then I'd suggest renaming them to Core Viewer and Core Manager

--
Marek

-- 
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] New community-templates structure

[Marek Hulán]

On čtvrtek 8. prosince 2016 16:58:24 CET Greg Sutcliffe wrote:
> Oh, another thought, possibly half-baked - is there any impact on backwards
> compatibility? IIRC foreman_templates doesn't actually care about the
> directory structure (it's a **/*erb glob) but perhaps I've overlooked
> something?

Sorry for late answer, the new structure should work with foreman_templates 
just fine. Foreman core has a list of files it seeds, I'm happy to provide a 
PR for it with new paths [1] if we change the structure in core too but we 
could start seeding all we have there since we'd have metadata for each 
template.

[1] 
https://github.com/theforeman/foreman/blob/develop/db/seeds.d/07-provisioning_templates.rb#L21

--
Marek

-- 
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] Revert removal of @host.params for host_param

[Marek Hulán]

Hello

The discussion has diverged into something different. People agree we should 
add an extra layer but implemented through proxy objects. It's also clear no 
one starts actively working on this right now. At the same time I want to add 
new macro, let's say rpm_distro? which returns true/false based on 
@host.operatingsystem, how do I do it?

So far the answer was to add a new macro. Now with the proxy object, should I 
define it in host so one would use @host.rpm_distro?. Honestly I don't want to 
add more stuff into Host object, not even through concerns. So should I wait 
until we have a proxy layer? That means I can't add any improvements. For me 
the best answer is add new macro called "rpm_distro?". This will result in two 
approaches in future, we'll have both @host.param and rpm_distro?

I think the best approach is just reverting the deprecation warning and add a 
value to host_param macro. It can check that user is asking for a parameter 
that does not exist and raise a exception of a specific class so rendering 
could display nicer error message such as "You tried to use parameter with 
name abc but it's not defined for host xyz" instead of "Undefined method 
upcase on nil". We could extend Host#param for this too but it's not right, 
this exception is specific for template rendering, other internal usage of 
this method might rely on fact it returns nil.

My probably last comment in this thread - the PR was opened Nov 1st 2016, 
deprecation was suggested Nov 2nd, merged Jan 3rd 2017 [1]. I know a lot of 
devs were offline during December but still, please try to raise you concerns 
in PRs rather than revert stuff.

[1] https://github.com/theforeman/foreman/pull/3983

--
Marek

On pondělí 16. ledna 2017 14:59:43 CET Tomer Brisker wrote:
> Hi,
> I think that while there are benefits to moving away from the host object,
> we have a de-facto API based on it.
> A way to change without breaking user's template would be to use a "proxy"
> object that maintains the same endpoints and allows adding functionality or
> handling changes in the underlying objects without breaking the way users
> use them.
> So the templates will still have a "@host" object with the same methods as
> before, except it will in fact be proxy object and not an active record.
> For example, we could have a nice error message if the actual host is nil.
> We could also leverage method_missing to easily handle passing anything not
> defined in the api to the host (possibly only if safe mode is off), so that
> any users relying on active record methods etc. won't have breakage.
> 
> Tomer
> 
> On Mon, Jan 16, 2017 at 2:49 PM, Stephen Benjamin 
> 
> wrote:
> > On Mon, Jan 16, 2017 at 3:24 AM, Ondrej Prazak  wrote:
> > > +1 for keeping the macros. IMHO, just because we did something a certain
> > 
> > way for a long time should not prevent us from changing it if there are
> > reasons for a change. This is also not the first change in core that
> > affected plugin(s) in a negative way and I doubt it will be the last.
> > Breaking plugin tests is unpleasant, but it is still a second best
> > scenario.
> > 
> > 
> > The plugin test failure is relatively minor, the main objection here
> > is the number of users who rely on this interface now need to change.
> > After raising this issue we got some PR's that help the migrations
> > which is nice, but there's
> > organizations who have less sophisticated technical users who learned
> > basic ERB who have to re-learn this, not to mention that git repos of
> > users using foreman_templates now have to update, and we now have lots
> > of incorrect info out there on the internet and internal intranets
> > that need to be updated.  We're making our users do a lot of work for
> > not a lot of good.
> > 
> > The change was not needed, and it was merged while a significant
> > number of developers were away for the holidays.  I think it should be
> > changed to restore the @host interface, or reverted. I know there are
> > some benefits to stop using the Host::Managed object, but we could've
> > implemented @host as an instance of some proxy class without breakage
> > for users.
> > 
> > FWIW, this change, if we actually followed semver, should require a
> > bump to 2.0 once the deprecated methods are removed.
> > 
> > - Stephen
> > 
> > --
> > 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] Community template repository labels

[Marek Hulán]

Hello,

labels might help so +1 for that. I plan to send a PR with new directory 
structure as discussed at [1] soon. It might help the bot to just check the 
directories of touched files.

[1] https://groups.google.com/forum/#!topic/foreman-dev/bzfBWEtIMpg

--
Marek

On pátek 13. ledna 2017 10:19:02 CET Eric D Helms wrote:
> If this will help with getting reviews or directing reviews then sounds all
> good. The bot could handle this afaik as long as they are predictable which
> is which.
> 
> On Jan 12, 2017 6:26 AM, "Ewoud Kohl van Wijngaarden" <
> 
> ew...@kohlvanwijngaarden.nl> wrote:
> > Hello all,
> > 
> > Since there are multiple types of templates in community templates, I
> > wonder if it's time to (automatically) attach labels to PRs. I was
> > thinking:
> > 
> > * Remote exection
> > * Provisioning
> > 
> > Maybe we need to split up Provisioning into a label per distro.
> > 
> > Any thoughts on this? Can the foreman bot be easily modified to do this
> > for us?
> > 
> > --
> > 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] Revert removal of @host.params for host_param

[Marek Hulán]

On čtvrtek 12. ledna 2017 9:32:06 CET Stephen Benjamin wrote:
> - Original Message -
> 
> > From: "Marek Hulán" <mhu...@redhat.com>
> > To: foreman-dev@googlegroups.com
> > Sent: Thursday, January 12, 2017 2:59:39 AM
> > Subject: Re: [foreman-dev] Revert removal of @host.params for host_param
> > 
> > On středa 11. ledna 2017 14:22:53 CET Stephen Benjamin wrote:
> > > - Original Message -
> > > 
> > > > From: "Daniel Lobato Garcia" <elobat...@gmail.com>
> > > > To: foreman-dev@googlegroups.com
> > > > Sent: Wednesday, January 11, 2017 11:05:39 AM
> > > > Subject: [foreman-dev] Revert removal of @host.params for host_param
> > > > 
> > > > Hi foreman devs,
> > > > 
> > > > Just noticed today
> > > > https://github.com/theforeman/foreman/pull/3983/files
> > > > after some comments on IRC. What's the background behind this change?
> > > > 
> > > > As far as I can see, this merely moves
> > > > 
> > > > @host.param to host_param
> > > > @host.param_true? to host_param_true?
> > > > @host.param_false? to host_param_false?
> > > > @host.info to host_enc
> > > > 
> > > > without gaining anything from the change. This will force people to
> > > > change their templates (including our community templates) when the
> > > > deprecation is removed, and there's nothing to gain.
> > > > 
> > > > Does someone know what's the rationale behind this change? As it
> > > > stands
> > > > right now, I propose reverting that commit entirely to avoid
> > > > inflicting
> > > > that pain on users - which include many devs who maintain templates.
> > > > 
> > > > Best,
> > > 
> > > I know the macros look better, but it seems like a small gain for a
> > > lot of pain.  A lot of users use the existing methods in parameter
> > > values
> > > (ERB w/ safe mode off), and their own custom templates.
> > > 
> > > And the standard response to these kinds of complaints is "well, it's
> > > deprecated and users have enough time to change."  But I really just
> > > don't think that's sufficient, this is more change for the sake of
> > > change.
> > > 
> > > Also, the deprecation wasn't really smooth as it broke REX tests.
> > > 
> > >   http://ci.theforeman.org/job/test_plugin_matrix/2466/
> > > 
> > > - Stephen
> > 
> > Hello
> > 
> > I strongly disagree that this does not have big benefits. Using internal
> > Foreman objects in templates is a bad practice. It blocks us from
> > improving
> > our code. Therefore it's very important to build a DSL that users can use
> > in templates and keep that compatible. We can then later change the
> > implementation of host_param_true method without any templates changing.
> > Think
> > of this as a templating API.
> > 
> > Another less significant benefit is that for plugins it's easier to
> > wrap/alias
> > the template method rather than manipulating something that's used
> > internally in @host. Still not ideal but that should be solved by
> > https://github.com/ theforeman/foreman/pull/3701
> > 
> > Of course it will require users to migrate to new template helpers which
> > is
> > why we move there slowly and hopefully with proper deprecations. I was
> > hoping to do the update for community-templates since it's very easy
> > migration.
> > 
> > If you think it's too complicated for users we could provide rake task or
> > migration. But please don't revert this.
> 
> Yes, if you provided a migration it would be much better.  That doesn't
> really solve the problem with people using the foreman_templates plugin
> who will have those changes reverted, but I guess it's better than nothing.
> 
> There's still dozens of other things allowed for @host in the Jail that
> aren't covered by these macros.   What's the plan for those?

Whenever we have a chance, we should move from internal objects to macros. The 
more macros we have the higher the chance is that we can keep templates 
compatible.

> I still think this provides more headaches than any benefits.

I hope that following helps
* https://github.com/theforeman/community-templates/pull/343
* https://github.com/theforeman/foreman/pull/4187
* https://gist.github.com/ares/5435226ef0317613535101765404d3f5

--
Marek

> 
> 
> - Stephen
> 
> > --
> > Marek
> > 
> > --
> > 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] Revert removal of @host.params for host_param

[Marek Hulán]

> Also, the deprecation wasn't really smooth as it broke REX tests.
>   http://ci.theforeman.org/job/test_plugin_matrix/2466/

One more note, REX was not broken by this, users were no affected. It's just 
the test that checks "no warning was reported". The test tests something more 
than it should. But in this case it's actually good that REX tests let us know 
that we should update REX code. We didn't have to and just fix the test, we 
didn't have to release new version with any fix either. It let us know early 
before the method was entirely disabled. I'm not sure what we could do better 
in this case.

--
Marek

-- 
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] Revert removal of @host.params for host_param

[Marek Hulán]

On středa 11. ledna 2017 14:22:53 CET Stephen Benjamin wrote:
> - Original Message -
> 
> > From: "Daniel Lobato Garcia" 
> > To: foreman-dev@googlegroups.com
> > Sent: Wednesday, January 11, 2017 11:05:39 AM
> > Subject: [foreman-dev] Revert removal of @host.params for host_param
> > 
> > Hi foreman devs,
> > 
> > Just noticed today https://github.com/theforeman/foreman/pull/3983/files
> > after some comments on IRC. What's the background behind this change?
> > 
> > As far as I can see, this merely moves
> > 
> > @host.param to host_param
> > @host.param_true? to host_param_true?
> > @host.param_false? to host_param_false?
> > @host.info to host_enc
> > 
> > without gaining anything from the change. This will force people to
> > change their templates (including our community templates) when the
> > deprecation is removed, and there's nothing to gain.
> > 
> > Does someone know what's the rationale behind this change? As it stands
> > right now, I propose reverting that commit entirely to avoid inflicting
> > that pain on users - which include many devs who maintain templates.
> > 
> > Best,
> 
> I know the macros look better, but it seems like a small gain for a
> lot of pain.  A lot of users use the existing methods in parameter values
> (ERB w/ safe mode off), and their own custom templates.
> 
> And the standard response to these kinds of complaints is "well, it's
> deprecated and users have enough time to change."  But I really just
> don't think that's sufficient, this is more change for the sake of
> change.
> 
> Also, the deprecation wasn't really smooth as it broke REX tests.
>   http://ci.theforeman.org/job/test_plugin_matrix/2466/
> 
> 
> - Stephen

Hello

I strongly disagree that this does not have big benefits. Using internal 
Foreman objects in templates is a bad practice. It blocks us from improving 
our code. Therefore it's very important to build a DSL that users can use in 
templates and keep that compatible. We can then later change the 
implementation of host_param_true method without any templates changing. Think 
of this as a templating API.

Another less significant benefit is that for plugins it's easier to wrap/alias 
the template method rather than manipulating something that's used internally 
in @host. Still not ideal but that should be solved by https://github.com/
theforeman/foreman/pull/3701

Of course it will require users to migrate to new template helpers which is 
why we move there slowly and hopefully with proper deprecations. I was hoping 
to do the update for community-templates since it's very easy migration.

If you think it's too complicated for users we could provide rake task or 
migration. But please don't revert this.

--
Marek

-- 
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] HoundCI - annoying?

[Marek Hulán]

Hello,

yes, I find it annoying and I liked the jenkins job more. It would be great if 
hound would be able to use reviews that would generate one email per review. 
Hopefully they work on it. Otherwise I'd be for moving back to jenkins.

On středa 11. ledna 2017 12:07:38 CET David Davis wrote:
> Not sure if it helps you but you can filter out the HoundCI emails by
> checking for emails from "Hound ”. Also, when a
> HoundCI comment is addressed, isn’t the comment collapsed?

Sometimes that's annoying as well, the the hound comments in collapsed thread.

--
Marek

> I agree though that HoundCI doesn’t seem to work properly. On Katello,
> we’ve seen it add inline comments but pass PRs, fail Pos without inline
> comments, and raise inline comments that we’re not seeing when running
> rubocop locally.
> 
> Another reason to move to Jenkins is that sometimes HoundCI doesn’t catch
> all the errors that actually rubocop might since it only looks at the lines
> changed. Like right now, it doesn’t look like rubocop is passing for
> foreman on develop.
> 
> 
> David
> 
> On Wed, Jan 11, 2017 at 11:18 AM, Timo Goebel  wrote:
> > Hi devs,
> > 
> > I'm usually not very easily annoyed. What get's me started though
> > eventually is when things don't work properly.
> > HoundCI is one of those things.
> > 
> > My main concern is, that I get an e-mail and/or Github notification for
> > every single comment. These can easily be ten or more e-mails. They're not
> > grouped as other reviews.
> > In addition, the inline comments are very distracting when reviewing a PR
> > imho. When the issues are fixed, I'd prefer for the comments to be
> > removed.
> > When reviewing a PR, I usually don't care about the style issues. I just
> > want to see if there are some problems or if all is fine.
> > 
> > Back in the days, code style was checked by Jenkins. I think, it did a far
> > better job in displaying style issues. With the current Jenkins Github
> > plugin it believe would be easily possible to show style issues as a
> > separate line along with all the other CI checks.
> > 
> > One argument in favor of HoundCI is, that it checks JavaScript style. But
> > I think, that can easily be set up in Jenkins as well by running eslint.
> > 
> > Any comments? How do others feel?
> > 
> > Timo
> > 
> > --
> > 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 foreman-tasks to the core: the plan

[Marek Hulán]

Few comments below

On čtvrtek 5. ledna 2017 15:25:47 CET Lukas Zapletal wrote:
> Is it only the Rails App that depends on Foreman Core? What's reasonable
> plan to me is:
> 
> a) Extract core part that does not depend on Foreman core into a simple gem
> (that's what you propose I guess) and make it a hard dependency of core.
> b) The rest of foreman-tasks (Rails App/Engine - administrative UI part for
> tasks) remains an *optional* plugin in a separate (plugin) repository.
> c) We include the plugin in the default installation set but Foreman should
> work without the plugin as well, it is only needed to perform
> administrative tasks.

I'm not sure I follow what you mean by administrative tasks. Note that reports 
import and puppet envs import are core actiones that now run as a foreman task 
(both synchronous and asynchronous variants). By making the UI part optional 
users would not be able to monitor their progress, cancel them etc if they 
don't install the plugin. What would be the benefit of such setup?

> If that's what you propose, why do we need temporary workarounds? Can't we
> just do it right away? The timing is good, 1.14 is getting out soon, we can
> start digging.

Moving the code into core code base might take time until it's reviewed and 
merged. The workaround would get nightly builds back before the code is moved.

--
Marek

> On Wed, Jan 4, 2017 at 10:29 AM, Ivan Necas  wrote:
> > Hello friends,
> > 
> > You've might noticed we started using foreman-tasks inside the
> > foreman-core since [1] was merged. Unfortunately, we hit issues in the
> > packaging phase and the proposed workarounds were not accepted ([2]
> > [3]).
> > 
> > Based on various discussions, as well as on the fact that
> > foreman-tasks is already part of infrastructure for pretty wide amount
> > of plugins (Katello, Remote Execution, Chef, Salt, Ansible, Docker…),
> > it seems moving foreman-tasks code-base into the core as part of the
> > Foreman is where people want to get us moving.
> > 
> > Therefore, let me start proposing the plan for moving this subject
> > forward.
> > 
> > The plan would be:
> > 
> > 1. get the the foreman-tasks-core, that is part of the tasks code
> > being use both in foreman server and smart-proxy code into separate
> > repository
> > 2. get the foreman-tasks on the same set of rubocop rules the foreman
> > code uses
> > 3. fill unit test gaps
> > 4. open PR to foreman with the foreman-tasks functionality
> > 5. open PR to get the hammer-cli-foreman-tasks inside hammer-cli-foreman
> > 
> > The target version for this would be foreman 1.15.
> > 
> > In the mean time, I would like to kindly ask for trying to
> > find an acceptable workaround in [2] and [3] until this is done.
> > 
> > Also, since this will be pretty large change already, I would like to
> > avoid radical changes done as part of the PR: as already said,
> > foreman-tasks has already quite significant user base though various
> > plugins that we need to support and I would rather prefer keeping
> > those as additional issues to track and address based on priorities,
> > as well as going though proper deprecation cycle if we need to
> > deprecate something.
> > 
> > Opinions, comments, questions, concerns (and remember, :+1: is also a
> > valid response:)
> > 
> > [1] - https://github.com/theforeman/foreman/pull/3670
> > [2] - https://github.com/theforeman/foreman-packaging/pull/1436
> > [3] - https://github.com/theforeman/foreman-packaging/pull/1437
> > 
> > -- 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] Moving foreman-tasks to the core: the plan

[Marek Hulán]

+1

--
Marek

On středa 4. ledna 2017 10:29:19 CET Ivan Necas wrote:
> Hello friends,
> 
> You've might noticed we started using foreman-tasks inside the
> foreman-core since [1] was merged. Unfortunately, we hit issues in the
> packaging phase and the proposed workarounds were not accepted ([2]
> [3]).
> 
> Based on various discussions, as well as on the fact that
> foreman-tasks is already part of infrastructure for pretty wide amount
> of plugins (Katello, Remote Execution, Chef, Salt, Ansible, Docker…),
> it seems moving foreman-tasks code-base into the core as part of the
> Foreman is where people want to get us moving.
> 
> Therefore, let me start proposing the plan for moving this subject forward.
> 
> The plan would be:
> 
> 1. get the the foreman-tasks-core, that is part of the tasks code
> being use both in foreman server and smart-proxy code into separate
> repository
> 2. get the foreman-tasks on the same set of rubocop rules the foreman
> code uses
> 3. fill unit test gaps
> 4. open PR to foreman with the foreman-tasks functionality
> 5. open PR to get the hammer-cli-foreman-tasks inside hammer-cli-foreman
> 
> The target version for this would be foreman 1.15.
> 
> In the mean time, I would like to kindly ask for trying to
> find an acceptable workaround in [2] and [3] until this is done.
> 
> Also, since this will be pretty large change already, I would like to
> avoid radical changes done as part of the PR: as already said,
> foreman-tasks has already quite significant user base though various
> plugins that we need to support and I would rather prefer keeping
> those as additional issues to track and address based on priorities,
> as well as going though proper deprecation cycle if we need to
> deprecate something.
> 
> Opinions, comments, questions, concerns (and remember, :+1: is also a
> valid response:)
> 
> [1] - https://github.com/theforeman/foreman/pull/3670
> [2] - https://github.com/theforeman/foreman-packaging/pull/1436
> [3] - https://github.com/theforeman/foreman-packaging/pull/1437
> 
> -- 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.

Re: [foreman-dev] Example of how to extend the hostgroups action menu

[Marek Hulán]

On středa 21. prosince 2016 13:37:12 CET Daniel Kuffner wrote:
> Hi All,
> 
> Do we have somewhere an example of how to extend the hostgroups action menu
> item via foreman plugin? Is that possible?
> 
> thank you,
> Daniel

Hello,

I can't find any example for extending menu actions, but it should be possible 
using deface. See notes in [1] our wiki. It should not differ too much from 
other overrides that can be found in plugins like remote execution [2] or 
openscap [3].

[1] http://projects.theforeman.org/projects/foreman/wiki/
How_to_Create_a_Plugin#Modify-Existing-Foreman-View-using-Deface
[2] https://github.com/theforeman/foreman_remote_execution/tree/master/app/
overrides
[3] https://github.com/theforeman/foreman_openscap/tree/master/app/overrides

Hope this helps

--
Marek


-- 
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] Simple Example for foreman-tasks locks

[Marek Hulán]

On pátek 16. prosince 2016 16:28:47 CET Daniel Kuffner wrote:
> Hi All,
> 
> I was looking for a simple example of how to use locks of foreman-tasks
> (dynflow). I can see that Actions::EntryAction mixes in the
> Actions::Helpers::Lock but for me it is not clear how to use it.
> 
> regards,
> Daniel

Hello,

there are two types of locks - exclusive (blocking other tasks to lock the 
same resource) and non-exclusive also called links. To automatically create 
link to some object, you only define related_resource method in your task

   def related_resources
 [ ::Host.first ]
   end

As you can see, it should return array of linked objects, first host in this 
case.

To create a lock you need to first defined what locks are available for a 
given task, e.g.

   # names of locks that can be locked
   def available_locks
 [ :read, :write ]
   end

When the task has this defined you can lock resources in planning like this

   # locking only in plan phase
   def plan(params)
 lock!(::FactValue.first, :read)
 # exclusive_lock!(::Host.last) # locks all available locks on a given 
resource
 link!(::FactValue.last) # this would add link lock
 plan_self :params => params
   end
   # exclusive_lock! and lock! creates the same kind of lock, 
exclusive_lock! just locks all available locks

I'm in the middle of writing the manual for the foreman-tasks plugin. When I 
finish user guide, I'll send a PR so others can contribute. I also plan to put 
together developer guide which would cover this.

Hope this helps

--
Marek

-- 
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] Use mention-bot to increase reviews?

[Marek Hulán]

On úterý 6. prosince 2016 12:37:23 CET Daniel Lobato Garcia wrote:
> On 12/06, Sean O'Keeffe wrote:
> > Hows this going for everybody? I personally quite like it
> 
> Personally it's just noise for me, but if it works for some people it
> causes no harm

+1, I'm failing to get time for reviews and this does not help me, but I'm ok 
with it pinging me if it helps others.

--
Marek

> 
> > On Fri, Oct 28, 2016 at 12:36 PM, Greg Sutcliffe
> > 
> > 
> > wrote:
> > > On 27 October 2016 at 14:55, Ohad Levy  wrote:
> > >> On Mon, Oct 17, 2016 at 4:02 PM, Greg Sutcliffe
> > >>  > >> 
> > >> > wrote:
> > >>> On 13 October 2016 at 13:28, Eric D Helms  
wrote:
> >  This has been turned on for the Katello repo, if devs find it needs
> >  tweaking there is a configuration file that can be added (
> >  https://github.com/facebook/mention-bot#configuration).
> > >>> 
> > >>> How's that going for you?
> > >>> 
> > >>> Dominic or Ohad, could you turn it on for the other repos mentioned,
> > >>> as
> > >>> a trial? Thanks!
> > >> 
> > >> Done.
> > > 
> > > Thanks. It's already pinged me for a review, so that was cool.
> > > 
> > > Lets see how it goes for a few weeks and we can see if we want to expand
> > > to other repos. Feedback welcome as we go :)
> > > 
> > > 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.
> > 
> > --
> > 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.
> 
> --
> Daniel Lobato Garcia
> 
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
> 
> GPG: http://keys.gnupg.net/pks/lookup?op=get=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.

Re: [foreman-dev] Way to create new foreman user using rake ?

[Marek Hulán]

Hello

I don't think so, but you can easily create admin using API or hammer CLI.

Hope this helps
--
Marek

On čtvrtek 1. prosince 2016 2:42:03 CET myrubycodecco...@gmail.com wrote:
> Hi all,
> 
> As we can rake permissions:reset etc, is there a way to create another
> admin user via rake also?
> 
> Thanks.


-- 
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] Using certificates for SSH access

[Marek Hulán]

Hello

some comments below

On Tuesday 13 of September 2016 08:51:12 Ohad Levy wrote:
> Hi,
> 
> I was looking at [1] which talks about how to leverage a CA for managing
> SSH access, and I thought it could be interesting for REX and potentially
> for foreman to manage.
> 
> In the post, they describe how they create different principles (groups -
> think hostgroups) for access, generating certificates with expatriation etc.
> 
> Since we already have some of the certificate handling code (puppet ca,
> pulp / katello certs) I wonder if it make sense to generalize it and offer
> SSH certificates (and their management and possible an auditing system for
> their usage) offering?

I was thinking about this earlier, the major benefit I see is that in case we 
change the key that Foreman uses we wouldn't have to update all hosts. Since 
we currently only install it during provisioning it might be very helpful. 
OTOH we should also provide puppet module that would configure this key so 
there's easy way to update it also for unmanaged hosts. Then the CA might not 
have that many benefits, we'd have to distribute the CA pub key instead of the 
main pub key. Probably the biggest benefit would be the key expiration.

If we decide to generalize the CA handling I'd first look if we could use 
something existing, e.g. FreeIPA. Maybe we could provide our simple backend 
too but I'd like to avoid building our own CA on top ssh-keygen :-) I'd also 
like to keep it in separate plugin - probably rex.

--
Marek

> 
> Ohad
> 
> [1]
> https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-w
> ith-ssh/

-- 
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] Hash rocket syntax

[Marek Hulán]

Few more comments below

> What do you mean by "Foreman dev"? 

You, me, everyone who contributed to Foreman.

> I’ve contributed to both foreman and
> rubocop several times. Having worked on rubocop with all its cops enabled
> hasn’t been a deterrent to me even though I don’t necessarily agree with
> all cops.

Seems rubocop devs are happy with more cops than at least one foreman dev is 
(me). That make sense, otherwise they would not contribute to rubocop I guess 
:-)

> I’m not disagreeing with you. But I still have nightmares about the dynflow
> source code which had no rubocop checking at all and featured a number of
> obscure ruby syntaxes that rubocop would have forbid.

If dynflow was foreman core project and was reviewed in that way from the first 
commit, this would not happen. Rubocop would not help too much. I tried to run 
rubocop on dynflow. From 1346 offenses I found only 22 regarding the obscure 
syntax, rest is "redundant return", "1.9 hash syntax", "top level class 
documentation missing" stuff. If you want to reproduce, see [1].

This thread started around has rocket syntax. So to remain on topic, I don't 
think that the fact there is a cop for enforcing one hash syntax, it's widely 
accepted among Ruby devs. Speaking of hash rockets, an example might be github 
style guide - https://github.com/styleguide/ruby/hashes

[1] https://gist.github.com/ares/ff6e8b19361148e2be17290f1167c7c4

--
Marek

> I think there’s probably a happy medium between not using rubocop and
> enabling all rubocop cops.
> 
> 
> David
> 
> On Tue, Aug 23, 2016 at 11:22 AM, Marek Hulán <mhu...@redhat.com> wrote:
> > On Tuesday 23 of August 2016 07:47:31 David Davis wrote:
> > > The plugins may not have as many contributors as foreman core but
> > > rubocop
> > > has more contributors (279 vs 200 for foreman) and they have pretty much
> > > all cops enabled. It’s only been around for 3 years (vs 7 years for
> > > foreman) so it doesn’t seem to be a deterrent to community
> > > contributions.
> > 
> > I don't think this is fair comparison. Do you think that 279 contributors
> > of
> > one project represent all Ruby devs or all Foreman devs? At least not one
> > Foreman dev, that's for sure. I don't say we should disable rubocop but I
> > don't think all devs are happy with all cops. Adding cops like hash rocket
> > makes it only worse.
> > 
> > --
> > Marek
> > 
> > > I’d probably wager that most experienced Ruby developers are aware of
> > > rubocop and the ruby community style guide [1]. For unexperienced Ruby
> > > developers, I think they are a great way to learn good Ruby coding
> > > standards.
> > > 
> > > That said, I agree it would be nice to get opinions of community members
> > > who contribute to foreman and their experiences with rubocop.
> > > 
> > > [1] https://github.com/bbatsov/ruby-style-guide
> > > 
> > > 
> > > David
> > > 
> > > On Tue, Aug 23, 2016 at 3:48 AM, Marek Hulán <mhu...@redhat.com> wrote:
> > > > I'm with Lukas, we already enforce too many things without clear
> > 
> > benefit.
> > 
> > > > Let's
> > > > keep both ways accepted which is default for all rubyists.
> > > > 
> > > > > > I think we implemented Rubocop far beyond what's reasonable point.
> > 
> > It
> > 
> > > > > > make sense for dangerous constructs, but not in this case (and few
> > > > > > others).
> > > > 
> > > > +1, since rubocop leads to bike-shedding and annoyed devs from both
> > 
> > sides
> > 
> > > > I
> > > > don't think it's a good idea to introduce more cops.
> > > > 
> > > > > I'd argue the opposite, in foreman_docker or foreman_ansible I think
> > > > > rubocop (with *all* cops enabled) helped maintain good coding
> > 
> > standards
> > 
> > > > > immensely and making the project *much easier* to read and get used
> > 
> > to.
> > 
> > > > With all respect, these plugins do not have as many contributors as
> > > > Foreman
> > > > and I'd like to hear from these contributors whether rubocop helped or
> > > > annoyed
> > > > them. I don't think that all cops enabled == good coding standards.
> > 
> > And it
> > 
> > > > does not imply good readability, that's on reviewer. TBH I think it's
> > 
> > also
> > 
> > > > pretty subjective (remember explicit return 

Re: [foreman-dev] Hash rocket syntax

[Marek Hulán]

On Tuesday 23 of August 2016 07:47:31 David Davis wrote:
> The plugins may not have as many contributors as foreman core but rubocop
> has more contributors (279 vs 200 for foreman) and they have pretty much
> all cops enabled. It’s only been around for 3 years (vs 7 years for
> foreman) so it doesn’t seem to be a deterrent to community contributions.

I don't think this is fair comparison. Do you think that 279 contributors of 
one project represent all Ruby devs or all Foreman devs? At least not one 
Foreman dev, that's for sure. I don't say we should disable rubocop but I 
don't think all devs are happy with all cops. Adding cops like hash rocket 
makes it only worse.

--
Marek

> 
> I’d probably wager that most experienced Ruby developers are aware of
> rubocop and the ruby community style guide [1]. For unexperienced Ruby
> developers, I think they are a great way to learn good Ruby coding
> standards.
> 
> That said, I agree it would be nice to get opinions of community members
> who contribute to foreman and their experiences with rubocop.
> 
> [1] https://github.com/bbatsov/ruby-style-guide
> 
> 
> David
> 
> On Tue, Aug 23, 2016 at 3:48 AM, Marek Hulán <mhu...@redhat.com> wrote:
> > I'm with Lukas, we already enforce too many things without clear benefit.
> > Let's
> > keep both ways accepted which is default for all rubyists.
> > 
> > > > I think we implemented Rubocop far beyond what's reasonable point. It
> > > > make sense for dangerous constructs, but not in this case (and few
> > > > others).
> > 
> > +1, since rubocop leads to bike-shedding and annoyed devs from both sides
> > I
> > don't think it's a good idea to introduce more cops.
> > 
> > > I'd argue the opposite, in foreman_docker or foreman_ansible I think
> > > rubocop (with *all* cops enabled) helped maintain good coding standards
> > > immensely and making the project *much easier* to read and get used to.
> > 
> > With all respect, these plugins do not have as many contributors as
> > Foreman
> > and I'd like to hear from these contributors whether rubocop helped or
> > annoyed
> > them. I don't think that all cops enabled == good coding standards. And it
> > does not imply good readability, that's on reviewer. TBH I think it's also
> > pretty subjective (remember explicit return cop discussion).
> > 
> > --
> > Marek
> > 
> > On Friday 19 of August 2016 11:54:23 Daniel Lobato Garcia wrote:
> > > On 08/19, Lukas Zapletal wrote:
> > > > > As discussed on IRC yesterday there should be consistency and there
> > 
> > is
> > 
> > > > > an
> > > > > option to autofix with rubocop if the style is changed to change
> > > > > existing
> > > > > code with less effort.
> > > > 
> > > > TL;DR - Let's keep Rubocop away from rockethash thing.
> > > > 
> > > > What the consistency gives us? We all know there are two ways and both
> > > > will work. Let's avoid big bangs that will make cherry picking harder
> > > > and just let's slowly improve as the time goes on.
> > > 
> > > Not sure what cherry-picking becomes harder after this change? It's just
> > > that people might have to rebase their PRs? That's a small price to pay
> > > considering code is read 1000x more often than written.
> > > 
> > > > I see no point in changing a single line of code from old to new
> > > > syntax
> > > > just for that. We should only change it when changing logic.
> > > > 
> > > > Even if Rubocop is able to check only for changed lines, I won't like
> > > > that at all. I do not want to switch my brain between Smart Proxy and
> > > > Foreman Core codebases. Both ways should work and be accepted. Let's
> > > > only make the old syntax preferable when reviewing and that's it.
> > > 
> > > Precisely that's the painpoint, reviewers shouldn't have to pay
> > > attention to that. One of the points for having style guidelines is that
> > > the code looks and reads as if it had been written by one person.
> > > 
> > > Think of it from the POV of the ocassional contributor who is just
> > > confused about which syntax to use because the code mixes them both for
> > > no reason.
> > > 
> > > > I think we implemented Rubocop far beyond what's reasonable point. It
> > > > make sense for dangerous constructs, but not in this case (and few
> > > > others).
> > > 
> > &

Re: [foreman-dev] Possible Feature Requst: Discussion: EC2 Subnet Display - include comment/description field in seperate view

[Marek Hulán]

On Tuesday 09 of August 2016 08:22:38 Matt Darcy wrote:
> I've been doing a little bit of POC work on foreman 1.11 with EC2 (not
> bothered moving to 1.12 for this POC as it's not really version specific).
> 
> when building/modifying a host the EC2 compute plugin pulls a list of
> subnets assigned to the account/compute resource associated to the foreman
> compute resource target. this is nice and simple to use, however some
> recent experience of what is in essence quite a small AWS estate, 6 VPCs,
> at 9 subnets each, this become quite scappy as the list of 54 IP subnets,
> totally out of any order was presented to the support team and without any
> meaningful information about the subnets removed some of the ease and
> management selling points that using foreman for the project been built on.
> 
> In the POC I started looking at the ability to pull not only the IP CIDR
> blocks but the comment field associated with the CIDR blocks.
> 
> My initial tests look like it's possible to get the info, and I'd imagine
> it's not too hard to create a second display box next to the IP list to
> list the comments, or include a second field in the single box, but I'm
> nowhere near that yet
> 
> I thought I'd open up a short discussion (hopefully) about this as a
> feature request and see if there is anything I've not considered
> implication wise or anything I'd not seen the bigger picture on before
> raising the feature request and looking to work on it and gather some
> people to work on it.
> 
> I'm currently looking at foreman for a much bigger EC2 deployment, which
> will have many more subnets and without something human readable it will be
> a much harder sell to use going forward.
> 
> thoughts ?
> 
> Matt

Hello

that sounds as a good addition to me. I'd prefer combining into a single 
select box, the second one would be hard to get in sync. I can imagine the 
comment being too long so some trimming might be considered.

--
Marek

-- 
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] No uploader

[Marek Hulán]

Ok, so there's an error in the client.rb, the underscore is missing in 
foreman_server_options (see below)

On Wednesday 03 of August 2016 01:23:57 Thomas Fee wrote:
> On the target (Chef) node, I ran "gem install chef_handler_foreman", then
> edited /etc/chef/client.rb.
> 
> Not have any additional information, I just made that file look like the
> documentation you linked to.
> 
> log_location STDOUT
> chef_server_url  "https://172.17.8.101:443;
> validation_client_name "chef-validator"
> # Using default node name (fqdn)
> 
> require 'chef_handler_foreman'
> foreman_server options :url => 'http://oz.local/foreman:8443'
 ^ here's the underscore missing
this actually causes the handler is not being created

--
Marek

> foreman_facts_upload true
> foreman_facts_whitelist ['lsb','network','cpu']
> foreman_facts_blacklist ['kernel','counters','interfaces::sit0']
> foreman_cache_file '/var/cache/chef_foreman_cache.md5'
> foreman_reports_upload true
> reports_log_level "notice"
> 
> On Wednesday, August 3, 2016 at 1:05:36 AM UTC-7, Marek Hulán wrote:
> > Hello,
> > 
> > how did you install the handler? You have to modify /etc/chef/client.rb to
> > register it. See [1] for example how to do it
> > 
> > [1] https://github.com/theforeman/chef-handler-foreman#installation
> > 
> > On Tuesday 02 of August 2016 11:46:40 Thomas Fee wrote:
> > > Trying to get chef-handler-foreman to work. At the end of a Chef
> > 
> > converge,
> > 
> > > it says
> > > 
> > > "ERROR: No uploader registered for foreman reporting, skipping facts
> > 
> > upload"
> > 
> > > "ERROR: No uploader registered for foreman reporting, skipping report
> > > upload"
> > > 
> > > So the question is, how does one get and register an uploader?

-- 
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] List moderation "always allow posts" errors

[Marek Hulán]

On Thursday 04 of August 2016 13:33:32 Dominic Cleal wrote:
> Are any other list moderators (of either -dev or -users) getting the
> following errors when allowing the current plus future posts from a user?
> 
> "One message has been posted. Failed to always allow posts from
> u...@example.com due to errors."
> 
> This seems to be occurring every time for me and is increasing the
> amount of moderated messages significantly. If it's affecting others
> then I'll try getting some help from Google Groups.

I haven't seen it even though I saw today two messages from the same user I 
allowed for future posts for sure.

--
Marek

-- 
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] No uploader

[Marek Hulán]

Hello,

how did you install the handler? You have to modify /etc/chef/client.rb to 
register it. See [1] for example how to do it 

[1] https://github.com/theforeman/chef-handler-foreman#installation


On Tuesday 02 of August 2016 11:46:40 Thomas Fee wrote:
> Trying to get chef-handler-foreman to work. At the end of a Chef converge,
> it says
> 
> "ERROR: No uploader registered for foreman reporting, skipping facts upload"
> "ERROR: No uploader registered for foreman reporting, skipping report
> upload"
> 
> So the question is, how does one get and register an uploader?

-- 
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] Plugin Proposal: User-defined ENC mutation

[Marek Hulán]

Hello

thanks for the write up. first of all - I find it useful. Not only for users 
but 
for plugin developers too. I encountered this scenario several times already, 
I'd like to extend ENC from plugin. For example in foreman_openscap we provide 
puppet module to configure scap client and we need to add the manifest to all 
hosts on which certain policy should be applied. In other words we need to add 
class and parameters for it into the ENC output. We would find the same thing 
useful in remote execution to configure ssh keys.

So I wonder if we should add some helpers to Foreman core that would allow 
register "mutators" and your plugin could use it and just add the UI that 
allows adding rules that would add mutators. Or other plugins might depend on 
your plugin to use mutators. I lean towards that we provide such mechanism in 
core, so PRs against core would be welcome (from me at least).

It might be worth of suggesting through our RFC repo - 
https://github.com/theforeman/rfcs see PRs for examples

Anyway let me know if I can help somehow with your effort.

--
Marek

On Monday 01 of August 2016 10:36:11 Jon McKenzie wrote:
> Quite a while ago I posted a thread
>  %22|sort:relevance/foreman-users/8BMaCeDXsM4/dVv5XSPqR7kJ> to the Foreman
> Users group asking about the concept of "smart classes", i.e. the ability
> to dynamically assign Puppet classes (similar to smart class parameters)
> depending on fact or other data. I didn't get any responses, and
> ultimately, our team ended up doing something
> straightforward and created hostgroups for each permutation of Puppet
> classes that we had in our environment (rather than sink development time
> into solving the problem in a different way). Predictably, this has become
> somewhat annoying to maintain as our environment has grown.
> 
> I started thinking more about this recently, and came up with what I think
> might be a workable solution to this type of requirement. Let me know what
> you think.
> 
> The basic problem is that Foreman's model for categorizing hosts is a
> little bit too rigid to handle certain use cases. For my environment, there
> are two basic issues: assigning a class based on fact or parameter data,
> and removing inherited classes based on the same. I could imagine other
> scenarios as well, however, for example retrieving a class parameter value
> from an external system (rather than storing it statically within Foreman).
> 
> For users who can't accomplish their host classification with the builtin
> tools, there would be a "safety valve" of sorts -- a Foreman administrator
> could define little bits of code that mutate the Foreman-generated ENC data
> arbitrarily (sort of like ENC middleware), based on fact or other data
> about the host. This would work in the following way:
> 
> The admin would define ENC "mutators" in a configuration directory, e.g.
> /etc/foreman/mutators.d. There would be a standard API for these mutators
> that might look something like this:
> 
> Mutator.create(:some_mutator_name) do |enc, facts|
>   if facts[:ipaddress] =~ /^10\./ and !enc[:classes].has_key?('some::class')
> enc[:classes]['some::class'] = nil
>   end
>   enc
> end
> 
> (where `facts' is a hash of the requesting host's facts and `enc' is the
> standard ENC data returned by Foreman's node classifier)
> 
> When the Foreman server boots, it would load these mutators out of the
> config dir. When a Puppet server requests ENC data for a host, Foreman
> would retrieve the ENC data as normal, and then run the mutators against
> that data in some configurable order. Each mutator would return the mutated
> ENC, and this would be passed on to the next mutator in the chain. At the
> end of the chain, the final ENC data would be passed back to the Puppet
> server to use for catalog compilation. (Optionally, a system could be
> established to allow the web UI user to pick and choose which host,
> hostgroup, etc. gets which mutator and what order the mutators should run,
> but this would take a little bit more effort to implement). Ideally, the
> ENC data would be exposed in the web UI along each part of the chain so
> that operators can inspect and validate its correctness -- at the very
> least, a 'before' and 'after' image could be displayed.
> 
> Before I start building something, I'd like to get some thoughts on this
> idea. Would other people find this useful? Are there other approaches
> people have tried and found successful?

-- 
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] Deprecate EL6?

[Marek Hulán]

On Thursday 28 of July 2016 16:34:30 Greg Sutcliffe wrote:
> So I had a read back through the thread, and drew a few conclusions. The
> history seems to be:
> 
> * The thread was opened ~10 weeks ago, and went quiet ~6 weeks ago
> * At that time, there were 5 upvotes (Dominic, Daniel, Ewoud, Michael,
> Duncan), 1 downvote (BK), and 1 unsure (Ohad, who said he had "mixed
> feelings). Others commented but did not express a preference.
> * We then jump forward to a few days ago, with all the discussion that's
> happened since.
> 
> It's hard to deny that it looked OK to go ahead with, as of 3 days ago;
> 5-to-1 is something we wouldn't normally challenge, and 6 weeks is plenty
> of time to speak up about concerns.
> 
> However, I do take issue with comparing it to the previous OS deprecations,
> which by-and-large have been Debian/Ubuntu deprecations. These (a) don't
> impact as large a part of the community, (b) have a shorter shelf-life than
> EL (implying users are more comfortable with upgrading), and (c) have a
> simpler packaging structure. They're also unlikely to be using any of the
> RPM-centric plugins we offer, which (of course) will be more affected by
> dropping EL6 (bear in mind that according to the 2016 survey, some 30% of
> our community use Katello - that's not insignificant). As such, while I
> agree no fallout occurred in the past, I think we do have to be more
> careful this time.
> 
> More than anything, I think it's the sudden switch from "dead thread" to
> "it's done" that has raised tempers, rather than the decision itself. I
> think it would have been reasonable to follow up with a "this seems
> decided, I'll do it in a few days" type of email - similar to how the
> branching happens. We have a similar "final call" approach in the RFCs, in
> case anyone lost sight of the thread in the noise.
> 
> In short then, we are where we are. I think these concerns *should* have
> been raised earlier, but now that they *have* been raised, I think they're
> valid, and we should finish the discussion. As it stands today, we have
> around 5-to-4 in favour of dropping EL6 in 1.13, but that's not any kind of
> consensus.

Count me in for EL6 support for at least another release. If there's some 
extra effort needed with which I can help somehow, I'm happy to do so. I 
thought we solved main problems on smart-proxy using puppet API and SCL for 
dynflow plugin.

--
Marek

> 
> Can we get a (re)statement of the pros/cons from each side, to inform the
> choices of those on the fence? As of 10th May it seemed that the support of
> EL6 was only causing minor issues - is that still true? Other than
> preparation time (which is valid) are there other concerns for dropping it?
> 
> (PS - More generally, we seem to have an issue with "closing"
> discussions/RFCs with a firm decision; many discussions die out in this
> way. Thoughts on how we can improve that are welcome, and I will post my
> own, but lets start a new thread for that)

-- 
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] "Team AL-GTD - 1" deleted

[Marek Hulán]

On Wednesday 27 of July 2016 09:09:20 Dominic Cleal wrote:
> On 27/07/16 08:54, Marek Hulán wrote:
> > On Monday 25 of July 2016 07:57:35 Dominic Cleal wrote:
> >> I've deleted the the "Team AL-GTD - 1" version that somebody had added
> >> to the Foreman project in Redmine, as it's project-wide and so is set on
> >> every issue.
> > 
> > Hello
> > 
> > Could you please elaborate a bit why this is considered bad? I planned to
> > use the same for planning and prioritization of our issues too. What do
> > you mean by "set on every issue"? As far as I can tell when I create new
> > global version, a new field "Target version" appears on issue form but
> > it's not mandatory to fill so people can ignore it.
> 
> Currently prprocessor's configured to set the target version to the
> first available automatically, so a PR is opened and it's set to the
> upcoming target version. Issues in the Foreman project were being set to
> this "Team AL-GTD 1" when it was created.
> 
> Perhaps the prprocessor behaviour can be changed to be configurable per
> project if other projects are relying on this feature.

Ah, makes sense now, thanks. So unless anyone objects (see below) I'd send a 
patch to PR processor to ignore target version.

> > Note that version does not conflict
> > with releases that I know are being used actively.
> 
> Yes, in Foreman we're using releases, but other projects may use the
> target version.

I went through projects and it seems it's mostly used by Discovery Hammer and 
OpenSCAP. Others seems to me to be obsolete or some testing versions. For our 
planning purpose the version does not have to be even shared with subprojects 
so plugins can continue using it while they would not see our global version. 
The only downside is that we don't see the plugin issue in product backlog if 
it's target version is already set to some specific plugin version. That should 
be fine in our use case.

So is there any concern from anyone using redmine for his or her plugin 
regarding adding few Foreman-wide versions? If not I hope to start using it 
from tomorrow (after pr processor is updated of course).

Thank you

--
Marek

-- 
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] Re: external_node_v2 refactor!

[Marek Hulán]

Hello

I don't think there's too much functionality in this script. Maybe a unit test 
for what's worth of testing would be enough? In such case I'd recommend using 
minitest. It has some stubbing built-in but maybe webmock [1] might be useful 
for stubbing out communication with Foreman.

[1] https://github.com/bblimke/webmock

--
Marek

On Thursday 21 of July 2016 01:50:02 otheus uibk wrote:
> Having written being in favor of Cucumber / Aruba, I do have doubts about
> it: the documentation is severely lacking, and while I finally found a
> decent guide, it's not clear to me using this will provide the tactical
> advantage I hoped for.
> 
> On Thursday, July 21, 2016 at 2:54:09 AM UTC+2, otheus uibk wrote:
> > The critical nature of node.rb has taken me down the rabbit hole of
> > functional development, which in the ruby/puppet world means rspec. But in
> > order to refactor properly, what I really need here is to test the
> > behavior
> > of the script _as an executable_. The current rspec file does unit testing
> > on some of the internal methods of that file, treated as a module. Some
> > googling brought me to the ARUBA project, which is a sub project of
> > cucumber. I'm very keen on the whole BDD cycle in general, but
> > unfortunately, the *style* of documentation of that project makes it very
> > difficult for me to proceed. It's clear that if I were to test
> > external_node_v2.rb using cucumber/aruba, I will need to add quite a few
> > files and it's a lot of work. Which I don't mind doing. But before I
> > proceed, I ask: Are there objections to using cucumber / aruba within this
> > project? Are there alternatives for testing a program as a black box? (In
> > our case, the testing harness will need to start a temporary HTTP service
> > to provide test files, in lieu of an ability to set up a mock).

-- 
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] hammer_cli_foreman_openscap

[Marek Hulán]

Hello

I have few more findings with the latest version, please find them below in 
text. Some of them might need fixing in API rather than here. Feel free to just 
create redmine issue from them in such case. Once below comments are fixed I 
think we can move it under theforeman org (unless someone objects).


On Friday 13 of May 2016 03:59:18 oprazak wrote:
> Thanks for comments, I made some changes and took care of the following:
> 
> * scap-content update -h displays --new-name without any help, using it
> 
> > fails
> > hammer scap-content update --id 1 --new-name test23
> > results in 400
> The name option was added by default and I did not notice. It is removed
> since scap content has only title.
> 
> * updating scap-content file does not seem to work
> 
> > hammer scap-content update --id 1 --scap-file
> > /usr/share/xml/scap/ssg/content/ssg-centos6-ds.xml
> > results in 400
> 
> Uploading files should work properly for both create and update commands.
> 
> * scap-content is missing create and info commands, there's currently no
> 
> > way
> > to display associated orgs and locs
> > 
> > * scap-content info should also display profile ids, otherwise I can't
> > create
> > policy
> 
> I added the missing commands and we can view profile_ids and taxonomies.

the info command lists --name but that does not work, it does not list --title 
which is required to search for scap-content by title

> > * policy create allows to specify weekday as 1, update forces me to
> > specify
> > monday
> 
> I think this is a problem of foreman-side validations, more on that below.

policy create help says I can use scap content name, when I try I get 400, 
probably because content has only title, using id helps

hammer policy create --hostgroup-titles default --name default --scap-content 
default --scap-content-profile-id 1 --period daily
Could not create the policy:
  Error: 400 Bad Request

weekday is always required even if period is daily

using hostgroup titles results in following error

[ERROR 2016-06-14T11:12:22 Exception] undefined method `empty?' for 1:Fixnum
Could not create the policy:
  undefined method `empty?' for 1:Fixnum

using hostgroup id results in following error

Could not create the policy:
  You cannot call create unless the parent is saved

without hostgroup specification it saves fine

> > * arf-report shouldn't provide update command, probably caused by copy and
> > paste, since the definition contains wrong messages anyway
> 
> Removed.

arf-report help suggest we can use name for search, ArfReport object doesn't 
seem to have any name attribute

> 
> A bit unrelated but found during testing
> 
> > * policy create help would deserve better strings, e.g. valid values for
> > period (it's more about foreman_openscap API)
> > 
> > * when there's no foreman_scap_client manifest I receive 422, it should be
> > some better explanatory error
> 
> Policy cannot be created/updated if foreman_scap_client puppet class is not
> found in foreman. I improved the error handling, we should get a sane
> message about what went wrong.
> 
> Related concerns:
> * Policy validation could use some improvements. Validations for scheduling
> are triggered conditionally, for example 'weekday' gets validated only if
> period is 'weekly'. This is fine for our UI, but it does not prevent
> passing '--period monthly --day-of-month 15 --weekday $something_ugly_here'
> on command line, which effectively bypasses the weekday validation.
> 
> I plan to add search options for locs and orgs but I haven't fully figured
> it out yet.
> Let me know if there is anything else.
> O.

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