[foreman-dev] New form helpers and reusing definitions from server side

[Marek Hulán]

Hello

I'd like to bring into awareness a discussion that's going on in bookmarks PR 
[1]. This PR demonstrates how to do client side validations using new 
components for forms. E.g. this is how we define that the field is required 
and can't be too long [2]. We have similar validations defined in our model.

One concern I had is that we'll duplicate the definition, both in UI and our 
data model. I'd prefer to have UI validation rendered based on server 
definition. There are cases where the UI field is not related to the specific 
model attribute so we also need the option to explicitly define client 
validations.

Similarly, strings that are normally rendered server side are now duplicated 
at [3]. That can end up in out of sync error messages for users using UI and 
API.

Of course this can be refactored later, but if we start to hardcode too many 
things, the motivation for later refactoring will be lower. Also I'd like to 
have good form helpers from the beginning since changes to them will have 
impact on many plugins later.

I'm definitely not going to block the PR on this. But I'd like to hear 
opinions of others, suggestions for improvements or any other feedback. 

[1] https://github.com/theforeman/foreman/pull/4807
[2] https://github.com/theforeman/foreman/pull/4807/
files#diff-6011fb23e8f8bacb536ab442e57b874cR48
[3] https://github.com/theforeman/foreman/pull/4807/
files#diff-6254f272d0e11d7caaacec9ece0c6669R6

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] 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] Proposal: Foreman 1.18 = 2.0

[Marek Hulán]

Dne čtvrtek 30. listopadu 2017 11:59:27 CET, Ewoud Kohl van Wijngaarden 
napsal(a):
> On Thu, Nov 30, 2017 at 09:57:24AM +0100, Marek Hulán wrote:
> >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).
> 
> These sound like good goals. How hard would it be to make the changes
> you're suggesting?
> 
> I have a slight preference to make 1.17 the 2.0 already because of the
> changes it's introducing but other than dropping API v1 and unattended
> installation mode they all sound like non-trivial tasks that will not be
> ready in time for 1.17.

very rough estimations
taxonomies (at least two release cycles)
apiv1 (easy if we don't need to spend time on proper extracting to gem/plugin 
that users could still install)
host group provisioning (drop is easy, refactor could be 1 foreman release)
smart variables unification with params - 1 or 2 releases, Ori has done some 
research in this area
extracting puppet to a plugin, not sure, Shim would perhaps know better
unattended installation mode - 1 release

I think even if we paralellize the effort, they should all be delivered in 
same release that we would call 2.0. Not sure how to do it, keeping PR opened 
for more than few weeks is not good :-) I'd like to avoid 2 develop branches.

> Maybe we need a list of deprecated features/desired breaking changes so
> we can look at it after a release when we're starting to plan for the
> next. If it grows to a certain size or the release manager feels like
> it's time for a major then they can announce it's being considered. That
> way devs have time to give priority to the breaking changes a long time
> in advance rather than the 2 weeks prior to branching.

That sounds good to me.

> What I'm proposing are guidelines that mostly focus on clear
> communication - no strict policy. Communication is much more important
> than what we actually do.

+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] Unique IDs and UI testing automation

[Marek Hulán]

Thanks Walden for bringing this up.

Dne středa 29. listopadu 2017 20:06:50 CET, Walden Raines napsal(a):
> > Seems reasonable to me. I don't really see a downside other than the work
> 
> to add all the IDs.
> 
> I don't think we should go through the entire application and add the IDs.

Why not? It might be a bit boring but very useful effort. If we only add IDs 
to new UI, I as an integration tests writer would remain frustrated whenever I 
add new test that touches existing area. I think it wouldn't be more than 1 
day of work to extend all tables in Foreman core. For inputs it should be even 
simpler as we have form helpers that would just need to be updated (but I 
think all rails inputs already have id).

This would also be a good opportunity for a contribution for someone who'd 
like to investigate the whole stack, go over all pages and do small code 
changes on them.

> I think the way to tackle this is two-fold:
> 
>- Add IDs as we update functionality on pages that don't have these IDs
>- Encouraging QE to report missing IDs (and potentially open a PR to add
>them) on troublesome pages
> 
> The latter has already been agreed to, the former is in our hands to
> remember to do.

I think we should also agree on a guideline how to construct such IDs, so we 
don't end up in random strings which would be prone to duplicates. For parts 
that are generated by rails, I think using dom_id helper would be a good start 
[1], obviously UI rendered from JS would need to have it's implementation of 
this method.

For tables we could have something like this
'table-users'

for tr, this should do
dom_id(user, 'row') # result is row_user_15 where 15 is id of user, or 
row_user if user is new_record

For inputs, rails follow the rule $resource_$attribute, while this does not 
necessarily need to be always unique, I think it's a good enough for resource 
forms. For the rest (e.g. search input) we should generate it uniquely, there 
are cases where we have 2 search field on the same page, e.g. roles and 
filters opened in 2pane.

For buttons it can be tricky. Perhaps the same approach as we have with data-
id today in core would do, or even keep to data-id only.

[1] https://apidock.com/rails/ActionView/RecordIdentifier/dom_id

--
Marek

> 
> Cheers,
> Walden
> 
> 
> On Wed, Nov 29, 2017 at 1:31 PM, Ewoud Kohl van Wijngaarden <
> 
> ew...@kohlvanwijngaarden.nl> wrote:
> > On Wed, Nov 29, 2017 at 01:08:13PM -0500, Walden Raines wrote:
> >> In order to assist in UI automation, I would like to propose that we add
> >> 
> >> unique IDs to the following elements:
> >>   - Tables and table rows (s)
> >>   - All inputs, including those not technically in a form (row select
> >>   checkboxes, for example)
> >>   - All buttons
> >> 
> >> These IDs should all follow the same format, perhaps something like
> >> object.class-object.id-element.type.  For example, product-2-row and
> >> product-2-checkbox.
> >> 
> >> Thoughts on this?  Anything that needs to be added or changed?
> > 
> > +1 This was also the feedback I heard from QE. Sometimes they have to use
> > xpaths to test which are more likely to break than IDs.
> > 
> > 
> > --
> > 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] 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 foreman-dev+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/o

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] Missing github issues features (no migration)

[Marek Hulán]

Dne středa 29. listopadu 2017 11:09:03 CET, Greg Sutcliffe napsal(a):
> On 29/11/17 09:33, Lukas Zapletal wrote:
> > Or maybe I miss the main reason why we are not using Github issues at
> > all?
> 
> As you said, the last time we evaluated it, it simply wasn't suitable.
> The situation is more comparable now, however (in addition to BZ link
> and private issues) I think we would also lose flexibility. In the the
> last week or so, Marek and Walden have both proposed new plugins that
> could be added to our Redmine - not possible if we go to GH, we'd be
> stuck with waiting for them to implement new features (and in my
> experience that's not fast at all). That's always the downside of going
> proprietary over open source ;)
> 
> > I like github integration with PRs, speed and good reliability (only
> > few blackouts per year) and also new features like projects. On the
> > other hand, it's full commitment to something not under our control
> > (today we can easily move our git somewhere else, but we still loose
> > all PRs).
> 
> Side note: Actually the PR data is accessible over the API, and I have
> *all* of it in a MySQL DB. Yes, that's a lot of data - once I learn more
> about data analysis (studying R at the moment :P) I will be doing things
> with it.
> 
> > This email is just to discuss possibilities, I know that migration
> > to Github would be painful and even too expensive or perhaps
> > technically not doable (how to migrate so many tickets). It's a pitty
> > that github is now getting features it really needed.
> 
> I think that's the key point. There's no doubt we *could* make GH Issues
> fit our workflow (or any other bugtracker) - but the effort to migrate
> 20,000+ Redmine issues to multiple repos, as well as change all the
> automation, is more than likely not worth it. There needs to be a *huge*
> win for moving to GH Issues to make it happen, and I'm only seeing
> side-grades and incremental stuff, I'm afraid.
> 
> > I also really like gitlab which is packed with super nice features,
> > theoretically migration to something like that would be easier (open
> > source). On the other hand, we'd need to host this and one thing is
> > having redmine down for an hour, different thing is inability to
> > push. But this is definitely a possibility, we also have some know
> > how already running our internal instance.
> 
> I'd be +1 for GitLab-for-everything, assuming we can figure out some
> reliablity, as you say. Maybe using Gitlab.com is an option. But *wow*
> that is a lot of work :D
> 
> Greg

+1 to Greg reply, personally I'm fine with redmine.

--
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] Question about defaults for VM memory

[Marek Hulán]

Hi Perry,

we default to 768MB by default unless the value comes from the compute 
profile. I agree that 1 GB would be a better default. But if you configure a 
value for a compute profile that you specify also in a hostgroup that you use 
for provisioning, you de facto configure your own default.

--
Marek

On středa 15. listopadu 2017 20:51:40 CET Perry Gagne wrote:
> Hello,
> 
> How does foreman decide what the defaults are for memory when provision VMs
> via the webui?
> 
> Sometimes when creating VMs to test provisioning configs, I forget to
> adjust to memory (I usually use about 2 gig to be safe).  Foreman defaults
> to 768MB.
> 
> I am wondering if that is enough, RHEL Kickstart for example seems to have
> issues even with 1 gig.
> 
> We don't seem to have anyway right now of making the defaults tied to the
> OSs recommendations.
> 
> I can create an RFE to raise the default, but I figure I would ask here
> first to see what peoples thoughts where.
> 
> Thanks,
> -Perry


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

Re: [foreman-dev] [RFC] Deprecate and move Github RFC repo content

[Marek Hulán]

Since you volunteered to clean up, definitely a +1 from me :-)

I agree that discussion should happen outside of the RFC itself as the 
discussion in the PR was usually hard to follow. It was not clear if comments 
are still valid or not. Mail list seems to have good presence of developers so 
I expect the discussion to happen there. I don't really care which wiki we use 
for writing summaries of this discussion but redmine feels a bit more natural 
to me.

--
Marek

On středa 15. listopadu 2017 10:14:49 CET Lukas Zapletal wrote:
> Hey,
> 
> this is another proposal to deprecate Github RFC repo and move the
> content to our wiki. Reasons:
> 
> A) There is zero merged proposals for the past year (Jan-Nov 2017):
> https://github.com/theforeman/rfcs/commits/master
> 
> B) Activity is very low (comments in 3 PRs last winter, 3 PRs last
> summer, 1 PR last month):
> https://github.com/theforeman/rfcs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-> 
> desc
> 
> C) There is only one published RFC on the front page (by the way I am
> the author). I see some randomly numbered files in text/ folder but
> this does not look like a friendly space to newcomers or even
> experienced guys. We failed following processes described on the front
> page obviously and it's no surprise - people in need of writing a
> proposal need to focus on the most important stuff.
> 
> D) Developers naturally create [RFC] threads on our -dev list, some
> random subjects:
> * Make foreman STI to work even when an inherited class is not found
> * Proxies with multiple interfaces
> * Found In Version Katello Redmine custom field
> * Foreman with Puppet in a wildcard domain leads to nodes mistaken identity
> * Templates rendering only through Proxies
> ... and others I am gonna stop here. These are e-mail from core devs
> and also our community.
> 
> E) It's been already proposed on list by Tomer ("Retire the RFC
> repo"). Some people expressed intentions to use it (Justin, Eric, John
> and Perry) but I haven't seen much activity (see above). One of the
> reasons was time, but these days we should be pushing hard on
> proposals for the next generation of Foreman versions and I don't see
> this. Greg agreed this needs some more work around visibility and
> process improvement, but I don't see much improvements.
> 
> F) Content is not visible, most of us don't use it and WIP RFCs are
> quite unreadable. I want to read proposal as a completed document and
> then I want to send a consistent opinion about it.
> 
> PROPOSAL
> 
> Let's close the RFC repo for new PRs, add a note that contents has
> been moved. I will then move all finished RFCs to our wiki page. We
> already have that for years, it's named Features:
> 
> http://projects.theforeman.org/projects/foreman/wiki/Features
> 
> There is a template
> 
> http://projects.theforeman.org/projects/foreman/wiki/Sprint_Feature_Template
> 
> And couple of proposals already:
> 
> http://projects.theforeman.org/projects/foreman/wiki/Pagelets
> http://projects.theforeman.org/projects/foreman/wiki/Discovered_host_redesig
> n
> http://projects.theforeman.org/projects/foreman/wiki/Remote_Execution_Desig
> n http://projects.theforeman.org/projects/foreman/wiki/CentralizedLogging
> http://projects.theforeman.org/projects/foreman/wiki/PXE_Booting_UEFI (I
> moved this one, I take this back)
> 
> The wiki pages are just a place to put content on, a opt-in way. Most
> of us will likely prefer e-mail list for smaller proposals and I
> encourage everybody to continue to do so. This is just a complementary
> place, but it's not pulling conversation out of our devel list.
> 
> BENEFITS
> 
> 1) Stops splitting place for important discussions - we already have
> the dev list.
> 2) Actually *readable* content, easy to edit, easy to track changes.
> 3) Rich content - github hasn't invented HTML/RTF with images, wiki
> can do it all.
> 4) Free form - just write your proposal, add a title, name and status
> and that's it.
> 
> ALTERNATIVE PROPOSAL
> 
> Let's keep the github repo but remove all git content and move all
> pages to wiki section under that github repository. Discussion will be
> made in the devel mailing list. Advantage is that the syntax will
> remain the same, but I hereby offer migration of all finished RFCs
> into RedMine syntax.


-- 
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] 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] speeding up tests

[Marek Hulán]

On čtvrtek 9. listopadu 2017 10:14:33 CET Tomas Strachota wrote:
> On Tue, Nov 7, 2017 at 11:17 AM, Ivan Necas  wrote:
> > On Tue, Nov 7, 2017 at 9:29 AM, Lukas Zapletal  wrote:
> >> We should start tracking test breakages in time, if we have a test
> >> that did not break for a year, lets delete it. As simple as that. It's
> >> added value is almost zero.
> >> 
> >> This is not out of my head, I've heard that on a talk somewhere.
> >> Instead of deleting, we can move it to archive - run them on a nightly
> >> basis, if we find this too much. Frankly, I prefer deletion.
> > 
> > -1: the fact that the test doesn't fail in a year can be just due
> > to fact that we have not worked on that area for some time. It might
> > work for some project with strictly defined use-case, but for Foreman,
> > I don't think thats' the case.
> 
> -1 as well for deleting the tests. They become useful once you start
> refactoring things even when the code wasn't touched for a long time.

Another -1 for deleting based on time, +1 for revisting tests and deleting 
tests with zero value (there are such tests). Honestly I think the biggest 
performance improvement would be by manually going through tests and fixing 
them. Minimizing DB calls where possible, remove duplicated tests etc.

--
Marek

> 
> >> Also, let's ditch unit tests in favor of integration tests. We have a
> >> lot of areas covered with both and this is extra work and slowing down
> >> things.
> > 
> > +1 for integration tests > unit tests: and I'm willing to talk about
> > deleting unit-tests once we know that integration tests are covering the
> > same.
> > 
> > I feel unit-tests more important, when working on specific algorithm etc.
> > We don't do it that often. We mostly integrate.
> 
> +1 I see more value in integration tests in general. Unit tests for
> algorithms are useful too.
> I see less value in unit tests for attribute presence and simple
> validations like uniqueness.
> 
> >> LZ
> >> 
> >> 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.
> >>> 
> >>> 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
> >>> * ...
> 
> That would definitely help to improve day-to-day developer's experience.
> 
> >>> 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:
> >>> 
> >>> * smaller repos - faster tests per repo (we would still need a plugin
> >>> matrix kind of tests done at some point)
> >>> * 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")
> >>> * 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.
> 
> The biggest benefit of splitting the repos is imho the need for
> stabilizing the api between components.
> I believe that there would be some transfer to stability of the whole
> project.
> >>> 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.
> >>> 
> >>> --
> >>> 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

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 approach seems to be more appropriate
> > >

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] Please set the release in redmine when merging PRs

[Marek Hulán]

> I'll try to remind reviewers when I see it unset unless I get negative
> reactions here. I'm going over all issues merged after 1.15 branching and
> setting 1.16.0 where appropriate.
> 

Hello,

it took me a while to get back to it but it should be now complete.

--
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@googlegroups.com

[Marek Hulán]

It's been like this for a long time. I started to work on unification recently 
and I have it in my branch but I need to add a migration for existing Katello 
users. There's no need to have separate Katello templates.

Anyway as a workaround, the &: syntax need to be replaced before we unify 
them.

--
Marek

On pátek 20. října 2017 14:28:59 CEST Lukas Zapletal wrote:
> Looks like Katello ships some extra templates?
> http://projects.theforeman.org/issues/21406
> 
> On Fri, Oct 20, 2017 at 2:01 PM, Lukas Zapletal  wrote:
> > Hello,
> > 
> > I am just preparing demo for OSS Europe and I noticed that the bug in
> > safemode hasn't been fixed in 1.15.6 yet. That's a blocker bug we
> > should consider fixing in 1.15 series.
> > 
> > Was there a bump of safemode gem or templates? The issue is with:
> > 
> > Katello Kickstart Default template:
> > https://gist.github.com/lzap/df6c103573dba61cc5bc22d39c6201b6
> > 
> > LZ
> > 
> > --
> > Later,
> > 
> >   Lukas @lzap Zapletal


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

Re: [foreman-dev] Release process & permissions

[Marek Hulán]

Hello

I like 2. At the same time, if it takes more then few weeks, I'd say let's 
just give the release person all permission that are required. If we agree 
that the person should do the release (in the worst case, we can do the 
nomination process), we should make it as easy as possible for them to do the 
job. I don't think anyone would break something on purpose. People tend to ask 
more skilled people when they are uncertain.

Thanks for the write up!

--
Marek

On středa 27. září 2017 16:46:34 CEST Daniel Lobato Garcia wrote:
> Hi devs,
> 
> After a few releases, and now that I'm trying to help someone else to
> take over in case it's needed, I found a roadblock.
> 
> Whoever is doing the release, needs to have **many** permissions.
> 
> Otherwise, it doesn't make much sense for a person to take over release
> responsibilities. For example, if Ondrej has to do 1.15.5, he would need
> the following permissions (see at the end of the email).
> 
> Of course there are alternatives:
> 
> 1 is to have the release nanny be supervised by people who have 'earned'
> these permissions. This is a bad idea because some of the tasks just
> cannot be 'supervised'. The nanny would have to ask someone to tag
> repositories, modify jenkins jobs, upload GPG signatures, post to the
> mailing list, tag new builds in Koji...
> 
> 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and
> make it a real pipeline from 0 to release completed. At this moment,
> releases that are not the first RC1 are mostly automated by
> https://github.com/dlobatog/foreman_release and
> https://github.com/theforeman/tool_belt.
> 
> My proposal is to go forward with 2. Give Jenkins permissions to do all
> of the actions needed, and whoever is the release nanny, ideally only
> has to make sure all of the steps are moving forward. If something
> breaks, figure out how to fix it for the next release.
> 
> This would mean making a few extra jobs before and after the current
> release pipeline. In my opinion, it's the way to go to ensure anyone can
> take over this responsibility.
> 
> At this moment, we are in a situation where only people who
> mostly have permissions everywhere can successfully do a release without
> asking many people for favors.
> 
> Personally if we complete this, I see it as a big win as it would dwarf
> our bus factor for release managers & allow us to release at any pace we
> desire (right now it's slow because we can't truly release things from
> one day to the next due to the work involved).
> 
> Thoughts?
> 
> Here's the list of permissions:
> 
> 
> 
> Github:
>   - Push in foreman, foreman-selinux, foreman-installer,
> smart-proxy, foreman-infra, foreman-packaging
> 
> Transifex -
>   - Allow to change the auto-update URL to point to latest -stable
> branch
> 
> Redmine -
>   - Create new "Found in Release" version
> 
> Jenkins -
>   - Modify jobs
>   - Run jobs
> 
> Koji -
>   - Create tags
>   - SSH access to update the mash scripts
>   - Create packages
>   - Tag builds
> 
> Repository servers
>   - ssh in deb.theforeman.org
>   - ssh in yum.theforeman.org
> 
> Announcements -
>   - Post to foreman-announce
>   - Merge access in theforeman.org
>   - Change IRC message
>   - Publish in Twitter, G+
> 
> ---
> 
> --
> Daniel Lobato Garcia
> 
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
> 
> GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
> Keybase: https://keybase.io/elobato


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

Re: [foreman-dev] Access to foreman-infra

[Marek Hulán]

On pondělí 25. září 2017 14:01:57 CEST Ewoud Kohl van Wijngaarden wrote:
> Hello all,
> 
> To get more involved in foreman infra I'd like to request push access to
> foreman-infra. At first I'd like to help more with the CI.
> 
> Regards,
> Ewoud Kohl van Wijngaarden

+1, although I'm not in infrastructure team :-)

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

[Marek Hulán]

Based on 2 thumbs (+1 mine :-) and no negative response, I sent an invitation 
to Bryan. Looking forward for your contributions Bryan.

--
Marek

On pondělí 11. září 2017 10:36:27 CEST Marek Hulán wrote:
> 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.

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 w

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]: https://github.com/theforeman/forem

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/ansibl

Re: [foreman-dev] Plugins configuration managment platform

[Marek Hulán]

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
[3] 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
[5] https://github.com/theforeman/foreman_chef/blob/master/lib/foreman_chef/
engine.rb#L81-L83

Hope this helps

--
Marek

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


-- 
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] Nomination for an additional GitHub org owner

[Marek Hulán]

Totally makes sense to me, +1. Good point about the timezone.

--
Marek

On čtvrtek 29. června 2017 10:42:44 CEST Tomer Brisker wrote:
> Well, how about our fearless community leader?
> Makes sense to me that managing the community includes the github repos
> when needed - adding maintainers, migrating repos etc.
> I nominate Greg Sutcliffe to be another owner of the git org as he is
> available in European times.
> ​Greg has been an active member, contributor and maintainer for quite a few
> years now and should have no problem helping out with these tasks.​
> 
> 
> On Mon, Jun 26, 2017 at 4:41 PM, Greg Sutcliffe 
> 
> wrote:
> > On Mon, 2017-06-26 at 10:25 +0300, Tomer Brisker wrote:
> > > +1 to adding Eric, although that won't solve the issue of Ohad and
> > > Dominic being busy and having no owner available on this side of the
> > > globe.
> > 
> > That's fair, do you want to start a new nomination thread to address
> > that? :P
> > 
> > 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.

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] Cannot view full report | Openscap

[Marek Hulán]

The issue was opened as http://projects.theforeman.org/issues/20077 which is 
now considered resolved. The issue was that the given host did not have 
openscap smart proxy assigned.

--
Marek

On čtvrtek 22. června 2017 16:56:27 CEST sai krishna Khanday wrote:
> Hello,
> 
> Foreman Host OS: RHEL 7.3
> Foreman Version: 1.15.0
> Foreman OpenSCAP Plugin Version: 0.7
> 
> 
> When trying to view a full report in the Foreman UI, we are receiving the
> following error:
> 
> 
> ERF42-7625 [Foreman::Exception]: No OpenSCAP proxy found for
> ForemanOpenscap::ArfReport with 996599
> 
> 
> There is no addition information regarding the error code.
> 
> http://projects.theforeman.org/projects/foreman/wiki/ERF42-7625?parent=Error
> Codes
> 
> 
> I made sure smartproxy has openscap as active feature. Reports are
> generated and uploaded but getting above error while trying to access full
> report and even compliance openscap metrics is also blank.
> 
> 
> I don't see any openscap error logs generated in
> /var/log/foreman-proxy/proxy.log or /var/log/foreman/production.log
> 
> 
> 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] #10089 - not so simple?

[Marek Hulán]

Hello,

thanks for your contribution! I'd recommend opening the PR on github with the 
change, that way it will get attention of more reviewers. If you're not sure 
about the process, please find a description at [1]. My opinion on the change 
is that it should change the font only for text areas that contain the YAML/
JSON, therefore in this case only when parameter type is set to YAML/JSON.

Thanks

[1] https://www.theforeman.org/contribute.html#SubmitPatches

--
Marek

On neděle 25. června 2017 14:09:22 CEST Eric Anderton wrote:
> New poster, long time Foreman user, and hopeful contributor here.
> 
> As I've decided to take the plunge into contributing to Foreman,  I figured
> #10089 might be a good newbie task to pick off:
> 
> http://projects.theforeman.org/issues/10089 - Use fixed-width font for
> parameters
> 
> """As some parameters are displayed as YAML, using a fixed-width font would
> greatly ease reading and writing of such values.
> Right now, indentation is too hard to get right and I usually have to edit
> the parameter in an external editor then copy-paste the content in order to
> avoid problems."""
> 
> ---
> 
> My hunch is that this has been sitting open for two years now because
> either it's really this simple, or there's some nuance here not documented
> in the feature request.
> 
> The code below sets textarea.form-control fields to monospace.  Since
>  is used in a lot of places next to controls that are styled as
> Helvetica, modifying all places where .form-control is used would cause
> cosmetic issues.  Plus, the lack of fixed-width input today is mostly an
> issue for multi-line input (AFAIK).
> 
> Example:
> https://github.com/eanderton/foreman/commit/84657c11c0893b86b922dc0b70047863
> 9ea26217
> 
> I'm open to any additional suggestions on this one.  Any feedback?
> 
> Thanks,
> - Eric Anderton


-- 
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] Nomination for an additional GitHub org owner

[Marek Hulán]

+1

On pondělí 26. června 2017 7:41:18 CEST Ondrej Prazak wrote:
> +1 from me
> 
> On Mon, Jun 26, 2017 at 3:16 AM, Tom McKay  wrote:
> > +1 for @ehelms
> > 
> > On Fri, Jun 23, 2017 at 9:05 AM, Neil Hanlon  wrote:
> >> +1 from me :)
> >> 
> >> On Fri, Jun 23, 2017 at 8:44 AM Greg Sutcliffe 
> >> 
> >> wrote:
> >>> Hi all,
> >>> 
> >>> Slightly different to our usual "nominate a new commiter" process, but
> >>> I'm wondering if we need to appoint a new owner on our GitHub
> >>> organisation?
> >>> 
> >>> Currently, only Dominic and Ohad are owners, and they are both
> >>> frequently busy with other things, which leads to some delays when
> >>> adding in new repos or moving things about. 2 people is also a fairly
> >>> high bus factor. I think it's time we added a third name to the owners
> >>> - we don't have an official process for this, but I'm treating like
> >>> commit access, so here's a nomination email.
> >>> 
> >>> Obviously, this is mainly a role for maintenance - creating/forking
> >>> repos, moving them, creating new teams, etc. rather than about merging
> >>> code. I think a we have a few people that would be a good fit - my
> >>> suggestion would be Eric Helms. He's experienced both in our structure
> >>> & in GitHub-y stuff, and is in a different timezone, which helps if
> >>> something comes up out of European hours.
> >>> 
> >>> Any comments/concerns/upvotes? :)
> >>> 
> >>> 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.
> >> 
> >> --
> >> 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] Proposal to move "How to create a plugin" page to github.

[Marek Hulán]

> Am 22.06.17 um 11:16 schrieb Greg Sutcliffe:
> > +1 for moving the plugin documentation to the plugins part of the
> > website. I think that makes sense, and we can (as with other areas)
> > keep the wiki for footnotes, edge cases, and tips.
> > 
> > Greg
> 
> I'd suggest to add a Markdown file to the core repo. I believe code
> documentation is better suited to be in the code repo and the
> documentation can be reviewed alongside the code change in core by core
> maintainers. The website should be more for foreman users. But
> theforeman.org is fine with me as well.
> 
> - Timo

Having this info in the codebase itself sounds reasonable but I'd prefer 
having it on one place with other pages such as template writing wiki. The 
later is also useful for users and ideally will be moved to theforeman.org one 
day.

If there was a reliable way to sync it from theforeman.org to core codebase, 
that would we great. If I had to choose between these two, then I find 
theforeman.org better. I think Google would give better results for potential 
plugin writers too.

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

Why do you want to introduce it in a new plugin? I can see the global proxy 
setting in core. When we get to the point when we want to have separate proxy 
per library/plugin/communication then I think we should start using the 
foreman_http_proxies plugin and enhance it if needed. From my experience, 
starting a plugin brings a lot of extra maintenance effort, such as test 
infrastructure, redmine setup, plugin manual write-up, hammer plugin from 
scratch, support in installer. Why not simply add a new setting in Foreman?

--
Marek

On středa 21. června 2017 16:28:38 CEST Sebastian Gräßl wrote:
> The biggest part of this all is actually ensuring that all requests made by
> the application are actually going through the HTTP proxy.
> 
> As a solution to that, I was thinking of starting a plugin that configures
> the proxy for HTTP libraries (Net::HTTP, Excon, RestClient, etc.) used.
> At first it would only make sure that we have all requests covered.
> As a nicety it could also have a debug mode to show outgoing requests via
> something like httplog[1].
> 
> The HTTP proxy would at first just be one global setting, but later on by
> extending the used libraries' underlying request methods it could
> also allow for dynamically choosing the appropriate proxy per request.
> This then can be used by the foreman_http_proxies[2] plugin.
> 
> [1] https://github.com/trusche/httplog
> [2] https://github.com/jlsherrill/foreman_http_proxies
> 
> On Thursday, May 25, 2017 at 11:58:12 AM UTC+2, Marek Hulán wrote:
> > sorry for typo, it should have been:
> > 
> > AFAIK we don't *have* the solution *implemented* atm.
> > 
> > On čtvrtek 25. května 2017 11:49:24 CEST Marek Hulán wrote:
> > > 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
> > > 
> > > > 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 <http://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
> > > > > 
> > > > >  <mailto:seba...@validcode.me
> > 
> > >> 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
> &

Re: [foreman-dev] Proposal to move "How to create a plugin" page to github.

[Marek Hulán]

+1, I think it could be added to developer handbook [1] or new section at [2] 
or to plugins page [3]

[1] https://theforeman.org/contribute.html
[2] https://theforeman.org/documentation.html
[3] https://theforeman.org/plugins/

--
Marek

On čtvrtek 22. června 2017 8:48:39 CEST ssht...@redhat.com wrote:
> Hi all,
> 
> Recently I have created a couple of PR's that added extension point to
> plugins. These extension point needed to be documented in the
> http://projects.theforeman.org/projects/foreman/wiki/How_to_Create_a_Plugin
>  document.
> The problem is that between the time I have created the code PR and the
> time it got merged (and the doc change was necessary) passed a couple of
> months. I had to remember the context when I was writing the PR in order to
> write the wiki page.
> 
> I suggest creating a docs PR side by side with the code PR and creating a
> reference between them.
> Benefits:
> 1. The documentation would be created in the same context by the developer,
> while it's fresh in his memory and he remembers all the caveats for the
> user.
> 2. The reviewers could better understand what the PR is offering.
> 3. There is less chance for the developer to forget to update the docs
> 
> In order to do that, we have to move the page to github (somewhere in
> theforeman.org  repo).
> To mitigate a concern about the ease of change, we can put a link to edit
> the page in the header/footer of the page itself, so it will be one click
> away for anyone who wants to edit it.
> 
> Comments?


-- 
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] Please set the release in redmine when merging PRs

[Marek Hulán]

As long as it won't override manually set release, that could work. I'm not 
sure if we distinguish between core and plugin in prprocessor but I suppose 
few "ifs" would do.

I'm OK with manual setting too since I open the redmine issue prior merge 
anyway to check the PR is linked to correct one and it implements the whole 
issue.

--
Marek

On středa 14. června 2017 22:05:28 CEST Sean O'Keeffe wrote:
> Is this something we could think about automating in similar way the PR is
> set by theforeman-bot ?
> 
> On Wed, 14 Jun 2017 at 20:50, Marek Hulán  wrote:
> > Hello
> > 
> > I'd like to kindly ask all Foreman committers to set the release version
> > in
> > the linked redmine issue after they merge the PR. In past, Dominic used to
> > do
> > it, unless it was set by the reviewer. Please correct me if I'm wrong but
> > I
> > think it's not going to happen any further.
> > 
> > I think it's very helpful to users and devs to easily find out, what
> > Foreman
> > version contains the fix, just by looking at redmine issue. Therefore I'd
> > like
> > to continue with this but I'd appreciate if we I'm not the only one who
> > set
> > it.
> > 
> > After PR is merged, the last existing version should be set to "Release"
> > field, atm it's 1.16.0. If you merged something that you believe should be
> > cherry-picked into last stable version, set that as a release, e.g.
> > "1.15.2".
> > Meaning of Release field is "the lowest Foreman version that contains the
> > fix".
> > 
> > I'll try to remind reviewers when I see it unset unless I get negative
> > reactions here. I'm going over all issues merged after 1.15 branching and
> > setting 1.16.0 where appropriate.
> > 
> > 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.


-- 
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] Please set the release in redmine when merging PRs

[Marek Hulán]

Hello

I'd like to kindly ask all Foreman committers to set the release version in 
the linked redmine issue after they merge the PR. In past, Dominic used to do 
it, unless it was set by the reviewer. Please correct me if I'm wrong but I 
think it's not going to happen any further.

I think it's very helpful to users and devs to easily find out, what Foreman 
version contains the fix, just by looking at redmine issue. Therefore I'd like 
to continue with this but I'd appreciate if we I'm not the only one who set 
it.

After PR is merged, the last existing version should be set to "Release" 
field, atm it's 1.16.0. If you merged something that you believe should be 
cherry-picked into last stable version, set that as a release, e.g. "1.15.2". 
Meaning of Release field is "the lowest Foreman version that contains the 
fix".

I'll try to remind reviewers when I see it unset unless I get negative 
reactions here. I'm going over all issues merged after 1.15 branching and 
setting 1.16.0 where appropriate.

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

[Marek Hulán]

On úterý 6. června 2017 9:54:12 CEST Tomas Strachota wrote:
> On Mon, Jun 5, 2017 at 4:14 PM, Lukas Zapletal  wrote:
> > On Mon, Jun 5, 2017 at 2:48 PM, Tomer Brisker  wrote:
> >> My suggestion is that we replace the katello test currently running on
> >> every PR with a test that installs the top 5 plugins together and runs
> >> all of their tests.
> > 
> > +1 +1 +1
> > 
> > Last week or two, Katello was red because of trivial regression in the
> > testing framework, we did not block PRs at all, but eventually Daniel
> > stepped up and fixed it. That sounds to me this works! If we can
> > extend this to other plugins - big improvement for these. For
> > discovery this would be huge improvement in overall stability.
> > 
> > I agree that it should not make the jenkins load much worse, discovery
> > and also other plugins has only dozens of tests, so the slowdown
> > should not be significant I hope. We can stick with what Katello team
> > does today - only test postgresql on particular ruby version (2.2 I
> > think today). If we are able to run them all in one rake task, that
> > would mean just one Rails boot as well.
> 
> +1 for testing a set of most used plugins on postgresql and one ruby
> version for each PR. Together with that we can still keep testing for
> the full matrix once a week.

+1 to what was suggested except for the limit 5 :-) as long as plugins tests 
take less than 1 minute (usually it's within seconds), I think we can test 
more.

plugins I'd like to see tested since they are not tiny and hence more prone to 
be broken by changes:

remote execution
discovery
openscap

--
Marek

> 
> > What others say? Next steps would be:
> > 
> > - nominate the plugins for this and vote them (or we can simple take
> > most downloaded from our survey)
> > - modify katello job to test all of them
> > - rename katello job perhaps to avoid confusion?
> > 
> > --
> > Later,
> > 
> >   Lukas @lzap Zapletal
> > 
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > foreman-dev+unsubscr...@googlegroups.com. For more options, visit
> > https://groups.google.com/d/optout.


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

Re: [foreman-dev] 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 history of why we did
> >> 
> >> this.
> >> 
> >> > A change wo

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 typo, it should have been:

AFAIK we don't *have* the solution *implemented* atm.

--
Marek

On čtvrtek 25. května 2017 11:49:24 CEST Marek Hulán wrote:
> 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 <http://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
> > > 
> > > mailto:sebast...@validcode.me>> 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
> > > <https://github.com/theforeman/foreman-docker/pull/189>
> > > [2] https://github.com/theforeman/rfcs/pull/18
> > > <https://github.com/theforeman/rfcs/pull/18>
> > > [3] https://github.com/jlsherrill/foreman_http_proxies
> > > <https://github.com/jlsherrill/foreman_http_proxies>
> > > 
> > > On Thu

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
> > 
> > mailto:sebast...@validcode.me>> 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 to be a standard,
> >  

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 foreman-dev+unsubscr...@googlegroups.com.
> > For more 

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&search=0x7A92D6DD38D6DE30
> > Keybase: https://keybase.io/elobato


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

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 19:12:32 CEST Bryan Kearney wrote:
> On 04/12/2017 09:39 AM, Marek Hulán wrote:
> > <%= 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.
> 
> What is the effort to make this a user driven setting?
> -- bk

I could imagine that as "easy", otoh I'd like to avoid adding more options 
just because we're not sure. It's not critical I think. If we chose wrong 
format, I'm happy to modify it in next version. Once we have it consistent, 
it's easy to grep and change everywhere.

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

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
> >> > 
> >> > --
> >> > You received this message because you are subscribed to the Google
> 

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 "foreman-dev" group.
> > 
> > >> To unsubscribe from this group and stop receiving emails from it, send
> > 
> > an email to foreman-dev+uns

Re: [foreman-dev] Retire the RFC repo?

[Marek Hulán]

On úterý 28. března 2017 13:38:31 CEST Ewoud Kohl van Wijngaarden wrote:
> On Tue, Mar 21, 2017 at 03:39:45PM +, Greg Sutcliffe wrote:
> > I've been meaning to reply to this for about a week, sorry for the delay.
> > This is a topic I've been thinking about for a *long* time, so apologies
> > for the long thread :P
> 
> Let me be even later to the party.
> 
> > I think there's two issues here. One is *how* to have the discussion, and
> > the other is how to *end* the discussion. From the comments so far, it
> > seems we're still somewhat split on point 1, but we're all agreed we need
> > to find a solution to point 2. As such, I'm only going to discuss point
> > 2, as that's where we currently struggle.
> 
> While I agree that we need a better way to end discussions, I think that
> on point 1 we can improve as well. To me it feels like we lack
> visibility. It has been suggested to move back to the mailing list since
> that has more visibility. Others have suggested discussions on github
> are easier to read back. I'd suggest that we adopt the github bot to
> notify the ML of certain events. Some things I can think of are created,
> reached impasse, closed or merged. For reached impasse we could use a
> label or [impasse]. A timer could also work.

I like this idea a lot

--
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] 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] Retire the RFC repo?

[Marek Hulán]

On pondělí 13. března 2017 9:44:12 CET Lukas Zapletal wrote:
> >some design decisions are still being made without going through the RFC
> >process, either by mailing list discussions or by people just creating PRs
> >without any prior discussion.
> I've seen this several times particularly in Smart Proxy repo where
> some design changes were part of regular PRs without proper
> discussion. To give an example, dependency injection framework was
> introduced as a Puppet 4 PR and this change turned things upside down
> in initialization phase. The sad thing about this one is I executed
> unit tests once for this change locally to see if it fixed random
> failures on my dev setup. Since the PR was entitled simply Puppet, I
> just made a comment without reading discussion or code. I am bringing
> it here because I think Smart Proxy (and larger plugins) are also
> subject for RFCs.
> 
> I have a proposal, let's retire RFC github repo and simply fallback to
> mailing list but with [RFC] prefix so everyone is aware this is
> possible design change, refactoring or larger proposal that is at
> least worth reading. This should definitely not be annoying for anyone
> to at least inform about intentions, motivation, reasoning and overall
> design.

Works for me

> I don't think we need any kind of design documents, but short
> description with a place for discussion before code is actually is
> written is a good thing to have.

We can always fallback to pad/wiki/google docs/rfc repo when it's needed. Most 
of the time, it's not.

--
Marek

> 
> On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker  wrote:
> > Hello,
> > 
> > About a year ago, we decided to try using a new system for discussing
> > design decisions prior to making changes, by creating a repo for RFCs
> > [1]. Part of the problem was that when discussing on the mailing list,
> > discussions tended to die out without a resolution, and eventually
> > whoever wrote the code made the decision (or not).
> > Since then, there have been about 30 proposals made in the repository. 22
> > of them are still open, most with no activity for months.
> > So I feel fairly safe to say that this change has not led to the wanted
> > result of getting decisions made faster or with more discussion. A
> > significant part of the proposals have less then 10 comments, in many
> > cases
> > all from just one or two respondents. Eventually proposals are still
> > decided on only when someone goes ahead, writes the code and gets it
> > merged. This has also led to some discussions taking place without all of
> > the developers even knowing about them, as it would seem most don't
> > follow that repo regularly, leading to repeated discussions when a PR is
> > created. In addition, some design decisions are still being made without
> > going through the RFC process, either by mailing list discussions or by
> > people just creating PRs without any prior discussion.
> > 
> > I'm not sure what we can do to increase peoples' involvement in these
> > discussions, nor what would be a better way of making design decisions,
> > but
> > let's try to figure it out since this attempt has not worked out as
> > expected in my opinion.
> > 
> > [1] original discussion -
> > https://groups.google.com/forum/#!msg/foreman-dev/P9uRYV5K1Dc/xKMnzOOqDgAJ
> > 
> > --
> > 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.


-- 
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.15 branching in approximately 2 weeks

[Marek Hulán]

On pátek 10. března 2017 19:43:48 CET Daniel Lobato Garcia wrote:
> As per
> http://projects.theforeman.org/projects/foreman/wiki/Foreman_115_Schedule,
> 1.15 is due to be branched soon, in 2 weeks approximately.
> 
> Please help to make develop more stable during this process, be it through
> thorough testing, bugfixing or improving documentation.
> 
> Help with updating the manual would be appreciated, see the list of
> tasks in:
>   - https://github.com/theforeman/theforeman.org/issues/765
> 
> Some translations are nearing 100% completion, we welcome contributions
> that help finishing them for the next release:
>   - https://www.transifex.com/foreman/foreman/foreman/
> 
> If you have any critical fixes that you think should be included in 1.15
> in any of the core projects, please reply to this read to raise
> attention over them. Maintainers feel free to set the 1.15 label to
> any PR of that nature.

Hello,

thanks for the heads up. I think these two are required for 1.15

https://github.com/theforeman/foreman/pull/4320 - lock all templates we seed
https://github.com/theforeman/foreman/pull/4322 - realign templates structure

otherwise the syncing from community-templates before the release will be much 
harder.

--
Marek

> 
> Best,
> 
> --
> Daniel Lobato Garcia
> 
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
> 
> GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
> Keybase: https://keybase.io/elobato


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

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  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  wrote:
> > Timo Goebel  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.

[foreman-dev] Seeding templates overrides custom changes - should we lock templates we ship?

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

Re: [foreman-dev] Re: showing the hidden "Select Action" button on all hosts page

[Marek Hulán]

Hello,

I also think the button should be displayed even without selecting any item.

--
Marek

On středa 1. února 2017 12:48:10 CET Roxanne Hoover wrote:
> Tom,
> 
> I agree and would add that the Select Actions button on the All Hosts page
> is the correct styling of the button.
> 
> On Wed, Feb 1, 2017 at 12:33 PM, Tom McKay  wrote:
> > This has been nack'ed in the past but could we always show the "Select
> > Action" button on the all hosts page?
> > 
> > Currently this hidden button does not appear until one or more of the host
> > checkboxes are selected in the full list. It is very common for users that
> > have enabled orgs/locs to be confused about where to find the "Assign
> > Organization" and "Assign Location" actions. This is further confused by
> > the hosts edit page where the org/loc is grayed out and uneditable.
> > 
> > My suggestion would be to always show the Select Action button and have
> > the individual entries in that list be grayed out.
> > 
> > I'm attaching images of the content hosts page for an example. I think the
> > button title on this page should be "Select Action" and not be the first
> > entry in the list ("Change Host Collection"). The button is also disabled
> > which makes the entries in the list undiscoverable and I would suggest
> > changing 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] 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 permission, rex per

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

[Marek Hulán]

On úterý 17. ledna 2017 10:57:26 CET Marek Hulán wrote:
> Thanks for the feedback, I opened a PR at [1]
> 
> [1] https://github.com/theforeman/community-templates/pull/344

And the PR was merged. Next steps I plan to look at soon:
* update templates in core and rethink if we need to list templates explicitly
* update metadata in all tempaltes so we could fully rely on them during 
import/seed

--
Marek

> 
> --
> Marek
> 
> On pátek 25. listopadu 2016 15:40:53 CET Marek Hulán wrote:
> > Hello foreman devs,
> > 
> > As I demonstrated on last community demo [1] templates can be now easily
> > exported from Foreman. I also mentioned that I'm working [2] on
> > foreman_templates feature to easily export all templates to a given git
> > repo. Since the plugin can be used with any git repo, not just the
> > community- templates [3] one, I'd like to standardize the format of such
> > repository.
> > 
> > When we export templates from Foreman, we can only use template attributes
> > to determine the resulting path in the repo. First obvious idea is to name
> > the template file according to it's name in Foreman. That's probably not
> > enough since it wold result in one directory mixing all partition tables,
> > provisioning templates and job templates. So I came up with structure like
> > $template_type/$name. For better look and feel of what it means, you can
> > see it in one of my branches [4].
> > 
> > Currently we also separate provisioning templates into more directories. I
> > don't think the rule is well defined today. I think we could separate it
> > per template kind. Again you can see this demonstrated in another branch
> > at [5]. It applies only to provisioning templates, other types don't have
> > template kind attribute.
> > 
> > Please share your ideas for other structuring or which of schema mentioned
> > above you find better. The level of nesting does not matter from technical
> > point of view but I think 2 or 3 directories is the limit.
> > 
> > The ultimate goal of making foreman_templates exporting compatible with
> > community-templates is making sharing of user changes easy, in fact just a
> > matter of opening PR from the forked repo. Another nice benefit would be
> > that future changes in metadata, e.g. adding organizations and locations
> > keys would be much easier, we'd just reexport all templates from Foreman
> > with updated export code.
> > 
> > Since we now have metadata as a part of each template we could also
> > improve
> > seeding to avoid hard coding the list in seed files [6]
> > 
> > [1] https://www.youtube.com/watch?v=M0-3x8AUfFQ
> > [2] https://github.com/theforeman/foreman_templates/pull/36
> > [3] https://github.com/theforeman/community-templates
> > [4] https://github.com/ares/community-templates/tree/develop_kind_only
> > [5]
> > https://github.com/ares/community-templates/tree/develop_kind_and_subkind
> > [6]
> > https://github.com/theforeman/foreman/blob/develop/db/seeds.d/07-provision
> > i
> > ng_templates.rb#L21-L94
> > 
> > Thanks for all 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] 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 foreman-dev+unsubscr...@googlegroups.com.
> > For more options, visit https:

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

[Marek Hulán]

On čtvrtek 19. ledna 2017 8:44:59 CET Lukas Zapletal wrote:
> > 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
> 
> The price for that is too high in my eyes. I think these roles and
> permissions should be strictly separated for now and forever and we
> need to come up with different approach of handling that. What I like
> the best is a help text, better documentation and renaming the core
> roles to something that is more obvious.
> 
> Allowing plugins to modify core roles will end up with a mess that is
> very difficult to clean! Both adding and deleting permissions for
> existing roles during upgrades is very challenging, we usually want to
> tell administrators "hey, danger ahead, during upgrade all these users
> will get/lost some permissions" so it's a dilemma to do this via
> migration/seed or explicitly ask the user to do the change in upgrade
> notes. When reviewing these changes, we need to be careful and we are
> doing great job in core, but I wonder what happens if we open the
> doors to any plugin to basically play around with the two most
> important roles in the application.

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.

Currently we don't support plugin uninstallation, when we do we'll likely have 
a tool to say which permission should be removed.

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.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1304608

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

[Marek Hulán]

Thanks for the feedback, I opened a PR at [1]

[1] https://github.com/theforeman/community-templates/pull/344

--
Marek

On pátek 25. listopadu 2016 15:40:53 CET Marek Hulán wrote:
> Hello foreman devs,
> 
> As I demonstrated on last community demo [1] templates can be now easily
> exported from Foreman. I also mentioned that I'm working [2] on
> foreman_templates feature to easily export all templates to a given git
> repo. Since the plugin can be used with any git repo, not just the
> community- templates [3] one, I'd like to standardize the format of such
> repository.
> 
> When we export templates from Foreman, we can only use template attributes
> to determine the resulting path in the repo. First obvious idea is to name
> the template file according to it's name in Foreman. That's probably not
> enough since it wold result in one directory mixing all partition tables,
> provisioning templates and job templates. So I came up with structure like
> $template_type/$name. For better look and feel of what it means, you can
> see it in one of my branches [4].
> 
> Currently we also separate provisioning templates into more directories. I
> don't think the rule is well defined today. I think we could separate it per
> template kind. Again you can see this demonstrated in another branch at
> [5]. It applies only to provisioning templates, other types don't have
> template kind attribute.
> 
> Please share your ideas for other structuring or which of schema mentioned
> above you find better. The level of nesting does not matter from technical
> point of view but I think 2 or 3 directories is the limit.
> 
> The ultimate goal of making foreman_templates exporting compatible with
> community-templates is making sharing of user changes easy, in fact just a
> matter of opening PR from the forked repo. Another nice benefit would be
> that future changes in metadata, e.g. adding organizations and locations
> keys would be much easier, we'd just reexport all templates from Foreman
> with updated export code.
> 
> Since we now have metadata as a part of each template we could also improve
> seeding to avoid hard coding the list in seed files [6]
> 
> [1] https://www.youtube.com/watch?v=M0-3x8AUfFQ
> [2] https://github.com/theforeman/foreman_templates/pull/36
> [3] https://github.com/theforeman/community-templates
> [4] https://github.com/ares/community-templates/tree/develop_kind_only
> [5]
> https://github.com/ares/community-templates/tree/develop_kind_and_subkind
> [6]
> https://github.com/theforeman/foreman/blob/develop/db/seeds.d/07-provisioni
> ng_templates.rb#L21-L94
> 
> Thanks for all 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] 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" 
> > 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" 
> > > > 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.