Auto-Provisioning Discovered Bare-metal Host via PXE Issue

lzap · May 15, 2017, 1:30pm

I found the root cause today, here is the patch:

github.com/theforeman/foreman_discovery

Fixes #19313 - autoprovisioning NIC association fixed

theforeman:develop ← lzap:autoprovisioning-association-19313

opened 01:28PM - 15 May 17 UTC

lzap

+112 -52

After discovered host is converted to Managed, associated NICs still have their …associations set to the original record from the database (`Host::Discovered`), which led the `host.managed?` statement fail in `tftp_ready?` method in TFTP orchestration. This led to TFTP orchestration to be skipped completely, so I added a statement to set the appropriate assotiation explicitly during auto provisioning. This is a regression and I cannot find the root cause of this, it worked previously. We have reports that both 1.14 and 1.15 are broken.

Only this line is relevant and fixes the issue, all the rest is improving
tests:

github.com/theforeman/foreman_discovery

Fixes #19313 - autoprovisioning NIC association fixed

theforeman:develop ← lzap:autoprovisioning-association-19313

opened 01:28PM - 15 May 17 UTC

lzap

+112 -52

After discovered host is converted to Managed, associated NICs still have their …associations set to the original record from the database (`Host::Discovered`), which led the `host.managed?` statement fail in `tftp_ready?` method in TFTP orchestration. This led to TFTP orchestration to be skipped completely, so I added a statement to set the appropriate assotiation explicitly during auto provisioning. This is a regression and I cannot find the root cause of this, it worked previously. We have reports that both 1.14 and 1.15 are broken.

This is not relevant to if subnet is or is not set. Test it please and
comment in the github or issue.

···

On Mon, May 15, 2017 at 11:47 AM, Jacek Mierzwa wrote:

This is for my case:

subnet assigned to the host group

- discovered host has primary NIC in the subnet (it’s the only subnet I
have defined)

however, ‘subnet’ field is indeed clear:

On Sun, May 14, 2017 at 10:14 PM, Lukas Zapletal lzap@redhat.com wrote:

Chad, one more question - what subnet the primary interface of your
discovered node is connected to, what IP address it was assigned and what
subnet have you set in the hostgroup?

These three must match, can you check this?

LZ

On Sun, May 14, 2017 at 8:43 PM, Lukas Zapletal lzap@redhat.com wrote:

Chad,

when a host is discovered, it should be discovered in a subnet. This is
shown on the list of discovered hosts. Do you see those set correctly?

Workaround is to have such a subnet defined so it is assigned during
discovery.

On Fri, May 12, 2017 at 2:21 PM, Chad Schroeder < >>> chads.finishing.strong@gmail.com> wrote:

Any progress to report Lukas?

On Wednesday, May 3, 2017 at 4:07:46 AM UTC-5, Lukas Zapletal wrote:

Nah I cannot reproduce it in my libvirt environment, I guess this has
something to do with IPMI. Could you try to add “ipmi_*” facts into ignored
facts so IPMI NIC is not created during discovery? Does it help?

On Wed, May 3, 2017 at 10:54 AM, Lukas Zapletal lz...@redhat.com >>>>> wrote:

Jacek, for 1.15 there is another bug for autoprovisioning that has
been fixed in RC2:

Bug #19409: Auto provision does not work after taxonomy fix - Discovery - Foreman

Try with RC2 please. Anyway, one questions for all of you - how does
Foreman recognize your NICs after host is discovered?

Can you make screenshot of recognized NICs in the UI (discovered host
detail page)? Interested in which interface is set as primary/provisioning.

Also which subnet has been detected? Does it match
primary/provisioning NIC? Is TFTP associated with this subnet?

What version of the FDI (image) do you use? If this is a regression
can you try with older version?

Initially I thought it’s caused by domain but that was wrong
assumption.

On Fri, Apr 28, 2017 at 12:27 PM, Jacek Mierzwa jmie...@lbisa.com >>>>>> wrote:

I have tested auto-provisioning in 1.15 RC1.
Now it also matters if hostname pattern is used in discovery rule.

No hostname in discovery rule:

auto-provision does NOT create PXE file

manually select ‘Build’ on auto-provisioned host = PXE file
created!

manually select ‘Rebuild config’ on auto-privisioned host = nothing

Hostname pattern used in discovery rule:

auto-provision does NOT create PXE file

manually select ‘Build’ on auto-provisioned host = no PXE file +
hostname reverted to default (macXXXXXXXXXX)

manually select ‘Rebuild config’ on auto-privisioned host = no PXE
file + hostname reverted to default (macXXXXXXXXXX)

after the hostname is reverted to default:

manually select ‘Build’ on host = no PXE file

manually select ‘Rebuild config’ on host = PXE file created!

I think this goes beyond tftp.rb :S

On Tue, Apr 25, 2017 at 6:40 PM, Chad Schroeder < >>>>>>> chads.finis...@gmail.com> wrote:

Lukas,

Hope this helps:

On initial discovery, the results of tftp_ready? are:
host.nil: false
host.managed: false

Clicking “Auto Provision” on the discovered host in the “Discovered
Hosts” menu:
host.nil: false
host.managed: false

Clicking “Edit” on the host in “All Hosts” menu and then clicking
submit:
host.nil: false
host.managed: true
managed: true
provision: true
host: mac00224d4fb56a.sub.domain.net
host.operatingsystem: CentOS 7.3.1611
host.pxe_loader.present: true
pxe_build?: true
SETTINGS[:unattended]: true

Chad

On Friday, April 21, 2017 at 8:13:18 AM UTC-5, Lukas Zapletal wrote:

Ok thanks, I can see that either TFTP nor DHCP steps are not
getting orchestrated at all. I suspect that this returns false:

https://github.com/theforeman/foreman/blob/develop/app/model
s/concerns/orchestration/tftp.rb#L21

Maybe if you are able to break up the tftp_ready? method into
multiple lines and do some debug logger outputs of all individual
statements in there to see which does not trigger TFTP orchestration.

Strange is we should see DHCP orchestration but that does not
happen as well. Are NICs created correctly? Is there a subnet set?

Unfortunately I have engagement at customer site for whole week, I
will carry on the week after. We need to solve this.

On Wed, Apr 19, 2017 at 4:58 PM, Chad Schroeder < >>>>>>>>> chads.finis...@gmail.com> wrote:

I’m not sure I follow what your asking for Lukas.

On Wednesday, April 19, 2017 at 8:50:21 AM UTC-5, Lukas Zapletal >>>>>>>>>> wrote:

Jacek, I apologize but what I meant was:

http://projects.theforeman.org/projects/foreman/wiki/Trouble
shooting#Enable-detailed-SQL-logger-for-orchestration-messages

Chad, it looks like setting (a fake) domain did not help to
Jacek, can you try it? Did it help in your case? Associate Subnet with a
Domain and then set it in the Hostgroup.

LZ

On Wed, Apr 19, 2017 at 2:51 PM, Jacek Mierzwa < >>>>>>>>>>> jmie...@lbisa.com> wrote:

And here is Foreman app debug-level log from ‘successful’
auto-provision (no PXE file appears).

On Wed, Apr 19, 2017 at 2:13 PM, Jacek Mierzwa < >>>>>>>>>>>> jmie...@lbisa.com> wrote:

Here’s the SQL debug log from ‘successful’ auto-provision (no
PXE file appears).
Please find attached.

Thanks/Regards

On Wed, Apr 19, 2017 at 1:21 PM, Lukas Zapletal < >>>>>>>>>>>>> lz...@redhat.com> wrote:

Ok I finally reproduced.

When domain is blank, autoprovisioning fails for no apparent
reason,
logs are empty, something fails during orchestration and
hosts are
getting discovered again (which fails since managed host
already
exists).

Bug #19313: Auto-provisioning does not orchestrate TFTP - Discovery - Foreman

I will do my best to fix it this week, but I am on travel the
week
after, crossing my fingers.

LZ

On Thu, Apr 13, 2017 at 4:28 PM, Garreat jmie...@fgtsa.com >>>>>>>>>>>>>> wrote:

I experience this issue.
After clicking ‘auto-provisioning’ on a discovered host,
the host entry is
created, the host reboots - but only to enter Foreman
Discovery Image PXE
loop.
My TFTP proxy is in healthy status as I can recreate PXE
default no prob.

Now answering your checklist:

host is managed - yes - OK

provision method is “build” and not “image” - how to
check this? I can’t
see the ‘build mode’ checkbox for the newly created host

host has operating system set - yes (inherited from host
group) - OK

host has pxe loader flag present (not set to blank or
None) - how to check
this?

host has one provisioning NIC with valid MAC address -
yes it does - OK

a subnet is associated with the provisioning NIC - it is,
but it’s a
subnet different than the one declared in machine’s host
group

the subnet has TFTP feature turned on - it does, and it’s
the same TFTP
proxy as in the subnet that I wanted

Also, the ‘domain’ is blank for the fresh created host.
The OS assigned to this host group has a valid PXElinux
template selected.

Assume I’m not making any manual changes:

‘Build host’ does nothing

‘Rebuild config’ creates a PXE mac-template on TFTP
immediatly

facter -j output attached

Thanks / Regards / Greetings

W dniu wtorek, 11 kwietnia 2017 10:28:17 UTC+2 użytkownik
Lukas Zapletal
napisał:

TFTP orchestration is not being triggered. It can be only
performed
when all of these conditions are met:

host is managed

provision method is “build” and not “image”

host has operating system set

host has pxe loader flag present (not set to blank or
None)

host has one provisioning NIC with valid MAC address

a subnet is associated with the provisioning NIC

the subnet has TFTP feature turned on

Visit a host which failed provisioning and do this
checklist please.

LZ

–
Later,
Lukas @lzap Zapletal

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

–
Later,
Lukas @lzap Zapletal

–
Later,
Lukas @lzap Zapletal

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

–
Later,
Lukas @lzap Zapletal

–
Later,
Lukas @lzap Zapletal

–
Later,
Lukas @lzap Zapletal

–
Later,
Lukas @lzap Zapletal

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

–
Later,
Lukas @lzap Zapletal

Jacek_Mierzwa · May 15, 2017, 1:53pm

Thank you Lukas, that looks promising.
I would test straight away, however… I don't even have this file!
/usr/share/foreman/app/controllers/concerns/foreman/controller/
discovered_extensions.rb

Discovery plugin installed with 'apt-get install ruby-foreman-discovery'.
Here's what I got:

foreman@4ed717663fc1:~/app/controllers/concerns/foreman/controller$ ls -la
total 92
drwxr-xr-x. 4 foreman foreman 4096 May 12 15:28 .
drwxr-xr-x. 3 foreman foreman 24 May 12 15:28 …
-rw-r–r--. 4 foreman foreman 502 May 9 12:29 action_permission_dsl.rb
-rw-r–r--. 4 foreman foreman 2946 May 9 12:29 authentication.rb
-rw-r–r--. 4 foreman foreman 1280 May 9 12:29 auto_complete_search.rb
-rw-r–r--. 4 foreman foreman 154 May 9 12:29 bookmark_common.rb
-rw-r–r--. 4 foreman foreman 363 May 9 12:29 compute_resources_common.rb
-rw-r–r--. 4 foreman foreman 497 May 9 12:29 csv_responder.rb
-rw-r–r--. 4 foreman foreman 2197 May 9 12:29 environments.rb
-rw-r–r--. 4 foreman foreman 752 May 9 12:29 filter_parameters.rb
-rw-r–r--. 4 foreman foreman 2154 May 9 12:29 host_details.rb
-rw-r–r--. 4 foreman foreman 512 May 9 12:29 migration_checker.rb
drwxr-xr-x. 2 foreman foreman 4096 May 12 15:28 parameters
-rw-r–r--. 4 foreman foreman 1368 May 9 12:29 provisioning_templates.rb
drwxr-xr-x. 2 foreman foreman 44 May 12 15:28 puppet
-rw-r–r--. 4 foreman foreman 1801 May 9 12:29 session.rb
-rw-r–r--. 4 foreman foreman 4867 May 9 12:29 smart_proxy_auth.rb
-rw-r–r--. 4 foreman foreman 470 May 9 12:29 ssh_keys_common.rb
-rw-r–r--. 4 foreman foreman 6405 May 9 12:29 taxonomies_controller.rb
-rw-r–r--. 4 foreman foreman 1672 May 9 12:29 taxonomy_multiple.rb
-rw-r–r--. 4 foreman foreman 375 May 9 12:29 topbar_sweeper.rb
-rw-r–r--. 4 foreman foreman 267 May 9 12:29 user_self_editing.rb
-rw-r–r--. 4 foreman foreman 1350 May 9 12:29 users_mixin.rb

Any clue on that? :S

···

On Mon, May 15, 2017 at 3:30 PM, Lukas Zapletal wrote:

I found the root cause today, here is the patch: https://github.com/
theforeman/foreman_discovery/pull/346

Only this line is relevant and fixes the issue, all the rest is improving
tests:

https://github.com/theforeman/foreman_discovery/pull/346/files#diff-
2e9f4565997ec456d7eb9c4bbcfca096R61

This is not relevant to if subnet is or is not set. Test it please and
comment in the github or issue.

On Mon, May 15, 2017 at 11:47 AM, Jacek Mierzwa jmierzwa@lbisa.com > wrote:

This is for my case:

subnet assigned to the host group

- discovered host has primary NIC in the subnet (it’s the only subnet I
have defined)

however, ‘subnet’ field is indeed clear:

On Sun, May 14, 2017 at 10:14 PM, Lukas Zapletal lzap@redhat.com wrote:

Chad, one more question - what subnet the primary interface of your
discovered node is connected to, what IP address it was assigned and what
subnet have you set in the hostgroup?

These three must match, can you check this?

LZ

On Sun, May 14, 2017 at 8:43 PM, Lukas Zapletal lzap@redhat.com wrote:

Chad,

when a host is discovered, it should be discovered in a subnet. This is
shown on the list of discovered hosts. Do you see those set correctly?

Workaround is to have such a subnet defined so it is assigned during
discovery.

On Fri, May 12, 2017 at 2:21 PM, Chad Schroeder < >>>> chads.finishing.strong@gmail.com> wrote:

Any progress to report Lukas?

On Wednesday, May 3, 2017 at 4:07:46 AM UTC-5, Lukas Zapletal wrote:

Nah I cannot reproduce it in my libvirt environment, I guess this has
something to do with IPMI. Could you try to add “ipmi_*” facts into ignored
facts so IPMI NIC is not created during discovery? Does it help?

On Wed, May 3, 2017 at 10:54 AM, Lukas Zapletal lz...@redhat.com >>>>>> wrote:

Jacek, for 1.15 there is another bug for autoprovisioning that has
been fixed in RC2:

Bug #19409: Auto provision does not work after taxonomy fix - Discovery - Foreman

Try with RC2 please. Anyway, one questions for all of you - how does
Foreman recognize your NICs after host is discovered?

Can you make screenshot of recognized NICs in the UI (discovered
host detail page)? Interested in which interface is set as
primary/provisioning.

Also which subnet has been detected? Does it match
primary/provisioning NIC? Is TFTP associated with this subnet?

What version of the FDI (image) do you use? If this is a regression
can you try with older version?

Initially I thought it’s caused by domain but that was wrong
assumption.

On Fri, Apr 28, 2017 at 12:27 PM, Jacek Mierzwa jmie...@lbisa.com >>>>>>> wrote:

I have tested auto-provisioning in 1.15 RC1.
Now it also matters if hostname pattern is used in discovery rule.

No hostname in discovery rule:

auto-provision does NOT create PXE file

manually select ‘Build’ on auto-provisioned host = PXE file
created!

manually select ‘Rebuild config’ on auto-privisioned host =
nothing

Hostname pattern used in discovery rule:

auto-provision does NOT create PXE file

manually select ‘Build’ on auto-provisioned host = no PXE file +
hostname reverted to default (macXXXXXXXXXX)

manually select ‘Rebuild config’ on auto-privisioned host = no
PXE file + hostname reverted to default (macXXXXXXXXXX)

after the hostname is reverted to default:

manually select ‘Build’ on host = no PXE file

manually select ‘Rebuild config’ on host = PXE file created!

I think this goes beyond tftp.rb :S

On Tue, Apr 25, 2017 at 6:40 PM, Chad Schroeder < >>>>>>>> chads.finis...@gmail.com> wrote:

Lukas,

Hope this helps:

On initial discovery, the results of tftp_ready? are:
host.nil: false
host.managed: false

Clicking “Auto Provision” on the discovered host in the
"Discovered Hosts" menu:
host.nil: false
host.managed: false

Clicking “Edit” on the host in “All Hosts” menu and then clicking
submit:
host.nil: false
host.managed: true
managed: true
provision: true
host: mac00224d4fb56a.sub.domain.net
host.operatingsystem: CentOS 7.3.1611
host.pxe_loader.present: true
pxe_build?: true
SETTINGS[:unattended]: true

Chad

On Friday, April 21, 2017 at 8:13:18 AM UTC-5, Lukas Zapletal >>>>>>>>> wrote:

Ok thanks, I can see that either TFTP nor DHCP steps are not
getting orchestrated at all. I suspect that this returns false:

https://github.com/theforeman/foreman/blob/develop/app/model
s/concerns/orchestration/tftp.rb#L21

Maybe if you are able to break up the tftp_ready? method into
multiple lines and do some debug logger outputs of all individual
statements in there to see which does not trigger TFTP orchestration.

Strange is we should see DHCP orchestration but that does not
happen as well. Are NICs created correctly? Is there a subnet set?

Unfortunately I have engagement at customer site for whole week,
I will carry on the week after. We need to solve this.

On Wed, Apr 19, 2017 at 4:58 PM, Chad Schroeder < >>>>>>>>>> chads.finis...@gmail.com> wrote:

I’m not sure I follow what your asking for Lukas.

On Wednesday, April 19, 2017 at 8:50:21 AM UTC-5, Lukas Zapletal >>>>>>>>>>> wrote:

Jacek, I apologize but what I meant was:

http://projects.theforeman.org/projects/foreman/wiki/Trouble
shooting#Enable-detailed-SQL-logger-for-orchestration-messages

Chad, it looks like setting (a fake) domain did not help to
Jacek, can you try it? Did it help in your case? Associate Subnet with a
Domain and then set it in the Hostgroup.

LZ

On Wed, Apr 19, 2017 at 2:51 PM, Jacek Mierzwa < >>>>>>>>>>>> jmie...@lbisa.com> wrote:

And here is Foreman app debug-level log from 'successful’
auto-provision (no PXE file appears).

On Wed, Apr 19, 2017 at 2:13 PM, Jacek Mierzwa < >>>>>>>>>>>>> jmie...@lbisa.com> wrote:

Here’s the SQL debug log from ‘successful’ auto-provision (no
PXE file appears).
Please find attached.

Thanks/Regards

On Wed, Apr 19, 2017 at 1:21 PM, Lukas Zapletal < >>>>>>>>>>>>>> lz...@redhat.com> wrote:

Ok I finally reproduced.

When domain is blank, autoprovisioning fails for no apparent
reason,
logs are empty, something fails during orchestration and
hosts are
getting discovered again (which fails since managed host
already
exists).

Bug #19313: Auto-provisioning does not orchestrate TFTP - Discovery - Foreman

I will do my best to fix it this week, but I am on travel
the week
after, crossing my fingers.

LZ

On Thu, Apr 13, 2017 at 4:28 PM, Garreat jmie...@fgtsa.com >>>>>>>>>>>>>>> wrote:

I experience this issue.
After clicking ‘auto-provisioning’ on a discovered host,
the host entry is
created, the host reboots - but only to enter Foreman
Discovery Image PXE
loop.
My TFTP proxy is in healthy status as I can recreate PXE
default no prob.

Now answering your checklist:

host is managed - yes - OK

provision method is “build” and not “image” - how to
check this? I can’t
see the ‘build mode’ checkbox for the newly created host

host has operating system set - yes (inherited from host
group) - OK

host has pxe loader flag present (not set to blank or
None) - how to check
this?

host has one provisioning NIC with valid MAC address -
yes it does - OK

a subnet is associated with the provisioning NIC - it
is, but it’s a
subnet different than the one declared in machine’s host
group

the subnet has TFTP feature turned on - it does, and
it’s the same TFTP
proxy as in the subnet that I wanted

Also, the ‘domain’ is blank for the fresh created host.
The OS assigned to this host group has a valid PXElinux
template selected.

Assume I’m not making any manual changes:

‘Build host’ does nothing

‘Rebuild config’ creates a PXE mac-template on TFTP
immediatly

facter -j output attached

Thanks / Regards / Greetings

W dniu wtorek, 11 kwietnia 2017 10:28:17 UTC+2 użytkownik
Lukas Zapletal
napisał:

TFTP orchestration is not being triggered. It can be only
performed

when all of these conditions are met:

host is managed

provision method is “build” and not “image”

host has operating system set

host has pxe loader flag present (not set to blank or
None)

host has one provisioning NIC with valid MAC address

a subnet is associated with the provisioning NIC

the subnet has TFTP feature turned on

Visit a host which failed provisioning and do this
checklist please.

LZ

–
Later,
Lukas @lzap Zapletal

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

Jacek_Mierzwa · May 15, 2017, 2:16pm

OK I think I found it – nevermind!
So I'm testing this, will report soon…

···

On Mon, May 15, 2017 at 3:53 PM, Jacek Mierzwa wrote:

Thank you Lukas, that looks promising.
I would test straight away, however… I don’t even have this file!
/usr/share/foreman/app/controllers/concerns/foreman/controller/discovered_
extensions.rb

Discovery plugin installed with ‘apt-get install ruby-foreman-discovery’.
Here’s what I got:

foreman@4ed717663fc1:~/app/controllers/concerns/foreman/controller$ ls -la
total 92
drwxr-xr-x. 4 foreman foreman 4096 May 12 15:28 .
drwxr-xr-x. 3 foreman foreman 24 May 12 15:28 …
-rw-r–r--. 4 foreman foreman 502 May 9 12:29 action_permission_dsl.rb
-rw-r–r--. 4 foreman foreman 2946 May 9 12:29 authentication.rb
-rw-r–r--. 4 foreman foreman 1280 May 9 12:29 auto_complete_search.rb
-rw-r–r--. 4 foreman foreman 154 May 9 12:29 bookmark_common.rb
-rw-r–r--. 4 foreman foreman 363 May 9 12:29 compute_resources_common.rb
-rw-r–r--. 4 foreman foreman 497 May 9 12:29 csv_responder.rb
-rw-r–r--. 4 foreman foreman 2197 May 9 12:29 environments.rb
-rw-r–r--. 4 foreman foreman 752 May 9 12:29 filter_parameters.rb
-rw-r–r--. 4 foreman foreman 2154 May 9 12:29 host_details.rb
-rw-r–r--. 4 foreman foreman 512 May 9 12:29 migration_checker.rb
drwxr-xr-x. 2 foreman foreman 4096 May 12 15:28 parameters
-rw-r–r--. 4 foreman foreman 1368 May 9 12:29 provisioning_templates.rb
drwxr-xr-x. 2 foreman foreman 44 May 12 15:28 puppet
-rw-r–r--. 4 foreman foreman 1801 May 9 12:29 session.rb
-rw-r–r--. 4 foreman foreman 4867 May 9 12:29 smart_proxy_auth.rb
-rw-r–r--. 4 foreman foreman 470 May 9 12:29 ssh_keys_common.rb
-rw-r–r--. 4 foreman foreman 6405 May 9 12:29 taxonomies_controller.rb
-rw-r–r--. 4 foreman foreman 1672 May 9 12:29 taxonomy_multiple.rb
-rw-r–r--. 4 foreman foreman 375 May 9 12:29 topbar_sweeper.rb
-rw-r–r--. 4 foreman foreman 267 May 9 12:29 user_self_editing.rb
-rw-r–r--. 4 foreman foreman 1350 May 9 12:29 users_mixin.rb

Any clue on that? :S

On Mon, May 15, 2017 at 3:30 PM, Lukas Zapletal lzap@redhat.com wrote:

I found the root cause today, here is the patch: https://github.com/thef
oreman/foreman_discovery/pull/346

Only this line is relevant and fixes the issue, all the rest is improving
tests:

https://github.com/theforeman/foreman_discovery/pull/346/fil
es#diff-2e9f4565997ec456d7eb9c4bbcfca096R61

This is not relevant to if subnet is or is not set. Test it please and
comment in the github or issue.

On Mon, May 15, 2017 at 11:47 AM, Jacek Mierzwa jmierzwa@lbisa.com >> wrote:

This is for my case:

subnet assigned to the host group

- discovered host has primary NIC in the subnet (it’s the only subnet I
have defined)

however, ‘subnet’ field is indeed clear:

On Sun, May 14, 2017 at 10:14 PM, Lukas Zapletal lzap@redhat.com >>> wrote:

Chad, one more question - what subnet the primary interface of your
discovered node is connected to, what IP address it was assigned and what
subnet have you set in the hostgroup?

These three must match, can you check this?

LZ

On Sun, May 14, 2017 at 8:43 PM, Lukas Zapletal lzap@redhat.com >>>> wrote:

Chad,

when a host is discovered, it should be discovered in a subnet. This
is shown on the list of discovered hosts. Do you see those set correctly?

Workaround is to have such a subnet defined so it is assigned during
discovery.

On Fri, May 12, 2017 at 2:21 PM, Chad Schroeder < >>>>> chads.finishing.strong@gmail.com> wrote:

Any progress to report Lukas?

On Wednesday, May 3, 2017 at 4:07:46 AM UTC-5, Lukas Zapletal wrote:

Nah I cannot reproduce it in my libvirt environment, I guess this
has something to do with IPMI. Could you try to add “ipmi_*” facts into
ignored facts so IPMI NIC is not created during discovery? Does it help?

On Wed, May 3, 2017 at 10:54 AM, Lukas Zapletal lz...@redhat.com >>>>>>> wrote:

Jacek, for 1.15 there is another bug for autoprovisioning that has
been fixed in RC2:

Bug #19409: Auto provision does not work after taxonomy fix - Discovery - Foreman

Try with RC2 please. Anyway, one questions for all of you - how
does Foreman recognize your NICs after host is discovered?

Can you make screenshot of recognized NICs in the UI (discovered
host detail page)? Interested in which interface is set as
primary/provisioning.

Also which subnet has been detected? Does it match
primary/provisioning NIC? Is TFTP associated with this subnet?

What version of the FDI (image) do you use? If this is a regression
can you try with older version?

Initially I thought it’s caused by domain but that was wrong
assumption.

On Fri, Apr 28, 2017 at 12:27 PM, Jacek Mierzwa jmie...@lbisa.com >>>>>>>> wrote:

I have tested auto-provisioning in 1.15 RC1.
Now it also matters if hostname pattern is used in discovery rule.

No hostname in discovery rule:

auto-provision does NOT create PXE file

manually select ‘Build’ on auto-provisioned host = PXE file
created!

manually select ‘Rebuild config’ on auto-privisioned host =
nothing

Hostname pattern used in discovery rule:

auto-provision does NOT create PXE file

manually select ‘Build’ on auto-provisioned host = no PXE file +
hostname reverted to default (macXXXXXXXXXX)

manually select ‘Rebuild config’ on auto-privisioned host = no
PXE file + hostname reverted to default (macXXXXXXXXXX)

after the hostname is reverted to default:

manually select ‘Build’ on host = no PXE file

manually select ‘Rebuild config’ on host = PXE file created!

I think this goes beyond tftp.rb :S

On Tue, Apr 25, 2017 at 6:40 PM, Chad Schroeder < >>>>>>>>> chads.finis...@gmail.com> wrote:

Lukas,

Hope this helps:

On initial discovery, the results of tftp_ready? are:
host.nil: false
host.managed: false

Clicking “Auto Provision” on the discovered host in the
"Discovered Hosts" menu:
host.nil: false
host.managed: false

Clicking “Edit” on the host in “All Hosts” menu and then clicking
submit:
host.nil: false
host.managed: true
managed: true
provision: true
host: mac00224d4fb56a.sub.domain.net
host.operatingsystem: CentOS 7.3.1611
host.pxe_loader.present: true
pxe_build?: true
SETTINGS[:unattended]: true

Chad

On Friday, April 21, 2017 at 8:13:18 AM UTC-5, Lukas Zapletal >>>>>>>>>> wrote:

Ok thanks, I can see that either TFTP nor DHCP steps are not
getting orchestrated at all. I suspect that this returns false:

https://github.com/theforeman/foreman/blob/develop/app/model
s/concerns/orchestration/tftp.rb#L21

Maybe if you are able to break up the tftp_ready? method into
multiple lines and do some debug logger outputs of all individual
statements in there to see which does not trigger TFTP orchestration.

Strange is we should see DHCP orchestration but that does not
happen as well. Are NICs created correctly? Is there a subnet set?

Unfortunately I have engagement at customer site for whole week,
I will carry on the week after. We need to solve this.

On Wed, Apr 19, 2017 at 4:58 PM, Chad Schroeder < >>>>>>>>>>> chads.finis...@gmail.com> wrote:

I’m not sure I follow what your asking for Lukas.

On Wednesday, April 19, 2017 at 8:50:21 AM UTC-5, Lukas >>>>>>>>>>>> Zapletal wrote:

Jacek, I apologize but what I meant was:

http://projects.theforeman.org/projects/foreman/wiki/Trouble
shooting#Enable-detailed-SQL-logger-for-orchestration-messages

Chad, it looks like setting (a fake) domain did not help to
Jacek, can you try it? Did it help in your case? Associate Subnet with a
Domain and then set it in the Hostgroup.

LZ

On Wed, Apr 19, 2017 at 2:51 PM, Jacek Mierzwa < >>>>>>>>>>>>> jmie...@lbisa.com> wrote:

And here is Foreman app debug-level log from 'successful’
auto-provision (no PXE file appears).

On Wed, Apr 19, 2017 at 2:13 PM, Jacek Mierzwa < >>>>>>>>>>>>>> jmie...@lbisa.com> wrote:

Here’s the SQL debug log from ‘successful’ auto-provision
(no PXE file appears).
Please find attached.

Thanks/Regards

On Wed, Apr 19, 2017 at 1:21 PM, Lukas Zapletal < >>>>>>>>>>>>>>> lz...@redhat.com> wrote:

Ok I finally reproduced.

When domain is blank, autoprovisioning fails for no
apparent reason,
logs are empty, something fails during orchestration and
hosts are
getting discovered again (which fails since managed host
already
exists).

Bug #19313: Auto-provisioning does not orchestrate TFTP - Discovery - Foreman

I will do my best to fix it this week, but I am on travel
the week
after, crossing my fingers.

LZ

On Thu, Apr 13, 2017 at 4:28 PM, Garreat jmie...@fgtsa.com >>>>>>>>>>>>>>>> wrote:

I experience this issue.
After clicking ‘auto-provisioning’ on a discovered host,
the host entry is
created, the host reboots - but only to enter Foreman
Discovery Image PXE
loop.
My TFTP proxy is in healthy status as I can recreate PXE
default no prob.

Now answering your checklist:

host is managed - yes - OK

provision method is “build” and not “image” - how to
check this? I can’t
see the ‘build mode’ checkbox for the newly created host

host has operating system set - yes (inherited from
host group) - OK

host has pxe loader flag present (not set to blank or
None) - how to check
this?

host has one provisioning NIC with valid MAC address -
yes it does - OK

a subnet is associated with the provisioning NIC - it
is, but it’s a
subnet different than the one declared in machine’s host
group

the subnet has TFTP feature turned on - it does, and
it’s the same TFTP
proxy as in the subnet that I wanted

Also, the ‘domain’ is blank for the fresh created host.
The OS assigned to this host group has a valid PXElinux
template selected.

Assume I’m not making any manual changes:

‘Build host’ does nothing

‘Rebuild config’ creates a PXE mac-template on TFTP
immediatly

facter -j output attached

Thanks / Regards / Greetings

W dniu wtorek, 11 kwietnia 2017 10:28:17 UTC+2 użytkownik
Lukas Zapletal
napisał:

TFTP orchestration is not being triggered. It can be
only performed

when all of these conditions are met:

host is managed

provision method is “build” and not “image”

host has operating system set

host has pxe loader flag present (not set to blank or
None)

host has one provisioning NIC with valid MAC address

a subnet is associated with the provisioning NIC

the subnet has TFTP feature turned on

Jacek_Mierzwa · May 15, 2017, 2:45pm

Just tested, after clicking 'auto-provision' the PXE file does NOT appear.

Still need the same old procedure:
auto-provision -> (go to 'Hosts') -> (select the newly created host) ->
'Build hosts' -> (hostname reverted to default) -> 'Rebuild config'

Only then the PXE file does appear.

···

On Mon, May 15, 2017 at 4:16 PM, Jacek Mierzwa wrote:

OK I think I found it – nevermind!
So I’m testing this, will report soon…

On Mon, May 15, 2017 at 3:53 PM, Jacek Mierzwa jmierzwa@lbisa.com wrote:

Thank you Lukas, that looks promising.
I would test straight away, however… I don’t even have this file!
/usr/share/foreman/app/controllers/concerns/foreman/controller/
discovered_extensions.rb

Discovery plugin installed with ‘apt-get install ruby-foreman-discovery’.
Here’s what I got:

foreman@4ed717663fc1:~/app/controllers/concerns/foreman/controller$ ls
-la
total 92
drwxr-xr-x. 4 foreman foreman 4096 May 12 15:28 .
drwxr-xr-x. 3 foreman foreman 24 May 12 15:28 …
-rw-r–r--. 4 foreman foreman 502 May 9 12:29 action_permission_dsl.rb
-rw-r–r--. 4 foreman foreman 2946 May 9 12:29 authentication.rb
-rw-r–r--. 4 foreman foreman 1280 May 9 12:29 auto_complete_search.rb
-rw-r–r--. 4 foreman foreman 154 May 9 12:29 bookmark_common.rb
-rw-r–r--. 4 foreman foreman 363 May 9 12:29
compute_resources_common.rb
-rw-r–r--. 4 foreman foreman 497 May 9 12:29 csv_responder.rb
-rw-r–r--. 4 foreman foreman 2197 May 9 12:29 environments.rb
-rw-r–r--. 4 foreman foreman 752 May 9 12:29 filter_parameters.rb
-rw-r–r--. 4 foreman foreman 2154 May 9 12:29 host_details.rb
-rw-r–r--. 4 foreman foreman 512 May 9 12:29 migration_checker.rb
drwxr-xr-x. 2 foreman foreman 4096 May 12 15:28 parameters
-rw-r–r--. 4 foreman foreman 1368 May 9 12:29 provisioning_templates.rb
drwxr-xr-x. 2 foreman foreman 44 May 12 15:28 puppet
-rw-r–r--. 4 foreman foreman 1801 May 9 12:29 session.rb
-rw-r–r--. 4 foreman foreman 4867 May 9 12:29 smart_proxy_auth.rb
-rw-r–r--. 4 foreman foreman 470 May 9 12:29 ssh_keys_common.rb
-rw-r–r--. 4 foreman foreman 6405 May 9 12:29 taxonomies_controller.rb
-rw-r–r--. 4 foreman foreman 1672 May 9 12:29 taxonomy_multiple.rb
-rw-r–r--. 4 foreman foreman 375 May 9 12:29 topbar_sweeper.rb
-rw-r–r--. 4 foreman foreman 267 May 9 12:29 user_self_editing.rb
-rw-r–r--. 4 foreman foreman 1350 May 9 12:29 users_mixin.rb

Any clue on that? :S

On Mon, May 15, 2017 at 3:30 PM, Lukas Zapletal lzap@redhat.com wrote:

I found the root cause today, here is the patch: https://github.com/thef
oreman/foreman_discovery/pull/346

Only this line is relevant and fixes the issue, all the rest is
improving tests:

https://github.com/theforeman/foreman_discovery/pull/346/fil
es#diff-2e9f4565997ec456d7eb9c4bbcfca096R61

This is not relevant to if subnet is or is not set. Test it please and
comment in the github or issue.

On Mon, May 15, 2017 at 11:47 AM, Jacek Mierzwa jmierzwa@lbisa.com >>> wrote:

This is for my case:

subnet assigned to the host group

- discovered host has primary NIC in the subnet (it’s the only subnet
I have defined)

however, ‘subnet’ field is indeed clear:

On Sun, May 14, 2017 at 10:14 PM, Lukas Zapletal lzap@redhat.com >>>> wrote:

Chad, one more question - what subnet the primary interface of your
discovered node is connected to, what IP address it was assigned and what
subnet have you set in the hostgroup?

These three must match, can you check this?

LZ

On Sun, May 14, 2017 at 8:43 PM, Lukas Zapletal lzap@redhat.com >>>>> wrote:

Chad,

when a host is discovered, it should be discovered in a subnet. This
is shown on the list of discovered hosts. Do you see those set correctly?

Workaround is to have such a subnet defined so it is assigned during
discovery.

On Fri, May 12, 2017 at 2:21 PM, Chad Schroeder < >>>>>> chads.finishing.strong@gmail.com> wrote:

Any progress to report Lukas?

On Wednesday, May 3, 2017 at 4:07:46 AM UTC-5, Lukas Zapletal wrote:

Nah I cannot reproduce it in my libvirt environment, I guess this
has something to do with IPMI. Could you try to add “ipmi_*” facts into
ignored facts so IPMI NIC is not created during discovery? Does it help?

On Wed, May 3, 2017 at 10:54 AM, Lukas Zapletal lz...@redhat.com >>>>>>>> wrote:

Jacek, for 1.15 there is another bug for autoprovisioning that has
been fixed in RC2:

Bug #19409: Auto provision does not work after taxonomy fix - Discovery - Foreman

Try with RC2 please. Anyway, one questions for all of you - how
does Foreman recognize your NICs after host is discovered?

Can you make screenshot of recognized NICs in the UI (discovered
host detail page)? Interested in which interface is set as
primary/provisioning.

Also which subnet has been detected? Does it match
primary/provisioning NIC? Is TFTP associated with this subnet?

What version of the FDI (image) do you use? If this is a
regression can you try with older version?

Initially I thought it’s caused by domain but that was wrong
assumption.

On Fri, Apr 28, 2017 at 12:27 PM, Jacek Mierzwa <jmie...@lbisa.com >>>>>>>>> > wrote:

I have tested auto-provisioning in 1.15 RC1.
Now it also matters if hostname pattern is used in discovery rule.

No hostname in discovery rule:

auto-provision does NOT create PXE file

manually select ‘Build’ on auto-provisioned host = PXE file
created!

manually select ‘Rebuild config’ on auto-privisioned host =
nothing

Hostname pattern used in discovery rule:

auto-provision does NOT create PXE file

manually select ‘Build’ on auto-provisioned host = no PXE file

hostname reverted to default (macXXXXXXXXXX)

manually select ‘Rebuild config’ on auto-privisioned host = no
PXE file + hostname reverted to default (macXXXXXXXXXX)

after the hostname is reverted to default:

manually select ‘Build’ on host = no PXE file

manually select ‘Rebuild config’ on host = PXE file created!

I think this goes beyond tftp.rb :S

On Tue, Apr 25, 2017 at 6:40 PM, Chad Schroeder < >>>>>>>>>> chads.finis...@gmail.com> wrote:

Lukas,

Hope this helps:

On initial discovery, the results of tftp_ready? are:
host.nil: false
host.managed: false

Clicking “Auto Provision” on the discovered host in the
"Discovered Hosts" menu:
host.nil: false
host.managed: false

Clicking “Edit” on the host in “All Hosts” menu and then
clicking submit:
host.nil: false
host.managed: true
managed: true
provision: true
host: mac00224d4fb56a.sub.domain.net
host.operatingsystem: CentOS 7.3.1611
host.pxe_loader.present: true
pxe_build?: true
SETTINGS[:unattended]: true

Chad

On Friday, April 21, 2017 at 8:13:18 AM UTC-5, Lukas Zapletal >>>>>>>>>>> wrote:

Ok thanks, I can see that either TFTP nor DHCP steps are not
getting orchestrated at all. I suspect that this returns false:

https://github.com/theforeman/foreman/blob/develop/app/model
s/concerns/orchestration/tftp.rb#L21

Maybe if you are able to break up the tftp_ready? method into
multiple lines and do some debug logger outputs of all individual
statements in there to see which does not trigger TFTP orchestration.

Strange is we should see DHCP orchestration but that does not
happen as well. Are NICs created correctly? Is there a subnet set?

Unfortunately I have engagement at customer site for whole
week, I will carry on the week after. We need to solve this.

On Wed, Apr 19, 2017 at 4:58 PM, Chad Schroeder < >>>>>>>>>>>> chads.finis...@gmail.com> wrote:

I’m not sure I follow what your asking for Lukas.

On Wednesday, April 19, 2017 at 8:50:21 AM UTC-5, Lukas >>>>>>>>>>>>> Zapletal wrote:

Jacek, I apologize but what I meant was:

http://projects.theforeman.org/projects/foreman/wiki/Trouble
shooting#Enable-detailed-SQL-logger-for-orchestration-messag
es

Chad, it looks like setting (a fake) domain did not help to
Jacek, can you try it? Did it help in your case? Associate Subnet with a
Domain and then set it in the Hostgroup.

LZ

On Wed, Apr 19, 2017 at 2:51 PM, Jacek Mierzwa < >>>>>>>>>>>>>> jmie...@lbisa.com> wrote:

And here is Foreman app debug-level log from 'successful’
auto-provision (no PXE file appears).

On Wed, Apr 19, 2017 at 2:13 PM, Jacek Mierzwa < >>>>>>>>>>>>>>> jmie...@lbisa.com> wrote:

Here’s the SQL debug log from ‘successful’ auto-provision
(no PXE file appears).
Please find attached.

Thanks/Regards

On Wed, Apr 19, 2017 at 1:21 PM, Lukas Zapletal < >>>>>>>>>>>>>>>> lz...@redhat.com> wrote:

Ok I finally reproduced.

When domain is blank, autoprovisioning fails for no
apparent reason,
logs are empty, something fails during orchestration and
hosts are
getting discovered again (which fails since managed host
already
exists).

Bug #19313: Auto-provisioning does not orchestrate TFTP - Discovery - Foreman

I will do my best to fix it this week, but I am on travel
the week
after, crossing my fingers.

LZ

On Thu, Apr 13, 2017 at 4:28 PM, Garreat < >>>>>>>>>>>>>>>>> jmie...@fgtsa.com> wrote:

I experience this issue.
After clicking ‘auto-provisioning’ on a discovered host,
the host entry is
created, the host reboots - but only to enter Foreman
Discovery Image PXE
loop.
My TFTP proxy is in healthy status as I can recreate PXE
default no prob.

Now answering your checklist:

host is managed - yes - OK

provision method is “build” and not “image” - how to
check this? I can’t
see the ‘build mode’ checkbox for the newly created host

host has operating system set - yes (inherited from
host group) - OK

host has pxe loader flag present (not set to blank or
None) - how to check
this?

host has one provisioning NIC with valid MAC address -
yes it does - OK

a subnet is associated with the provisioning NIC - it
is, but it’s a
subnet different than the one declared in machine’s host
group

the subnet has TFTP feature turned on - it does, and
it’s the same TFTP
proxy as in the subnet that I wanted

Also, the ‘domain’ is blank for the fresh created host.
The OS assigned to this host group has a valid PXElinux
template selected.

Assume I’m not making any manual changes:

‘Build host’ does nothing

‘Rebuild config’ creates a PXE mac-template on TFTP
immediatly

facter -j output attached

Thanks / Regards / Greetings

W dniu wtorek, 11 kwietnia 2017 10:28:17

Jacek_Mierzwa · May 15, 2017, 2:52pm

/usr/share/foreman/vendor/ruby/2.3.0/gems/foreman_discovery-9.0.0/app/controllers/concerns/foreman/controller/discovered_extensions.rb

That's the file I have modified. Content:

github.com

lzap/foreman_discovery/blob/d25c931e6427405cad16c01ebe7163d24e764eb2/app/controllers/concerns/foreman/controller/discovered_extensions.rb

module Foreman::Controller::DiscoveredExtensions
  extend ActiveSupport::Concern

  # return auto provision rule or false when not present
  def find_discovery_rule host
    raise(::Foreman::Exception.new(N_("Unable to find a discovery rule, no host provided (check permissions)"))) if host.nil?
    Rails.logger.debug "Finding auto discovery rule for host #{host.name} (#{host.id})"
    # rule with *lower* priority wins (older wins for same priority)
    DiscoveryRule.where(:enabled => true).reorder(:priority, :created_at).each do |rule|
      max = rule.max_count
      usage = rule.hosts.size
      Rails.logger.debug "Found rule #{rule.name} (#{rule.id}) [#{usage}/#{max}]"
      # if the rule has free slots
      if max == 0 || usage < max
        # try to match the search
        begin
          if Host::Discovered.where(:id => host.id).search_for(rule.search).size > 0
            if validate_rule_by_taxonomy(rule, host)
              Rails.logger.info "Match found for host #{host.name} (#{host.id}) rule #{rule.name} (#{rule.id})"
              return rule

This file has been truncated. show original

lzap · May 17, 2017, 8:53am

I also found that my patch does not work well. Still trying to find
nice solution, but we at least found the regression which caused this.
Try to comment out this line:

github.com/theforeman/foreman_discovery

Fixes #19313 - autoprovisioning NIC association fixed

theforeman:develop ← lzap:autoprovisioning-association-19313

opened 01:28PM - 15 May 17 UTC

lzap

+112 -52

After discovered host is converted to Managed, associated NICs still have their …associations set to the original record from the database (`Host::Discovered`), which led the `host.managed?` statement fail in `tftp_ready?` method in TFTP orchestration. This led to TFTP orchestration to be skipped completely, so I added a statement to set the appropriate assotiation explicitly during auto provisioning. This is a regression and I cannot find the root cause of this, it worked previously. We have reports that both 1.14 and 1.15 are broken.

This should help now.

···

On Mon, May 15, 2017 at 4:52 PM, Jacek Mierzwa wrote: > /usr/share/foreman/vendor/ruby/2.3.0/gems/foreman_discovery-9.0.0/app/controllers/concerns/foreman/controller/discovered_extensions.rb > > That's the file I have modified. Content: > https://github.com/lzap/foreman_discovery/blob/d25c931e6427405cad16c01ebe7163d24e764eb2/app/controllers/concerns/foreman/controller/discovered_extensions.rb > > -- > 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+unsubscribe@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.

–
Later,
Lukas @lzap Zapletal

Jacek_Mierzwa · May 22, 2017, 1:33pm

Sorry I took few days off.

Anyway, just tested. Using the most recent version of
discovered_extensions.rb:

github.com

lzap/foreman_discovery/blob/375d10bb42a9b9d2f010f7f64c0f8ed2bd4a91fc/app/controllers/concerns/foreman/controller/discovered_extensions.rb

module Foreman::Controller::DiscoveredExtensions
  extend ActiveSupport::Concern

  # return auto provision rule or false when not present
  def find_discovery_rule host
    raise(::Foreman::Exception.new(N_("Unable to find a discovery rule, no host provided (check permissions)"))) if host.nil?
    Rails.logger.debug "Finding auto discovery rule for host #{host.name} (#{host.id})"
    # rule with *lower* priority wins (older wins for same priority)
    DiscoveryRule.where(:enabled => true).reorder(:priority, :created_at).each do |rule|
      max = rule.max_count
      usage = rule.hosts.size
      Rails.logger.debug "Found rule #{rule.name} (#{rule.id}) [#{usage}/#{max}]"
      # if the rule has free slots
      if max == 0 || usage < max
        # try to match the search
        begin
          if Host::Discovered.where(:id => host.id).search_for(rule.search).size > 0
            if validate_rule_by_taxonomy(rule, host)
              Rails.logger.info "Match found for host #{host.name} (#{host.id}) rule #{rule.name} (#{rule.id})"
              return rule

This file has been truncated. show original

.
The result is negative – still need the same old procedure.

···

On Wed, May 17, 2017 at 10:53 AM, Lukas Zapletal wrote:

I also found that my patch does not work well. Still trying to find
nice solution, but we at least found the regression which caused this.
Try to comment out this line:

https://github.com/theforeman/foreman_discovery/pull/346/files#diff-
d165f1f7d8058930cfef75cad203b33eR8

This should help now.

On Mon, May 15, 2017 at 4:52 PM, Jacek Mierzwa jmierzwa@lbisa.com wrote:

/usr/share/foreman/vendor/ruby/2.3.0/gems/foreman_discovery-9.0.0/app/
controllers/concerns/foreman/controller/discovered_extensions.rb

That’s the file I have modified. Content:
https://github.com/lzap/foreman_discovery/blob/
d25c931e6427405cad16c01ebe7163d24e764eb2/app/controllers/
concerns/foreman/controller/discovered_extensions.rb

–
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+unsubscribe@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.

–
Later,
Lukas @lzap Zapletal

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

lzap · May 23, 2017, 11:53am

Hey Jacek,

the patch has been tested and merged, what exactly does not work for you?

Do not use whole file that will unlikely work with the older version, just
comment out the one line in the 1.15 version of the file:

#host.clear_association_cache

github.com/theforeman/foreman_discovery

Fixes #19313 - autoprovisioning NIC association fixed

theforeman:develop ← lzap:autoprovisioning-association-19313

opened 01:28PM - 15 May 17 UTC

lzap

+112 -52

After discovered host is converted to Managed, associated NICs still have their …associations set to the original record from the database (`Host::Discovered`), which led the `host.managed?` statement fail in `tftp_ready?` method in TFTP orchestration. This led to TFTP orchestration to be skipped completely, so I added a statement to set the appropriate assotiation explicitly during auto provisioning. This is a regression and I cannot find the root cause of this, it worked previously. We have reports that both 1.14 and 1.15 are broken.

···

On Mon, May 22, 2017 at 3:33 PM, Jacek Mierzwa wrote:

Sorry I took few days off.

Anyway, just tested. Using the most recent version of
discovered_extensions.rb: https://github.com/lzap/foreman_discovery/blob/
375d10bb42a9b9d2f010f7f64c0f8ed2bd4a91fc/app/controllers/
concerns/foreman/controller/discovered_extensions.rb .
The result is negative – still need the same old procedure.

On Wed, May 17, 2017 at 10:53 AM, Lukas Zapletal lzap@redhat.com wrote:

I also found that my patch does not work well. Still trying to find
nice solution, but we at least found the regression which caused this.
Try to comment out this line:

Fixes #19313 - autoprovisioning NIC association fixed by lzap · Pull Request #346 · theforeman/foreman_discovery · GitHub
es#diff-d165f1f7d8058930cfef75cad203b33eR8

This should help now.

On Mon, May 15, 2017 at 4:52 PM, Jacek Mierzwa jmierzwa@lbisa.com >> wrote:

/usr/share/foreman/vendor/ruby/2.3.0/gems/foreman_discovery-
9.0.0/app/controllers/concerns/foreman/controller/
discovered_extensions.rb

That’s the file I have modified. Content:
GitHub - lzap/foreman_discovery at d25c931e6427405cad16c01ebe7163d24e764eb2
05cad16c01ebe7163d24e764eb2/app/controllers/concerns/
foreman/controller/discovered_extensions.rb

–
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+unsubscribe@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.

–
Later,
Lukas @lzap Zapletal

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

–
Later,
Lukas @lzap Zapletal

Jacek_Mierzwa · May 23, 2017, 3:20pm

It's working! Thank you Lukas!

In case anyone wondering - at this moment it's enough to install
1.15.0 + comment
out line 8 in file:
/usr/share/foreman/vendor/ruby/2.3.0/gems/foreman_discovery-9.0.0/app/services/foreman_discovery/host_converter.rb

(that's for Debian, not sure about other OSes)

Will keep an eye on this in 1.15.1+. Thanks!

···

On Tue, May 23, 2017 at 1:53 PM, Lukas Zapletal wrote:

Hey Jacek,

the patch has been tested and merged, what exactly does not work for you?

Do not use whole file that will unlikely work with the older version, just
comment out the one line in the 1.15 version of the file:

#host.clear_association_cache

https://github.com/theforeman/foreman_discovery/pull/346/files#diff-
d165f1f7d8058930cfef75cad203b33eL8

On Mon, May 22, 2017 at 3:33 PM, Jacek Mierzwa jmierzwa@lbisa.com wrote:

Sorry I took few days off.

Anyway, just tested. Using the most recent version of
discovered_extensions.rb: https://github.com/lzap/foreman_di
scovery/blob/375d10bb42a9b9d2f010f7f64c0f8ed2bd4a91fc/app/
controllers/concerns/foreman/controller/discovered_extensions.rb .
The result is negative – still need the same old procedure.

On Wed, May 17, 2017 at 10:53 AM, Lukas Zapletal lzap@redhat.com wrote:

I also found that my patch does not work well. Still trying to find
nice solution, but we at least found the regression which caused this.
Try to comment out this line:

https://github.com/theforeman/foreman_discovery/pull/346/fil
es#diff-d165f1f7d8058930cfef75cad203b33eR8

This should help now.

On Mon, May 15, 2017 at 4:52 PM, Jacek Mierzwa jmierzwa@lbisa.com >>> wrote:

/usr/share/foreman/vendor/ruby/2.3.0/gems/foreman_discovery-
9.0.0/app/controllers/concerns/foreman/controller/discovered
_extensions.rb

That’s the file I have modified. Content:
https://github.com/lzap/foreman_discovery/blob/d25c931e64274
05cad16c01ebe7163d24e764eb2/app/controllers/concerns/foreman
/controller/discovered_extensions.rb

–
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+unsubscribe@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.

–
Later,
Lukas @lzap Zapletal

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

–
Later,
Lukas @lzap Zapletal

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

Chad_Schroeder · May 31, 2017, 2:46pm

I was able to get auto-provisioning to work as well. Thank you Lukas!

···

On Tuesday, May 23, 2017 at 6:53:28 AM UTC-5, Lukas Zapletal wrote: > > Hey Jacek, > > the patch has been tested and merged, what exactly does not work for you? > > Do not use whole file that will unlikely work with the older version, just > comment out the one line in the 1.15 version of the file: > > #host.clear_association_cache > > > https://github.com/theforeman/foreman_discovery/pull/346/files#diff-d165f1f7d8058930cfef75cad203b33eL8 > > > > On Mon, May 22, 2017 at 3:33 PM, Jacek Mierzwa > wrote: > >> Sorry I took few days off. >> >> Anyway, just tested. Using the most recent version of >> discovered_extensions.rb: >> https://github.com/lzap/foreman_discovery/blob/375d10bb42a9b9d2f010f7f64c0f8ed2bd4a91fc/app/controllers/concerns/foreman/controller/discovered_extensions.rb >> . >> The result is negative -- still need the same old procedure. >> >> >> On Wed, May 17, 2017 at 10:53 AM, Lukas Zapletal > > wrote: >> >>> I also found that my patch does not work well. Still trying to find >>> nice solution, but we at least found the regression which caused this. >>> Try to comment out this line: >>> >>> >>> https://github.com/theforeman/foreman_discovery/pull/346/files#diff-d165f1f7d8058930cfef75cad203b33eR8 >>> >>> This should help now. >>> >>> On Mon, May 15, 2017 at 4:52 PM, Jacek Mierzwa >> > wrote: >>> > >>> /usr/share/foreman/vendor/ruby/2.3.0/gems/foreman_discovery-9.0.0/app/controllers/concerns/foreman/controller/discovered_extensions.rb >>> > >>> > That's the file I have modified. Content: >>> > >>> https://github.com/lzap/foreman_discovery/blob/d25c931e6427405cad16c01ebe7163d24e764eb2/app/controllers/concerns/foreman/controller/discovered_extensions.rb >>> > >>> > -- >>> > 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-user...@googlegroups.com . >>> > To post to this group, send email to forema...@googlegroups.com >>> . >>> > Visit this group at https://groups.google.com/group/foreman-users. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> Later, >>> Lukas @lzap Zapletal >>> >> >> >> >> -- >> >> *Jacek Mierzwa* | Systems Integration Engineer >> >> Platform Management Division >> >> >> >> > > > -- > Later, > Lukas @lzap Zapletal >

lzap · May 24, 2017, 6:40am

Thanks, Disovery 9.1 will go out soon to fix this, we have few more bugs we
want to fix before doing the release.

LZ

···

On Tue, May 23, 2017 at 5:20 PM, Jacek Mierzwa wrote:

It’s working! Thank you Lukas!

In case anyone wondering - at this moment it’s enough to install 1.15.0 + comment
out line 8 in file:

/usr/share/foreman/vendor/ruby/2.3.0/gems/foreman_discovery-9.0.0/app/services/foreman_discovery/host_converter.rb

(that’s for Debian, not sure about other OSes)

Will keep an eye on this in 1.15.1+. Thanks!

On Tue, May 23, 2017 at 1:53 PM, Lukas Zapletal lzap@redhat.com wrote:

Hey Jacek,

the patch has been tested and merged, what exactly does not work for you?

Do not use whole file that will unlikely work with the older version,
just comment out the one line in the 1.15 version of the file:

#host.clear_association_cache

https://github.com/theforeman/foreman_discovery/pull/346/fil
es#diff-d165f1f7d8058930cfef75cad203b33eL8

On Mon, May 22, 2017 at 3:33 PM, Jacek Mierzwa jmierzwa@lbisa.com >> wrote:

Sorry I took few days off.

Anyway, just tested. Using the most recent version of
discovered_extensions.rb: https://github.com/lzap/foreman_di
scovery/blob/375d10bb42a9b9d2f010f7f64c0f8ed2bd4a91fc/app/co
ntrollers/concerns/foreman/controller/discovered_extensions.rb .
The result is negative – still need the same old procedure.

On Wed, May 17, 2017 at 10:53 AM, Lukas Zapletal lzap@redhat.com >>> wrote:

I also found that my patch does not work well. Still trying to find
nice solution, but we at least found the regression which caused this.
Try to comment out this line:

https://github.com/theforeman/foreman_discovery/pull/346/fil
es#diff-d165f1f7d8058930cfef75cad203b33eR8

This should help now.

On Mon, May 15, 2017 at 4:52 PM, Jacek Mierzwa jmierzwa@lbisa.com >>>> wrote:

/usr/share/foreman/vendor/ruby/2.3.0/gems/foreman_discovery-
9.0.0/app/controllers/concerns/foreman/controller/discovered
_extensions.rb

That’s the file I have modified. Content:
https://github.com/lzap/foreman_discovery/blob/d25c931e64274
05cad16c01ebe7163d24e764eb2/app/controllers/concerns/foreman
/controller/discovered_extensions.rb

–
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+unsubscribe@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.

–
Later,
Lukas @lzap Zapletal

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

–
Later,
Lukas @lzap Zapletal

–

Jacek Mierzwa | Systems Integration Engineer

Platform Management Division

–
Later,
Lukas @lzap Zapletal