Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Sle15] AY setup written in first stage #520

Merged
merged 23 commits into from
Jul 21, 2017

Conversation

mchf
Copy link
Member

@mchf mchf commented Jun 9, 2017

  • DNS supported
  • /etc/hosts supported
  • Routing supported

See yast/aytests-tests#77 (DNS test)

@mchf mchf force-pushed the sle15-ay-network-in-first-stage branch 2 times, most recently from 79466b0 to 05a14a4 Compare June 9, 2017 12:36
@coveralls
Copy link

Coverage Status

Coverage increased (+0.03%) to 29.763% when pulling 05a14a4 on mchf:sle15-ay-network-in-first-stage into 641e67f on yast:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.06%) to 29.793% when pulling e03e09a on mchf:sle15-ay-network-in-first-stage into 641e67f on yast:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.06%) to 29.793% when pulling 58cc827 on mchf:sle15-ay-network-in-first-stage into 641e67f on yast:master.

@mchf mchf changed the title [WIP][Sle15] DNS ay setup written in first stage [Sle15] DNS ay setup written in first stage Jun 21, 2017
@mchf mchf changed the title [Sle15] DNS ay setup written in first stage [Sle15] AY setup written in first stage Jun 26, 2017
@coveralls
Copy link

Coverage Status

Coverage increased (+0.2%) to 29.921% when pulling 45601c4 on mchf:sle15-ay-network-in-first-stage into 641e67f on yast:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.2%) to 29.897% when pulling ca7768d on mchf:sle15-ay-network-in-first-stage into 641e67f on yast:master.

@@ -1,4 +1,12 @@
-------------------------------------------------------------------
Fri Jun 9 09:40:11 UTC 2017 - mfilka@suse.com

- Moving network setup in AY into 1s stage
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"1st"
Bug or feature number?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

currently not aware of any - the PBI contains no fate number

@kobliha: is there any fate request?


NetworkAutoYast.instance.configure_nics
end

# It does an automatic configuration of installed system
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK formerly this was not associated with AutoYaST. So we should explicitly point this out:

It works for both values of Mode.autoinst

BTW, what about autoupgrade? http://www.rubydoc.info/github/yast/yast-yast2/Yast/ModeClass

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

upgrade scenario ignores network setup ... but i'm not sure about autoupgrade - will check

# we neet to guarantee order of the items here
[host["host_address"] || "", host["names"] || []]
end
hosts_config = hosts_config.to_h.delete_if { |k, v| k.empty? || v.empty? }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This non-trivial FromAY-like section should go into its own method (class?) and be covered with tests.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well this is almost everything what configure_hosts does

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, now that the other configure_* methods are gone it makes less sense to split it off. Still, with all the "or empty" logic in here, tests are needed.

Also, how does this code relate to Import in host_auto? Do we need to "guarantee item order" also there?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Item order is most probably bad description here. I refer to "host_address" and "names". Each of these hash keys refer to a xml node. And this nodes can be ordered differently in the profile. We must guarantee that "host_address" is at first place.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this duplicates Host.Import . Is that one obsolete then?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, sorry, configure_submodule does call Import

#
# return {true, false, nil} "yes" => true, "no" => false, otherwise or not
# present => nil
def write_hostname_to_hosts
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A method named write_* that in fact calls SCR.Read?! I know it copies the sysconfig name but here I would prefix it with should_ or something.

Builtins.sleep(sl)
ProgressNextStage(_("Writing hostname...")) if gui
update_hostname
Builtins.sleep(0) if gui
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh, what?!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, consequence of some massive updating and code shifting and so on. I'll drop it.

SCR.Write(
path(".sysconfig.network.dhcp.WRITE_HOSTNAME_TO_HOSTS"),
@write_hostname ? "yes" : "no"
) if !@write_hostname
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug.

@mchf mchf force-pushed the sle15-ay-network-in-first-stage branch 4 times, most recently from 01e19ae to be9825b Compare July 11, 2017 10:55
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.1%) to 29.845% when pulling be9825b on mchf:sle15-ay-network-in-first-stage into 465fe0b on yast:master.

@mchf mchf force-pushed the sle15-ay-network-in-first-stage branch from be9825b to 766076d Compare July 11, 2017 11:06
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.1%) to 29.85% when pulling 766076d on mchf:sle15-ay-network-in-first-stage into 465fe0b on yast:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.1%) to 29.85% when pulling f7eb359 on mchf:sle15-ay-network-in-first-stage into 465fe0b on yast:master.

@mvidner
Copy link
Member

mvidner commented Jul 17, 2017

does host_auto#Import need similar code like configure_hosts?

@mchf
Copy link
Member Author

mchf commented Jul 20, 2017

# hosts => [
# # first <host_entry>
# {
# "hosts_address" => <ip>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. "host_address".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

end

# Returns networking section of current AY profile
def ay_networking_section
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO it would be more clear to replace this method by inlining ay_current_profile.fetch("networking", {})

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

regarding Host.Import see bellow

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in my POV "networking" section is used quite often so it deserved own method as a shortcut.

# we neet to guarantee order of the items here
[host["host_address"] || "", host["names"] || []]
end
hosts_config = hosts_config.to_h.delete_if { |k, v| k.empty? || v.empty? }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this duplicates Host.Import . Is that one obsolete then?

Copy link
Member

@mvidner mvidner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this PR mean that the lan_auto+host_auto clients are obsolete, as far as Write is concerned? And they are only useful for the AY config GUI? So /usr/share/YaST2/clients/ayast_setup.rb will no longer work for networking, or work differently ?


true
# expected format for Hosts.Import is { "ip" => [list, of, names] }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, and this must be documented there, in the API docs for Host.Import (not Hosts).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

@mchf
Copy link
Member Author

mchf commented Jul 20, 2017

Writing in first stage is experimental feature from my POV and is used only when second stage is disabled. Othewise _auto clients are used in second stage. See AY integration tests for some more details.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.2%) to 29.797% when pulling a8d5ee9 on mchf:sle15-ay-network-in-first-stage into 465fe0b on yast:master.

Copy link
Member

@mvidner mvidner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added tests b2b58c0 , but since you do this in your own repo, there is more work for you to merge them. Wanna push to the shared repo the next time?

@@ -1,4 +1,12 @@
-------------------------------------------------------------------
Fri Jul 11 09:40:11 UTC 2017 - mfilka@suse.com

- Moving network setup in AY into first stage
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this is a major thing we should have a public bug for this. I could not find one in https://trello.com/c/dxyLJ9c8/956-8-sle-15-%E2%9A%A1-autoyast-configure-the-whole-network-in-the-first-stage so should I create one?
Also, /etc/hosts should be mentioned.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.3%) to 30.241% when pulling 58bb702 on mchf:sle15-ay-network-in-first-stage into 465fe0b on yast:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.3%) to 30.241% when pulling b9c5e1a on mchf:sle15-ay-network-in-first-stage into 465fe0b on yast:master.

@mchf
Copy link
Member Author

mchf commented Jul 21, 2017

Thanks for the review

@mchf mchf merged commit 02d8e75 into yast:master Jul 21, 2017
@mchf mchf deleted the sle15-ay-network-in-first-stage branch July 21, 2017 08:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants