Skip to content

Conversation

@drkitty
Copy link
Contributor

@drkitty drkitty commented Apr 20, 2015

Resolves issue #966.

Changes:

  • In the "legacy" range mode, don't build classes that aren't allowed in any pools. The externally-visible behavior has not changed.
  • Add a new "standard" range mode (name suggestions are welcome) and make it the default. It makes a pool allow all dynamic interfaces in the range (using a single class per pool).
  • In the "known" range mode, don't include a line allowing the range's class(es). This doesn't change the externally-visible behavior because all interfaces with a subclass decl will also have a host decl, making them "known".
  • Remove some silly comments from the generated DHCP config (but not workgroup name comments; I know those are important).

drkitty added 4 commits April 16, 2015 12:54
The 'legacy' allow option now uses a single class where previously it
used several. The 'standard' allow option is the new default, because
'legacy' makes no sense and is probably a mistake anyway.
@drkitty
Copy link
Contributor Author

drkitty commented Apr 24, 2015

Still need to merge in the separate-DHCP-config changes from master (there are several conflicts).

Conflicts:
	cyder/core/ctnr/models.py
	cyder/cydhcp/build/builder.py
	cyder/cydhcp/vrf/models.py
	cyder/cydhcp/workgroup/models.py
@drkitty
Copy link
Contributor Author

drkitty commented Apr 28, 2015

Should be ready to go.

@drkitty
Copy link
Contributor Author

drkitty commented Apr 29, 2015

Note to self: I was supposed to leave the 'legacy' build process exactly the same. Revert it.

@drkitty
Copy link
Contributor Author

drkitty commented Apr 30, 2015

Looks like restoring the original 'legacy' behavior was easier than expected. The only difference now is that it doesn't print classes that aren't allowed anywhere.

@akeym
Copy link
Member

akeym commented Apr 30, 2015

Sounds fine to me. We shouldn't have been doing that in the first place.
Is there an easy way to tell what will be excluded? A manage.py shell
solution is fine by me.

On Thu, Apr 30, 2015 at 3:55 PM, drkitty notifications@github.com wrote:

Looks like restoring the original 'legacy' behavior was easier than
expected. The only difference now is that it doesn't print classes that
aren't allowed anywhere.


Reply to this email directly or view it on GitHub
#983 (comment).

@drkitty
Copy link
Contributor Author

drkitty commented May 1, 2015

I'll post a script shortly.

@drkitty
Copy link
Contributor Author

drkitty commented May 8, 2015

I'd recommend this be hand-verified. It's not too difficult to do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants