#theforeman

sigh, dont hit enter

as per mhulan's comments in that ticket, any plugin using "prepend" will conflict with those using alias_method_chain

wubooo: only for transaction handling, not for "find me a thing with id 3". dynflow internaly uses sequel for manipulating execution plans

unless you're actually seeing openscap in the stacktraces, it's probably something else

gwmngilfen: seeing openscap in the stack trace

and I'm seeing openscap in the menu items, hence my shock at it being there

then I guess you have the plugin loaded, indeed, start with removing it and then figure out what installed it ;)

or sure it's not a default option, and i don't believe its a dependency of anything either

s/or/for

aruzicka: right okay that makes sense, so basically need to develop a makara equivalent for sequel?

wubooo: or implement activerecord persistence adapter for dynflow

it's a bit annoying that foreman literally can't function with both makara and remote execution

gwmngilfen: it doesn't "look" like a default option, but that said, I've not specificed it (and I've ever tried using the --no-enable option for it, and it still pops up after deployment, thats why I was wondering if it had been made standard/default and the installer options not cleaned up

ikonia: its not a default. can you reproduce on a clean host?

gwmngilfen: trying to do it at the moment

oops, quit by accident, aruzicka: , any advice on best approach?

so should /usr/share/foreman-installer/config/foreman-answers.yaml

be the correct answer file that the installer stores the answers for each time it's run

just want to clarify %100 I'm verifying the right answer fire

file

it's i/etc/ iirc, although that may be a link

thats the installer options isn't it ?

/etc/foreman-installer/scenarios.d/foreman-answers.yaml

isn't that the options that the installer presents, not the actual answers for storing

wasy enough to test

*easy

a fair point

pretty sure thats the file though

good job I asked, as I was certain it was the other way around

I'm doing the same now

yep, thats the one

interesting, you win

i enabled a plugin, and it changed from false to {}

i usually do

;)

cheat

nah, practice ;)

wottop: I'm not sure what would amount to less work

aruzicka: huh?

@aruzicka:matrix.org: wuboooooo i think it's fair to say we're weren't really considering tools like makara. Perhaps the first step would be a discussion on the mailing list about wether we should support it, and what that work might need?

gwmngilfen: thanks for the info, i'll raise a topic on the mailing list

Hey folks - got a question about smart class parameters.

I have a puppet module with: Variant[Boolean, Enum['sometimes']]. When I have it set to sometimes as a smart class parameter, I get parameter 'manage_puppetca' expects a value of type Boolean or Enum['sometimes'], got String

The override is set to String - is there another way to configure the smart class parameter override for Enum?

I tried setting an inputer validator since that is Enum-like, but it made no difference. :-D

jpavel: so you're hitting one of life's great mysteries - why is it so damn hard to send booleans in YAML

basically we have a Boolean type in Foreman just for this purpose

but ofc, you cant use that because you need strings for the Enum

however sending "true" for the other type is going to come out as a tring not a boolean

(like, thanks for that YAML)

Right. :-( I use "Boolean" where applicable - I do like the dropdown to simplify that for me so I don't fat-finger my typing

is this a home-written modue?

it is

so the easiest solution is probably to add true and false to the enum

and then use a validator in foreman to select one of those 3 values

on the puppet side you can massage the true-string into a true-boolean

not perfect, but should work i think?

I can try it and see!

the validator should mean you still get a drop-down, iirc

if you use a list style, not a regex style ofc

Actually, I got it to work - I used yaml instead of String, with the validator

thanks!!!

jpavel: ah nice

is there a good way for me to apply a small patch (in a distributable way) to my foreman installation without messing too much stuff up? I want to remove the skip_orchestration! from https://github.com/theforeman/foreman/blob/1f6a... so that my dns updates when I get puppet reports

fabianvf: i'd suggest starting a discussion (either a feature request or the mailing list) about it - I'd guess we could accept that as a Setting, and then you can contribute it upstream :)

much easier than carrying it yourself

gwmngilfen: certainly happy to contribute it upstream :) was just curious if there is a way I could do it for right now since presumably there will be a bit of a delay between proposal/submission and release

indeed. you could do it as a plugin, but for such a one-line patch that may be overkill

if you do plan to go upstream with it, then editing the file is probably ok - it's only a burden when you have many manual changes to port at upgrade time

gwmngilfen: cool, that makes sense. Should I make an issue and then submit a patch or just submit the patch and include reasoning?

all core changes need a ticket anyway, so I'd start with a "Feature" ticket, give your reasoning and that you're happy to write it.

a setting makes the most sense to me, but perhaps others will disagree