[foreman-users] Re: VMware: Can't remove NIC on VMs provisioned by Foreman

[Stefan Lasiewski]

> 2) You can try to boot the VM into BIOS and see if you can modify the 
BIOS settings, by what you experience, it should be locked though

Ah yes, this was the strange part. This part of the BIOS is locked, which 
is frustrating. Looks like the BIOS bootorder is set to "User Mode" because 
Foreman sets the bios.bootorder. This prevents the user from modifying the 
Boot Order, according to what I read 
on https://communities.vmware.com/thread/434314?start=0=0 . 

>  i think the best option is to remove the network card as a bootdevice

Last night I ended up removing both NICs from the VM and re-adding them. 
That seems to have fixed this error. On a couple hosts, but not all hosts, 
this also removed the NIC as a boot device and allowed us to re-arrange the 
boot order in the BIOS.

For the record, this looks to be http://projects.theforeman.org/issues/14160

-= Stefan


-= Stefan

On Tuesday, February 7, 2017 at 4:36:37 AM UTC-8, Erez Zarum wrote:
>
> Yes, it's also an issue when creating a VMware Image to use for 
> provisioning through Foreman, Fog (the library that is being used for 
> almost all Compute Resources) makes the first boot device as the primary 
> network interface, this allows you to "rebuild" a VMware guest that was 
> provisioned through PXE (not Image), it's the same mechanism as 
> provisioning a physical server except Foreman does not modify the BIOS 
> setting a physical host.
> The issue with using Fog (API calls) is that the setting is then being 
> written inside the guest vmx file, there are a few ways to fix it:
> 1) Modify the vmx file manually: you have to remove the VM from the 
> vCenter inventory, edit the vmx file and remove those lines (search for 
> "hdd" and you will see the bootorder lines),
> 2) You can try to boot the VM into BIOS and see if you can modify the BIOS 
> settings, by what you experience, it should be locked though
> 3) Modify the VM boot order using API calls (ruby/python/powershell/etc.)
>
> I'm not familiar with Fog but i think the best option is to remove the 
> network card as a bootdevice once the guest build status is complete and 
> enable it once you decide to rebuild it.
>
>
>
>
> On Tuesday, February 7, 2017 at 4:06:47 AM UTC+2, Stefan Lasiewski wrote:
>>
>>
>> Foreman: 1.11.4
>> VMware vSphere 6.x
>>
>> I hooked up vCenter to Foreman as a compute resource, and provisioned a 
>> dozen CentOS 7 VMs using Foreman and Network Boot. 
>>
>> Now, when I try to remove some Network interfaces on some of the hosts, 
>> vCenter complains with:
>>
>> A specified parameter was not correct: 
>> configSpec.bootOptions.bootOrder
>>
>> This looks a bit like the following RedHat/Satellite bug: 
>> https://access.redhat.com/solutions/2773751 (login required)
>>
>> Has anyone else run into this with Foreman and vSphere?
>>
>> -= Stefan
>>
>

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

[foreman-users] VMware: Can't remove NIC on VMs provisioned by Foreman

[Stefan Lasiewski]

Foreman: 1.11.4
VMware vSphere 6.x

I hooked up vCenter to Foreman as a compute resource, and provisioned a 
dozen CentOS 7 VMs using Foreman and Network Boot. 

Now, when I try to remove some Network interfaces on some of the hosts, 
vCenter complains with:

A specified parameter was not correct: configSpec.bootOptions.bootOrder

This looks a bit like the following RedHat/Satellite bug: 
https://access.redhat.com/solutions/2773751 
(login required)

Has anyone else run into this with Foreman and vSphere?

-= Stefan

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

Re: [foreman-users] Excessive looping while loading host edit page

[Stefan Lasiewski]

Chris,

I don't know about you, but this command was showing about 1500 interfaces 
for Docker named 'vethNNN':

$ hammer --output=csv host interface list --host docker0N.example.org 
|wc -l

That not right, and `ip addr show` only shows about ~25  interfaces on each 
host. I suspect that Foreman was cataloging every single Docker ephemeral 
interface that's existed on these hosts since I bought up these host a 
month ago.

To delete these by hand, I'm doing the following:

hammer --output=csv host interface list --host docker0N.example.org > 
/tmp/docker0N.int.list

grep veth /tmp/docker0N.int.list  |cut -f1 -d, |while read NID; do
echo "### $NID"
hammer --verbose host interface delete --id $NID --host 
docker0N.example.org
done

-= Stefan

On Friday, February 3, 2017 at 6:32:14 AM UTC-8, Chris Baldwin wrote:
>
> Nice, I hadn't noticed that. If that's the case, this should be a 
> non-issue for us in the long term... once we upgrade :)
>
> On Thursday, February 2, 2017 at 6:29:37 PM UTC-5, Stefan Lasiewski wrote:
>>
>> How funny. I was just looking this up also. Also running Puppet 3.8 & 
>> Foreman 1.12.x, and a dozen Docker hosts. Turns out that Foreman doesn't 
>> like 12 hosts with dozens of interfaces on each!
>>
>> Looks like this has also been fixed in Foreman 1.14. See 
>> http://projects.theforeman.org/issues/16834 , which adds 'veth*' to 
>> ignored_interface_identifiers 
>> .
>>
>> -= Stefan
>>
>> On Thursday, February 2, 2017 at 12:35:49 PM UTC-8, Chris Baldwin wrote:
>>>
>>> I think the other way would be to avoid managing the host directly. 
>>> Since we only use Foreman as an ENC, all class management could (should) be 
>>> moved to a hostgroup, therefor never having to load the NICs.
>>>
>>> On Thursday, February 2, 2017 at 3:31:08 PM UTC-5, Tomer Brisker wrote:
>>>>
>>>> A possible workaround, if you don't need to manage all of those 
>>>> interfaces in foreman, is to ignore some of them during fact import using 
>>>> the ignored_interface_identifiers setting. 
>>>> You may need to delete the host and re-run puppet for the ignored 
>>>> interfaces to be removed.
>>>>
>>>> On Thu, Feb 2, 2017 at 10:22 PM, Chris Baldwin <ooga...@gmail.com> 
>>>> wrote:
>>>>
>>>>> Huh, that's interesting. The affected hosts do have a 
>>>>> larger-than-average (10+) number of interfaces as they're docker servers, 
>>>>> which is a commonality I hadn't noticed.
>>>>>
>>>>> Do you guys need/want any other logs to help w/ the issue? Is there 
>>>>> any kind of workaround that you've found?
>>>>>
>>>>> On Thursday, February 2, 2017 at 3:12:12 PM UTC-5, Tomer Brisker wrote:
>>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> Thank you for reporting this.
>>>>>> This looks like you are hitting 
>>>>>> http://projects.theforeman.org/issues/7829 which has to do with a 
>>>>>> large number of interfaces on the host, leading to the interface partial 
>>>>>> being rendered for each interface.
>>>>>>
>>>>>> On Thu, Feb 2, 2017 at 9:50 PM, Chris Baldwin <ooga...@gmail.com> 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> My setup:
>>>>>>> * Multiple Foreman servers, all on 1.12.1
>>>>>>> * memcached shared between them
>>>>>>> * shared backend DB (psql, 9.4.5)
>>>>>>> * Foreman is a puppet 3.8 ENC only
>>>>>>>
>>>>>>> I have a reasonably large Foreman install. For some reason, some 
>>>>>>> hosts take forever to load when clicking on 'edit'. The only thing I 
>>>>>>> see in 
>>>>>>> the logs is some obscene amount of rendering messages, to the tune of 
>>>>>>> 445+ 
>>>>>>> seconds of 
>>>>>>>
>>>>>>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb 
>>>>>>> (27.1ms)
>>>>>>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb 
>>>>>>> (1.2ms)
>>>>>>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_
>>>>>>> provider_specific_form.html.erb (0.1ms)
>>>>>>> 2017-02-02 11:36:43 [app] [I]

Re: [foreman-users] Excessive looping while loading host edit page

[Stefan Lasiewski]

Can we remove the interfaces from the WebUI besides deleting the host and 
re-run puppet? Won't we lose configuration data when we delete the host 
from Foreman?

-= Stefan

On Thursday, February 2, 2017 at 3:29:37 PM UTC-8, Stefan Lasiewski wrote:
>
> How funny. I was just looking this up also. Also running Puppet 3.8 & 
> Foreman 1.12.x, and a dozen Docker hosts. Turns out that Foreman doesn't 
> like 12 hosts with dozens of interfaces on each!
>
> Looks like this has also been fixed in Foreman 1.14. See 
> http://projects.theforeman.org/issues/16834 , which adds 'veth*' to 
> ignored_interface_identifiers 
> .
>
> -= Stefan
>
> On Thursday, February 2, 2017 at 12:35:49 PM UTC-8, Chris Baldwin wrote:
>>
>> I think the other way would be to avoid managing the host directly. Since 
>> we only use Foreman as an ENC, all class management could (should) be moved 
>> to a hostgroup, therefor never having to load the NICs.
>>
>> On Thursday, February 2, 2017 at 3:31:08 PM UTC-5, Tomer Brisker wrote:
>>>
>>> A possible workaround, if you don't need to manage all of those 
>>> interfaces in foreman, is to ignore some of them during fact import using 
>>> the ignored_interface_identifiers setting. 
>>> You may need to delete the host and re-run puppet for the ignored 
>>> interfaces to be removed.
>>>
>>> On Thu, Feb 2, 2017 at 10:22 PM, Chris Baldwin <ooga...@gmail.com> 
>>> wrote:
>>>
>>>> Huh, that's interesting. The affected hosts do have a 
>>>> larger-than-average (10+) number of interfaces as they're docker servers, 
>>>> which is a commonality I hadn't noticed.
>>>>
>>>> Do you guys need/want any other logs to help w/ the issue? Is there any 
>>>> kind of workaround that you've found?
>>>>
>>>> On Thursday, February 2, 2017 at 3:12:12 PM UTC-5, Tomer Brisker wrote:
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Thank you for reporting this.
>>>>> This looks like you are hitting 
>>>>> http://projects.theforeman.org/issues/7829 which has to do with a 
>>>>> large number of interfaces on the host, leading to the interface partial 
>>>>> being rendered for each interface.
>>>>>
>>>>> On Thu, Feb 2, 2017 at 9:50 PM, Chris Baldwin <ooga...@gmail.com> 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> My setup:
>>>>>> * Multiple Foreman servers, all on 1.12.1
>>>>>> * memcached shared between them
>>>>>> * shared backend DB (psql, 9.4.5)
>>>>>> * Foreman is a puppet 3.8 ENC only
>>>>>>
>>>>>> I have a reasonably large Foreman install. For some reason, some 
>>>>>> hosts take forever to load when clicking on 'edit'. The only thing I see 
>>>>>> in 
>>>>>> the logs is some obscene amount of rendering messages, to the tune of 
>>>>>> 445+ 
>>>>>> seconds of 
>>>>>>
>>>>>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb 
>>>>>> (27.1ms)
>>>>>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb 
>>>>>> (1.2ms)
>>>>>> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_
>>>>>> provider_specific_form.html.erb (0.1ms)
>>>>>> 2017-02-02 11:36:43 [app] [I]   Rendered 
>>>>>> nic/manageds/_managed.html.erb (29.9ms)
>>>>>>
>>>>>> over and over. 
>>>>>>
>>>>>> I have a few questions about this:
>>>>>> * I got this info from debug. What else can I look at to get more 
>>>>>> information?
>>>>>> * Why is it rendering the same four items over and over? 
>>>>>> * I actually deleted the host from Foreman and re-ran puppet, that 
>>>>>> seemed to fix the issue temporarily. However, I don't understand *why* 
>>>>>> that 
>>>>>> made a difference. Can someone shed some light on this?
>>>>>>
>>>>>> -Chris (oogs/oogs_/oogs_werk on IRC)
>>>>>>
>>>>>> This log is for a good host. In a bad host, add about 100 times the 
>>>>>> stanzas I listed above.
>>>>>>
>>>>>> 2017-02-02 11:36:42 [app] [I] Started GET "/hosts/
>>>>>&g

Re: [foreman-users] Excessive looping while loading host edit page

[Stefan Lasiewski]

How funny. I was just looking this up also. Also running Puppet 3.8 & 
Foreman 1.12.x, and a dozen Docker hosts. Turns out that Foreman doesn't 
like 12 hosts with dozens of interfaces on each!

Looks like this has also been fixed in Foreman 1.14. 
See http://projects.theforeman.org/issues/16834 , which adds 'veth*' to 
ignored_interface_identifiers 
.

-= Stefan

On Thursday, February 2, 2017 at 12:35:49 PM UTC-8, Chris Baldwin wrote:
>
> I think the other way would be to avoid managing the host directly. Since 
> we only use Foreman as an ENC, all class management could (should) be moved 
> to a hostgroup, therefor never having to load the NICs.
>
> On Thursday, February 2, 2017 at 3:31:08 PM UTC-5, Tomer Brisker wrote:
>>
>> A possible workaround, if you don't need to manage all of those 
>> interfaces in foreman, is to ignore some of them during fact import using 
>> the ignored_interface_identifiers setting. 
>> You may need to delete the host and re-run puppet for the ignored 
>> interfaces to be removed.
>>
>> On Thu, Feb 2, 2017 at 10:22 PM, Chris Baldwin  wrote:
>>
>>> Huh, that's interesting. The affected hosts do have a 
>>> larger-than-average (10+) number of interfaces as they're docker servers, 
>>> which is a commonality I hadn't noticed.
>>>
>>> Do you guys need/want any other logs to help w/ the issue? Is there any 
>>> kind of workaround that you've found?
>>>
>>> On Thursday, February 2, 2017 at 3:12:12 PM UTC-5, Tomer Brisker wrote:

 Hi Chris,

 Thank you for reporting this.
 This looks like you are hitting 
 http://projects.theforeman.org/issues/7829 which has to do with a 
 large number of interfaces on the host, leading to the interface partial 
 being rendered for each interface.

 On Thu, Feb 2, 2017 at 9:50 PM, Chris Baldwin  
 wrote:

> Hi,
>
> My setup:
> * Multiple Foreman servers, all on 1.12.1
> * memcached shared between them
> * shared backend DB (psql, 9.4.5)
> * Foreman is a puppet 3.8 ENC only
>
> I have a reasonably large Foreman install. For some reason, some hosts 
> take forever to load when clicking on 'edit'. The only thing I see in the 
> logs is some obscene amount of rendering messages, to the tune of 445+ 
> seconds of 
>
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_base_form.html.erb 
> (27.1ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_virtual_form.html.erb 
> (1.2ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered nic/_
> provider_specific_form.html.erb (0.1ms)
> 2017-02-02 11:36:43 [app] [I]   Rendered 
> nic/manageds/_managed.html.erb (29.9ms)
>
> over and over. 
>
> I have a few questions about this:
> * I got this info from debug. What else can I look at to get more 
> information?
> * Why is it rendering the same four items over and over? 
> * I actually deleted the host from Foreman and re-ran puppet, that 
> seemed to fix the issue temporarily. However, I don't understand *why* 
> that 
> made a difference. Can someone shed some light on this?
>
> -Chris (oogs/oogs_/oogs_werk on IRC)
>
> This log is for a good host. In a bad host, add about 100 times the 
> stanzas I listed above.
>
> 2017-02-02 11:36:42 [app] [I] Started GET "/hosts/
> testhost.domain.com/edit" for 127.0.0.101 at 2017-02-02 11:36:42 -0800
> 2017-02-02 11:36:42 [app] [I] Processing by HostsController#edit as 
> HTML
> 2017-02-02 11:36:42 [app] [I]   Parameters: {"id"=>"
> testhost.domain.com"}
> 2017-02-02 11:36:42 [app] [D] Cache read: 
> _session_id:1234567890asdfghjkl
> 2017-02-02 11:36:42 [app] [D] Setting current user thread-local 
> variable to oogs
> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
> 2017-02-02 11:36:42 [app] [D] Cache read: authorize_login_delegation
> 2017-02-02 11:36:42 [app] [D] Cache read: idle_timeout
> 2017-02-02 11:36:42 [app] [D] Setting current organization 
> thread-local variable to none
> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
> variable to none
> 2017-02-02 11:36:42 [app] [I]   Rendered hosts/_progress.html.erb 
> (0.2ms)
> 2017-02-02 11:36:42 [app] [D] Setting current organization 
> thread-local variable to MyOrg
> 2017-02-02 11:36:42 [app] [D] Setting current location thread-local 
> variable to MyLoc
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
> config_group.html.erb (41.7ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
> config_group.html.erb (31.5ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
> config_group.html.erb (29.7ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
> config_group.html.erb (27.2ms)
> 2017-02-02 11:36:42 [app] [I]   Rendered config_groups/_
> 

Re: [foreman-users] Using the <%= options %> or <%= pxe_kernel_options %> array in templates?

[Stefan Lasiewski]

On Fri, Oct 14, 2016 at 1:21 AM, Lukas Zapletal <l...@redhat.com> wrote:

> > It looks like many of many customizations can be folded into one of these
> > arrays, which would simplify our own templates and make it easier to keep
> > them in sync with the upstream versions.
> >
> > How could I make use of the <%= options %> or <%= pxe_kernel_options %>
> > arrays? I can't find any documentation about them. Would I want to set
> > parameters on a Host Group basis?
>
> If you can help us defining which options to include, that would be
> great. I only use Redhat systems and blacklist is the only parameter I
> make use of, so can't think of others.
>

Our own examples are a bit localized, but are probably useful for other
groups. Currently, I'm adding options using simple 'if/elsif/else'
statements in the body of my templates, but I think this could be
accomplished more elegantly.

- The first option is to workaround a bug with VMware and Red Hat's
consistent device naming, which creates network device names with crazy
names like 'eno1623' and 'eno33555201'. Our workaround is to
append 'net.ifnames=0
biosdevname=0' to the kernel parameters, as you can see above.

- The second is to activate a serial console for our Supermicro bare metal
servers, using the device assigned for the IPMI/BMC's "Serial over LAN"
feature.

If these kernel parameters are added during provisioning, they persist
after the provisioning is complete. Systemd will automatically activate the
serial console,
and there is no need to add a new Puppet class to make the changes.

Maybe we could make a generic param kernel_cmdline that would work with
> any OS. If you like the idea, file a feature ticket for me, easy change.


Sounds good. I'll file a ticket soon.

(Whoa, sorry for the delay. I thought I sent this message last week!)

-= Stefan



>
> --
> Later,
>  Lukas #lzap Zapletal
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Foreman users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/foreman-users/pFSAPKen7QA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> foreman-users+unsubscr...@googlegroups.com.
> To post to this group, send email to foreman-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/foreman-users.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Stefan Lasiewski Email: stef...@nersc.gov
Computer System Engineer IIIEmail: slasiew...@lbl.gov
NERSC Data Infrastructure Group

National Energy Research Scientific Computing Center (NERSC
<http://nersc.gov>)
Lawrence Berkeley National Laboratory

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

[foreman-users] Using the <%= options %> or <%= pxe_kernel_options %> array in templates?

[Stefan Lasiewski]

Hi all,

Currently, we have a couple templates with local customizations to do 
things like pass on Kernel parameters, like this example from the 
`Kickstart default PXELinux` template.

   <%-# NOTE:
   # If host is VMware (If it uses the VMware provider), than pass 
kernel params to avoid ‘consistent network device naming’.
   # If host is not VMware, then assign a serial console for IPMI/SOL. 
Assuming standard Supermicro ttyS1 for now.
-%>
<% if @host.provider == 'VMware' -%>
<%-# I am a Virtual Machine -%>
APPEND initrd=<%= @initrd %> ks=<%= foreman_url('provision')%> network 
ks.sendmac net.ifnames=0 biosdevname=0
<% else -%>
<%-# I am a Physical Machine -%>
append initrd=<%= @initrd %> ks=<%= foreman_url('provision')%> network 
ks.sendmac console=tty0 console=ttyS0,9600
<% end -%>
<% else -%>
APPEND initrd=<%= @initrd %> ks=<%= foreman_url('provision')%> 
ksdevice=bootif network kssendmac
<% end -%>


I noticed that newer versions of the `Kickstart default PXELinux` template 
have added an array named `<%= options %>` or `<%= pxe_kernel_options %>`, 
like so:
 
Foreman 1.13:

<% elsif @host.operatingsystem.name == 'Fedora' and @host.
operatingsystem.major.to_i > 16 -%>
APPEND initrd=<%= @initrd %> ks=<%= foreman_url('provision') %> 
ks.device=bootif network ks.sendmac <%= pxe_kernel_options %>


Foreman 1.12 and older:

<% elsif @host.operatingsystem.name == 'Fedora' and @host.
operatingsystem.major.to_i > 16 -%>
APPEND initrd=<%= @initrd %> ks=<%= foreman_url('provision')%> 
ks.device=bootif network ks.sendmac <%= options %> 



It looks like many of many customizations can be folded into one of these 
arrays, which would simplify our own templates and make it easier to keep 
them in sync with the upstream versions.

How could I make use of the <%= options %> or <%= pxe_kernel_options %> 
arrays? I can't find any documentation about them. Would I want to set 
parameters on a Host Group basis?

Thanks,

-= Stefan

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

Re: [foreman-users] How should I keep my templates up to date?

[Stefan Lasiewski]

Okay, thanks for that information.

Also, it looks like I can print out my current templates with the Hammer 
CLI, like this:

```

hammer template dump --name "Kickstart default PXELinux" |less

<%#

kind: PXELinux

name: Kickstart default PXELinux (Locally Customized)

oses:

- CentOS 4

- CentOS 5

...

```

-= Stefan
 

-= Stefan

On Wednesday, October 12, 2016 at 1:48:43 AM UTC-7, Greg Sutcliffe wrote:
>
> I was about to suggest foreman-templates, but it seems you've already got 
> it set up :)
>
> I think you're on the right path - a local git repo, which can be diff'd 
> and/or rebased against the upstream community-templates repo when you need 
> to, is a useful resource, and then regular syncing into Foreman via the 
> foreman-templates plugin. Be aware that foreman-templates is one-way only - 
> changes in the UI will be overwritten (although you can get a diff with 
> verbose=true, it only happens *after* the overwrite)
>
> Cheers
> Greg
>

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

Re: [foreman-users] foreman-rake "Don't know how to build task 'templates:purge'"

[Stefan Lasiewski]

On Wednesday, October 12, 2016 at 2:12:42 AM UTC-7, Greg Sutcliffe wrote:
>
> On 11 October 2016 at 19:25, Stefan Lasiewski <slasi...@lbl.gov 
> > wrote:
>
> I was able to get the correct version of my templates by specifying the 
>> correct foreman branch, like this:
>>
>> foreman-rake templates:sync branch=1.11-stable 
>>
>> I was expecting `foreman-rake templates:sync` to sync to the 
>> `1.11-stable` branch, but instead appears to sync to a newer version 
>> instead, and those templates are not compatible with 1.11. 
>>
>
> The plugin should correctly determine your version and sync the right 
> branch - I'm surprised that it didn't. If you wan't to debug it further, or 
> if it continues to happen, let me know.
>

Thanks Greg. I'll try again after we upgrade to 1.12 or 1.13. If it 
continues to happen, I'll post here.

-= Stefan

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

[foreman-users] How should I keep my templates up to date?

[Stefan Lasiewski]

We recently discovered that some of our provisioning templates in Foreman 
are out of date compared to the -stable branches 
at https://github.com/theforeman/community-templates/branches . In some 
cases, we're concerned that the templates are way out of date, possibly 
since we started with Foreman 1.4. As a result, our provisioning has been 
experiencing some bugs.

>From chatting on #theforeman, it sounds like upgrading Foreman doesn't 
upgrade the templates stored in the database.

What is the recommended way to keep our Foreman templates up to date? 
Should we look into a combination of a local git repo, and `foreman-rake r
epo="http://ourrepo/templates; templates:sync branch=ourbranch`?

Thank you,

-= Stefan

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

[foreman-users] foreman-rake "Don't know how to build task 'templates:purge'"

[Stefan Lasiewski]

I'm running CentOS 6 with SCL, and we're still on Foreman 1.11.

I'm trying to work with foreman_templates 
 to update my templates. I 
installed foreman_templates a few weeks ago using `foreman-installer` and I 
thought it was working then.

However, when I run certain foreman-installer tasks, I get errors about 
'Don't know how to build task', and others. I get essentially the same 
error inside and outside of the TFM SCL environment.

I'm not very experienced with foreman-rake. Any idea what's going on?

[root@puppet ~]# foreman-rake templates:purge 
rake aborted!
Don't know how to build task 'templates:purge'

(See full trace by running task with --trace)
[root@puppet ~]#


[root@puppet ~]# scl enable tfm bash
[root@puppet ~]# foreman-rake templates:purge prefix='Oops '
rake aborted! 
Don't know how to build task 'templates:purge' 
[root@puppet ~]# foreman-rake templates:purge prefix='Oops ' --trace
rake aborted!
Don't know how to build task 'templates:purge'
/opt/rh/rh-ruby22/root/usr/share/gems/gems/rake-10.4.2/lib/rake/task_manager
.rb:62:in `[]'
/opt/rh/rh-ruby22/root/usr/share/gems/gems/rake-10.4.2/lib/rake/application.rb:149:in
 
`invoke_task'
/opt/rh/rh-ruby22/root/usr/share/gems/gems/rake-10.4.2/lib/rake/application.rb:106:in
 
`block (2 levels) in top_level'
/opt/rh/rh-ruby22/root/usr/share/gems/gems/rake-10.4.2/lib/rake/application.
rb:106:in `each'
/opt/rh/rh-ruby22/root/usr/share/gems/gems/rake-10.4.2/lib/rake/application.rb:106:in
 
`block in top_level'
/opt/rh/rh-ruby22/root/usr/share/gems/gems/rake-10.4.2/lib/rake/application.rb:115:in
 
`run_with_threads'
/opt/rh/rh-ruby22/root/usr/share/gems/gems/rake-10.4.2/lib/rake/application.
rb:100:in `top_level'
/opt/rh/rh-ruby22/root/usr/share/gems/gems/rake-10.4.2/lib/rake/application.rb:78:in
 
`block in run'
/opt/rh/rh-ruby22/root/usr/share/gems/gems/rake-10.4.2/lib/rake/application.rb:176:in
 
`standard_exception_handling'
/opt/rh/rh-ruby22/root/usr/share/gems/gems/rake-10.4.2/lib/rake/application.
rb:75:in `run'
/opt/rh/rh-ruby22/root/usr/bin/rake:33:in `'
[root@puppet ~]# 



-= Stefan

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

[foreman-users] Adding a new Libvirt compute resource, but how can I add a password?

[Stefan Lasiewski]

I'm hooking Foreman into two servers which run KVM & Libvirt. I'm following 
5.2.5 
Libvirt Notes 
, and 
I created a SSH Key for testing. I can successfully reach the remote 
hypervisors with a command like `virsh -c 
qemu+ssh://hypervisor.example.com/system list`.

How do I add the passphrase to Foreman so that Foreman can log in to the 
remote server to manage the compute resources? I see some mention of `rake` 
tasks at 
https://www.theforeman.org/manuals/1.11/index.html#5.2.10PasswordEncryption 
, but I'm confused if that applies to what I am trying to do, or how to 
encrypt something like a passphrase for libvirt.

Thanks,

-= Stefan

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