Re: [foreman-dev] Nominating additional maintainers in foreman-core

[Marek Hulan]

+1 +1

--
Marek


On December 6, 2017 3:14:28 PM Ohad Levy  wrote:


On Dec 6, 2017 7:41 AM, "Tomer Brisker"  wrote:

Hello,
?As many of you may have noticed, foreman-core open PR? count has been in
the area of 100-110 for most of the last few months. There are only a few
people with merge access that actively review PRs, so that the time it
takes for changes to be accepted can take long. I would like to propose
granting merge access to two more members of the community:

Shimon Shtein - has 75 merged commits [1] and has taken part in the reviews
of 64 merged commits[2].
Michael Moll - has 71 merged commits [3] and has taken part in the reviews
of 130 merged commits[4]. He is also already a long time maintainer of
several of our other repos and has proven to be a responsible maintainer.

Please send +1/-1 either to the list or to me in private if you prefer.
Per our process, unless I receive any objections within a week, I will
request one of the organization owners to grant them access.


+1 to both :)


[1] https://github.com/theforeman/foreman/pulls?q=is%3Apr+
author%3Ashimshtein+is%3Aclosed
[2] https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93&;
q=is%3Apr+-author%3Ashimshtein+commenter%3Ashimshtein+is%3Aclosed+
?[3] https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93&;
q=is%3Apr+author%3Ammoll+is%3Aclosed+
[4]? https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93&;
q=is%3Apr+-author%3Ammoll+commenter%3Ammoll+is%3Aclosed+

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



--
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] RFC: File audit for template rendering

[Marek Hulan]

I like this.

I agree the renderred template should not be stored along audit records we 
have today, it does not represent any data change. Also it would be a lot 
of data in our db and would make searching of other audit records hard. 
Having long kickstart files in log files is neither a good idea.


One small comment, Foreman must remain operational if directory can't be 
written to and a directory must be configurable (developer setups). The 
only downside is related to HA Foreman setups. Users must share the dir 
among all Foreman instances.


We should probably limit this to provisioning templates and partition 
tables only in terms of templates rendering. Job templates can grow 
rapidly, thousands of files per one invocation. The job template result is 
different for each host.


Btw this would be also great for host classification auditing. That answers 
the question, what parameter values were available for the host when 
ENC/info method was called during provisioning.


It'd also be great if foreman-debug would be gathering this, but I suppose 
that's already on your radar.


--
Marek


On December 5, 2017 6:02:14 PM Lukas Zapletal  wrote:


Hello,

Foreman does have a nice audit trail for many operations, what's
missing is ability to find how a template (e.g. kickstart) was
rendered. Storing whole template text in audit table is probably not
the best thing to do, production.log is also not a good fit, so here
is a proposal.

I want to create a small API called File audit (*) with ability to
store arbitrary files into
/var/log/foreman/file_audit/id/text-timestamp where "id" is record id
(or multiple ids concatenated with dots), "text" is arbitrary alphanum
text and "timestamp" is unix epoch number. Example:

/var/log/foreman/file_audit/1.33.7/my.host.lan-pxelinux-1512492603

That API will be used to store contents of all templates rendered, so
users can easily go "back in time" and see how templates are being
rendered. The directory would be root-only reading and files will be
created with restricted permissions (foreman user rw only). On system
with SELinux, security would be more tightened allowing writing only
to foreman_t domain and reading to nobody. For the example above, this
would mean:

1.33.7/my.host.lan-pxelinux-1512492603

1 - file audit type (static list, 1 stands for "template audit entry")
33 - host id
7 - template id
my.host.lan-pxelinux - extra data so users can work and search from command 
line

1512492603 - UNIX epoch timestamp

Everytime new record is added, a log entry is created into
production.log containing file path. By default, there will be a cron
job deleting all files older than one month. In documentation, we will
ask users to rsync the directory to different location if long-term
archival is needed.

This API could be used for other audit logging, for example when user
uploads a manifest ZIP file in katello or new version of RPM/Puppet
file. This will be the first step to improve audit around templates,
later on we can create a plugin showing the data in audit/host pages
if needed. But in the first phase, administrators could easily
search/grep/diff those files when necessary.

(*) if you have a better name, please do propose

--
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] Kanban tools and redmine

[Marek Hulan]

There's one tool for redmine and kanboard already [1], patches welcome :-)

[1] https://github.com/ares/kansync

--
Marek


On November 30, 2017 18:53:17 Walden Raines  wrote:


So for me, I'd prefer to keep using what I need, redmine and some board

and
not trying to combine both together.

I think that is a fair point.

It would be nice if we had a way to import redmine issues into a board and
have them move themselves to in progress, ready for review, done, etc. as
the state changed on redmine.  I woul djust like to find some way to
minimize manual tracking.  Perhaps we could write some integrations to
trello/kanboard to cut down on the bookkeeping.

Cheers,
Walden

On Thu, Nov 30, 2017 at 4:27 AM, Marek Hulán  wrote:


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
> 

Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.

[Marek Hulan]

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.


--
Marek

--
Marek



On November 12, 2017 19:36:14 ssht...@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 be very difficult
to ensure a good UI since some other plugin could just put whatever they
want wherever in the UI.

Thanks,
Walden



On Tue, Nov 7, 2017 at 5:38 AM, Timo Goebel > wrote:


I have been playing with Facets the last few weeks and must say, that
they are really great. It's pretty easy to add dedicated functionality to
the host model and I want to use that for some of my plugins (Omaha,
Monitoring, something new, ...).
Everything is great so far except for the missing UI hooks Shim mentions.

What I want to do are mostly easy thing, like adding a new tab to the
host form or host show page. Currently, the only way to do this is using
deface.
But this feels pretty hacky to me and isn't good to maintain. I'd really
appreciate if there were easy and tested hooks for common areas like the
host show page.

In my opinion, we are already too late on finishing the facets (and
Pagelets) integration. Personally, I don't have a strong opinion on either
option. But prefer the second approach as well.

In regards to widening the feature gap for a host ux redesign: We have to
provide extension points anyways. The Foreman community gains a lot of
value from the rich plugin ecosystem and the possibility to extend Foreman
fairly easy.
When we redo the host ux pages, we have to provide extension points. This
is not a nice-to-have feature, but a must-have in my opinion.

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

[Marek Hulan]

1. Make the UI flexible - create enough extension points in the form/wizard 
so each facet will get the opportunity to be shown everywhere.
2. Reflect the different management aspects to the user in the UI - create 
a dedicated block for each facet, where it will get opportunity to show its 
own data


I lean towards 2 but I think we need combination of both. The example 
you've mentioned about puppet/salt/chef is a good example of 1. Config mgmt 
is shared property, e.g. the facts handling is the same and at some points, 
we need an extension point, e.g. in host form or detail page, I'd like to 
provide chef environment or some specific fact as a regular host attribute, 
not isolated in chef facet area.


But where it make sense, 2 sounds as a good approach.

--
Marek


On November 7, 2017 10:45:24 ssht...@redhat.com wrote:



I want to start a discussion about the future UX of Host creation/edit form
from facets perspective.

Let's start with a bit more explanation of facets and how I see the future
of host data model.
First of all I'll stat with the purpose of facets - they try to solve a
couple of problems: the ability to mix and match different aspects in
host's lifecycle - to get users the power to decide which parts of
lifecycle should be managed for this host. For example, some hosts should
be present in Foreman only as a book keeping record (nothing should be
managed by the foreman), but some other hosts will manage only the
provisioning part and for the third group of hosts the user wants to manage
only the configuration. Facets also solve the plugability problem - each
facet can belong to a different plugin, which will make foreman models more
flexible in the future. Another problem that facets solve is choice of
plugins with overlapping responsibilities. For example salt, chef and
puppet are competing for the same configuration management space, and the
user should be able to choose which one he wants to use, or even choose
some of them, and manage part of hosts using one plugin, while managing
other hosts using the other.
In my vision core foreman host is a bare book keeping record, while every
"manageable" aspect of hosts resides in a dedicated facet.

All this introduction was about the model - the data part of the object.
Now, about the UI part. As I can see there are two main options:
1. Make the UI flexible - create enough extension points in the form/wizard
so each facet will get the opportunity to be shown everywhere.
2. Reflect the different management aspects to the user in the UI - create
a dedicated block for each facet, where it will get opportunity to show its
own data.

Personally I incline to the second approach - for me it gets clearer for
both developers and the user where to put and expect each type of data.
Especially since I don't see too much overlapping between facets.

I would like to see more thoughts about the subject from both users and UX
team.
I did an attempt to implement the second approach in our current UI in this
PR , although before I
merge it, I want to make sure that I am not widening the feature gap for
host form redesign.

I will be more than happy to answer any questions, so feel free to ask me
anything.

Shim, AKA the facets guy :)

--
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] Discourse - summary of week 1

[Marek Hulan]

Please count me into Ivan category. Now with new mail experience, I want to 
have some time for reevaluation. If that feels as mailing list and can be 
used the same way, with forcing me to open webui just to use advanced 
features, such as poll or syntax highlight, I would lean more to pro side. 
But trial period would be prefered anyway.


--
Marek


On November 9, 2017 15:50:24 Greg Sutcliffe  wrote:


Hi all,

If you've been avoiding the Discourse mega-thread because you're super
busy, I hope this summary will be useful. I'll keep it short(ish) and
still represent eveyone accurately (I hope).

TLDR: cautiously positive overall, some great debate, next steps at the
end of this mail

Some stats so far:

* 14 people have recovered password & logged in
* 8 topics, 41 posts to Testing Area
* 218 emails sent (that escalated fast, but can do 50k/month for free)
* For the foreman-dev discussion:
  * 8 people involved
  * 35 replies (20 mine)

So that's 7 people who've tried the UI but haven't commented yet, and a
whole load more who haven't looked yet.

On the discussion, I see (I hope this is fair!):

* 3 in favour (myself, Eric, Neil)
* 2 cautious (Martin, Ewoud)
* 1 cautious, with a change to implementation (Ivan)
* 1 against, countering with another solution (Lukas)
* 1 neutral, just asking a question (Andrew)

Eric is in favour of better communication tools. Neil supports the
argument that there are users being turned away by mailing lists. Ewoud
made the point that sometimes we have to accept changes to workflow to
benefit the community.

Martin & Ewoud both made good points about plain email being second
class. The initial STMP provider was causing issues, we've moved to
Mailgun and all seems fine with email now, see [1] for a threaded Mutt
example.

Lukas was clear that he's against a forum, and proposed a move to GNU
Mailman plus Hyperkitty archive viewer. There was some good debate about
the features/benefits/drawbacks of forums vs mailing lists here, so I
encourage you to read those posts if you're undecided.

Ivan seemed happier to try the forum out, but proposes running
side-by-side with the mailing list for a trial period. My concern here
was how to construct such a fair trial - again, worth a read. He also
suggested using a forum for -users and a list for -dev. I agreed that's
an option, but ideally we'd have everyone on the same platform.

# What next?

Most of the pushback seems to be on mailing list mode (entirely fair)
but the root cause for that has been identified and fixed (it wasn't
Discourse). Mailing list mode really does feel the same to me as Google
Groups now (there's even a List-ID header to filter on), and I hope that
feeling will be the same for others.

Overall there seems enough support to working on this, but we have no
need to rush to a conclusion. While we continue tests, I will now spend
a little time on styling and setting it up to look like how we might
*actually* use it:

* I've changed the default view back to "Categories" from "Latest"
  * I think it's more informative for newcomers, but let me know your
preference.
* The imported lists are locked (view-only) so that we don't give the
  idea that posts here go back to the mailing lists. I'll also make:
  * A "Support" category (i.e foreman-users-alike)
  * A "Development" category (i.e. foreman-dev-alike)
  * An "Events" category for demos, conferences etc.
* These will get inbound email addresses once Ohad is back next week.
* I'll also try adding a template to the Support category, since
  templated posts was something that came up in an offline discussion.

Testing Area will stay, it may as well for now. Feel free to play around
in any of the boards. Other suggestions for things people would like to
try are welcome!

Discourse has many plugins[2] so I *may* try adding a few that could be
useful. I don't want UI clutter, but integration with other systems is
often useful. If you browse and see any good ones, let me know.

We do need more traffic. Those who haven't activated their account yet,
please do! Testing of @mentions, joining groups and using @group
mentions, and trying the templates (once done) is especially welcome.

[1] https://gist.github.com/ekohl/60f3b5bdc6559800835b9f2ea0df13c1
[2] https://meta.discourse.org/c/plugin

--
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] Regular Foreman-core issue triage?

[Marek Hulan]

I'd join regularly, after few years for which I receive all notifications 
from redmine, I can confirm there are bugs without much attention.


If we won't have representatives from all areas, we might need some tooling 
to ping people in redmine tickets. Again, after few years, I can tell that 
mentioning name in comment does not always work. There used to be a 
question plugin which works similarly as needinfo in BZ. Perhaps we could 
install it?


Thanks Greg for bringing this up

--
Marek


On November 8, 2017 16:28:59 Greg Sutcliffe  wrote:


So on IRC the idea of a regular issue triage for core issues in redmine
came up, and I think it's a pretty good idea.

I think we'd want to do this on a public stream (but recorded, I think),
and then anyone interested can join. We'd need a minimum number of
people involved to make it work, I guess we're looking at anyone with
commit / interest in foreman core itself. Proxy, plugins (and possibly
the installer) are out of scope, at least to start with.

Is anyone interested in participating in this? When should we hold it?
I'm guessing around lunch-time GMT if we want maximum coverage, or we
could alternate EMEA-friendly/US-East-friendly time slots? Avoid
Thursday if you can as demos and other recorded content tend to happen
then ;)

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] FactoryGirl renamed to FactoryBot - plugin maintainer action needed

[Marek Hulan]

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.

Re: [foreman-dev] Merge permissions to foreman-packaging

[Marek Hulan]

+1, I remember you've helped me many times.

--
Marek


On October 23, 2017 6:16:48 PM Ewoud Kohl van Wijngaarden 
 wrote:



Hello all,

To get more involved in packaging I'd like to request merge access to
foreman-packaging. I've already been monitoring PRs and submitted
various patches[1][2].

Regards,
Ewoud Kohl van Wijngaarden

[1]: 
https://github.com/theforeman/foreman-packaging/commits/rpm/develop?author=ekohl
[2]: 
https://github.com/theforeman/foreman-packaging/commits/deb/develop?author=ekohl


--
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] Found In Version Katello Redmine custom field

[Marek Hulan]

I would love to see the issue template, especially the reproducing steps 
would help. Also installed plugins would help in some cases.


--
Marek


On October 18, 2017 21:01:06 Justin Sherrill  wrote:


I like this idea, and there seems to be a plugin already to do it:
http://www.redmine.org/plugins/redmine_issue_templates


On 10/18/2017 02:55 PM, Tom McKay wrote:

Perhaps using a template for new issues. Here is an example from github:
https://github.com/openshift/origin/issues/new

[provide a description of the issue]

# Version
[provide output of the `openshift version` or `oc version` command]

# Steps To Reproduce
1. [step 1]
2. [step 2]

# Current Result

# Expected Result

# Additional Information
[try to run `$ oc adm diagnostics` (or `oadm diagnostics`) command if
possible]
[if you are reporting issue related to builds, provide build logs with
`BUILD_LOGLEVEL=5`]
[consider attaching output of the `$ oc get all -o json -n
` command to the issue]
[visit https://docs.openshift.org/latest/welcome/index.html]


On Mon, Oct 16, 2017 at 1:47 PM, Ewoud Kohl van Wijngaarden
mailto:ew...@kohlvanwijngaarden.nl>> wrote:

https://projects.theforeman.org/projects/foreman/issues/new
 has
this, but I'm not sure we can rename the Release field since it's
part of the Redmine Backlogs plugin though my memory is fuzzy
here. I think someone with admin rights on Redmine can say more
about the practicalities but the idea makes a lot of sense to me.

On Mon, Oct 16, 2017 at 01:38:18PM -0400, John Mitsch wrote:

+1

If we do this, we should clarify that the current "version"
field is used
for releases by calling it "target version" or something similar.

John Mitsch
Red Hat Engineering
(860)-967-7285 
irc: jomitsch

On Mon, Oct 16, 2017 at 10:18 AM, Andrew Kofink
mailto:akof...@redhat.com>> wrote:

RFC:

Because Katello is a nested project under Foreman in
Redmine, we can only
see Foreman versions in the "version" field. It would be
great to have a
custom text box field "Found In Version" that bug
reporters can provide the
exact RPM they installed to see the issue.

Let me know if you would find this useful.


--
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] Re: Sharing and idea: VMWare VIX instead of DHCP for vCenter VM's provisioning

[Marek Hulan]

Hello

Could you please list things that VIX allows and can't be achieved with 
current fog adapter? I'd like to avoid supporting 2 ways to talk to vmware 
and I don't think it makes sense to rewrite what we have unless there are 
some big benefits.


Thank you

--
Marek


On October 16, 2017 23:39:54 chrob...@redhat.com wrote:


+1 to supporting this, I could see a lot of use for this downstream as well
with so many customers running VMware.

On Monday, October 16, 2017 at 2:40:56 PM UTC-4, Evgeny Vasilchenko wrote:


I'd like to share an idea for provisioning of VMware guest VM's with
Foreman.

The idea required programming new type of Foreman proxy - unfortunately, I
neither have time or enough skills for that.

*The goal:*

   - Allow configuration of Linux (and maybe Windows) VM network
   interfaces with VMWare VIX's API
    instead of DHCP

*Facts:*

   - VMWare offers a free VM management API called *VIX* -
   https://blogs.vmware.com/vix/2008/07/what-is-vix-and.html
  - *VIX is an API that lets you programmatically control the
  products that host VMware VMs, and control the VMs themselves.*
 - it works with many VMWare products including vCenter
  -
- VIX package can be installed on both

*Linux and Windows *
   - VIX has a wrapper utility called *vmrun* (
   https://www.vmware.com/support/developer/vix-api/vix112_vmrun_command.pdf)
   which offers a CLI for controlling VM's running - e.g. starting, stopping,
   pausing, deleting, etc...

   - vmrun can be installed on a *Foreman Smart-Proxy* (AKA Sat6 capsule)
   *host* and
  - run any command or script *INSIDE* of a guest VM running on a
  vCenter computing resource - i

*.e. it can configure whatever, including network interfaces. *
   - in order to run something inside of VM - vmrun only need to
   know (beside of vCenter credentials of course)
   - *path to .VMX file* (already known after VM provisioning)
- guest OS username (i.e. root, administrator) and password
 - command line or script name to be executed

In fact VIX API and vmrun can do way more that this - I feel it simply
must be integrated into Foreman Proxy.
I've been using it for various VCenter related automation tasks and like
it's versatility and power.

Any ideas?






--
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] [POC] Automatic inspection of user-created provisioning templates

[Marek Hulan]

Thanks Shim, it looks very promising. Couple of thoughts for future. I 
think it'd be great if it was checking community-templates PRs. I wonder if 
we should integrate it with core or rather foreman_templates (or merge 
templates to core). Since it should probably be interactive and users 
should decide what changes they want to apply, some UI wizard will be 
needed, which is why I think it does not belong to foreman-maintain. and as 
always, while the tool is great, we need to write actual cops too.


--
Marek

Sent with AquaMail for Android
http://www.aqua-mail.com


On August 14, 2017 15:50:06 Ewoud Kohl van Wijngaarden 
 wrote:



On Mon, Aug 14, 2017 at 04:29:01AM -0700, ssht...@redhat.com wrote:

TL;DR: I have developed a way to scan any template and see if there are
suspicious/incorrect code patterns in them, so the templates will remain
valid even after foreman code changes.

Recently I have started to think about user created templates and foreman
upgrades.

When user upgrades foreman, hist default templates get upgraded by the
installer/migrations, but templates created by the user (both cloned and
from scratch) are not touched.
This could lead to invalid templates and broken provisioning functionality
for the user.
Good example for this would be the change

from calling to <%= foreman_url %> to <%= foreman_url('built') %>

I was looking for a way to inspect any template, in order to identify
problematic code as soon as the system is upgraded.

I came down to a solution based on rubocop - it's already analyzing source
files for patterns.
I have created a POC that analyzes a template written to a file, and
presents the resulting errors as regular rubocop (clang style).
All source codes are available as gist:
https://gist.github.com/ShimShtein/341b746f15826261053e97c2f435ff1a

Small explanation for the gist:

Entry point: inspect_template.rb
Usage:
Put everything from the gist to a single folder and execute:


inspect_template /path/to/template_source.erb


This script aggregates all the parts that are needed to create the
clang-like output.

The process:

  1. Strip all non-ruby text from the template. This is done by
  erb_strip.rb. It turns everything that is not a ruby code into spaces, so
  the ruby code remains in the same places as it was in the original file.
  2. Run rubocop with custom rules and erb monkey patch and produce a json
  report
 1. foreman_callback_cop.rb custom rule file. The most interesting
 line is "def_node_matcher :foreman_url_call?, '(send nil :foreman_url)
 '". Here you define which pattern to look for in the AST, in our case
 we are looking for calls (send) for foreman_url method without parameters.
 2. foreman_erb_monkey_patch.rb file: Patches rubocop engine to treat
 *.erb files as source files and not skip them.
  3. Process the resulting json to convert it to clang style highlighting.

Possible usages:

  - Scanning all template after foreman upgrade to see that they are still
  valid.
  - Linting a template while while editing.
  - Using rubocop's autocorrect feature to automatically fix offences
  found by this process.

Long shot: we can create custom rules to inspect code for our plugins too,
especially if we start creating custom rules in rubocop.

I am interested in comments, opinions and usages to see how to proceed from
here.


I think this is great and it should already include deprecations so
users get a heads up something changed. Otherwise users are not aware of
it and continue writing the deprecated styles. Auto-fix is fine but
having them review it can also be a teaching tool.

Another thing to consider is automatically referring to the correct
documentation for functions.

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

[Marek Hulan]

I don't think it causes any problems. I don't see the reason why the whole 
commit should be reverted. If something then perhaps deprecation warning 
could be removed. I'd still prefer communuty-templates using macros instead 
of internal objects.


--
Marek

Odesláno pomocí AquaMail pro Android
http://www.aqua-mail.com


Dne 13. ledna 2017 18:27:13 "Sean O'Keeffe"  napsal:


Maybe the best thing to do for now it to revert it and send a PR to the RFC
repo for a proper discussion?

On Fri, Jan 13, 2017 at 2:26 PM, Daniel Lobato Garcia 
wrote:


On 01/12, Marek Hulán wrote:
 > >
> > > 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.

Sorry but I oppose this. Some internal objects are quite stable, in
fact people rely upon them successfully - but we break the compatibility
for apparent advantages that IMO are not worth the hassle.

@host.operatingsystem, @host.architecture, etc... and @host.params, are
very stable objects that can safely be called from templates and expect
that will work for a long time. Not only our users do it. We also relied
upon these internal objects for years.

The first community templates PRs which are 4 years old used
@host.params, @host.operatingsystem, etc.. Those are stable enough to
not warrant writing a macro for them

What we did on #16740 is basically renaming things around and deprecating
params for macros that don't do anything but calling @host.params
themselves.

I would argue for the opposite way of thinking. When we change how
these internal APIs work, we should deprecate them. If these APIs
remain stable, don't change anything as it provides no value, and brings
headaches and wastes time. Time wasted on writing this thread, on the
people who write and review PRs in the project and associated ones
(templates, the migration to new macros, fixing anything that might break,
and adding more LOC which complicate our codebase).

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

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



--
You received this message because you