[foreman-dev] Question about defaults for VM memory
Hello, How does foreman decide what the defaults are for memory when provision VMs via the webui? Sometimes when creating VMs to test provisioning configs, I forget to adjust to memory (I usually use about 2 gig to be safe). Foreman defaults to 768MB. I am wondering if that is enough, RHEL Kickstart for example seems to have issues even with 1 gig. We don't seem to have anyway right now of making the defaults tied to the OSs recommendations. I can create an RFE to raise the default, but I figure I would ask here first to see what peoples thoughts where. Thanks, -Perry -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] HTTPS Username / Password authentication in foreman_templates
Are you referring the to the foreman repos hosted on GitHub[1] ? You should be able to do it if you have a github account: https://help.github.com/articles/https-cloning-errors/ Hope this helps --Perry [1] https://github.com/theforeman On Fri, Apr 21, 2017 at 10:05 AM, Bernhard Suttner wrote: > Hi, > > is it already possible to use username / password authentication to access > the HTTPS-based git repository? > > If this is not the case, I'm happy that someone provides some information > how to do it. I would then have a look on it. > > Best regards, > Bernhard > > -- > ATIX - The Linux & Open Source Company > www.atix.de > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Retire the RFC repo?
I also have not made a contribution to the RFC repo, but from time to time have read others. I like the idea of the RFC repo, but wonder if it could be better organized. One frustration I have with it is it is if you want to get a full idea of new and upcoming ideas, you have to browse each individual fork and there is no central index page. Perhaps some sort of wiki-like page with a central index of both "accepted" and "in progress" rfcs would be better? Thoughts? On Wed, Mar 15, 2017 at 9:00 AM, John Mitsch wrote: > I have an open design in the RFC repo that contains screenshots and > feedback that I still plan to implement. I've kept it open due to some > refactoring that has to happen before it can be implemented. > > I like having a central place that I can design out a feature with other > developers and UX team. Its nice to be able to refer back to it months > later without having to hunt down a thread and scroll through it. It also > makes linking to screenshots and comments much easier. > > I'm also open to other suggestions besides the mailing list, but my vote > is to keep the RFC repo > > John Mitsch > Red Hat Engineering > (860)-967-7285 <(860)%20967-7285> > irc: jomitsch > > On Wed, Mar 15, 2017 at 8:07 AM, Eric D Helms > wrote: > >> I also like the RFC repository. I have not merged or closed a lot of my >> RFCs because I consider the designs to still be open discussions that need >> re-visting and continued visibility. The ability to comment on specific >> issues and have multiple threads going makes it much easier to follow than >> a mailing list email IMO. >> >> On Wed, Mar 15, 2017 at 7:57 AM, Justin Sherrill >> wrote: >> >>> >>> >>> On 03/13/2017 07:10 AM, Tomas Strachota wrote: >>> For me the biggest advantage of RFC repo over design discussions on mailing list is that when you come back to it later, you immediately see the latest state of the proposal without any need for reading through the whole email thread. At the same time, when you what to see the whole discussion you can display the outdated comments and older commits. Sending/receiving comments in form of code reviews is quite natural for me, but that's matter of personal preference. In my opinion both described issues (RFCs not being closed and design decisions without RFCs) aren't connected with github reviews but with the process around. Moving back to mailing lists won't help us with that. Therefore I'd keep RFC repo and rather work on defining how we decide on accepting/rejecting RFCs and who's responsible for keeping an eye on that. >>> I also like the RFC repo. As someone that opened an RFC but never >>> 'closed' it, it was mostly due to time, but I still plan to revisit it in >>> the future. I'm not sure that its a 'bad' thing to have open RFCs (although >>> we could auto close them after some months of inactivity). Similarly on >>> the mailing list you'd just end up with discussions that never go anywhere. >>> >>> I'd be interested in other proposals, but like Tomas said, I don't think >>> moving to the mailing list would solve many of the issues. >>> >>> -Justin >>> >>> >>> >>> T. On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker wrote: > Hello, > > About a year ago, we decided to try using a new system for discussing > design > decisions prior to making changes, by creating a repo for RFCs [1]. > Part of > the problem was that when discussing on the mailing list, discussions > tended > to die out without a resolution, and eventually whoever wrote the code > made > the decision (or not). > Since then, there have been about 30 proposals made in the repository. > 22 of > them are still open, most with no activity for months. > So I feel fairly safe to say that this change has not led to the wanted > result of getting decisions made faster or with more discussion. A > significant part of the proposals have less then 10 comments, in many > cases > all from just one or two respondents. Eventually proposals are still > decided > on only when someone goes ahead, writes the code and gets it merged. > This has also led to some discussions taking place without all of the > developers even knowing about them, as it would seem most don't follow > that > repo regularly, leading to repeated discussions when a PR is created. > In addition, some design decisions are still being made without going > through the RFC process, either by mailing list discussions or by > people > just creating PRs without any prior discussion. > > I'm not sure what we can do to increase peoples' involvement in these > discussions, nor what would be a better way of making design > decisions, but > let's try to figure it out since this attempt has not worked out as > expected > in my opinion. > > [1]
Re: [foreman-dev] Issues with support of IPv6/DHCPv6 in Smart-Proxy
It also worth mentioning Kea. Which is the ISC next generation DHCP server. http://kea.isc.org/wiki On Fri, Mar 10, 2017 at 9:40 AM, Dmitri Dolguikh wrote: > After thinking about support for ipv6 + dhcpv6 in smart-poxy and > Foreman some more, I realized that: > > - while host duid management is possible, it’s going to be somewhat > involved (quite a few different scenarios) and possibly fragile > - dhcp servers can be configured to update dns records automatically > using hostname (and domain name, if required) that client passes with > dhcp request (or names can be generated automatically) > - Foreman's main requirement is to set correct pxe boot options for > managed hosts > - multiple dhcp servers can co-exist on the same network/network > segment, with responses selected by the client based on server > precedence > > This leads me to think that having a small dhcp server (that we can > interface with using a convenient set of api) dedicated to handling > pxe requests in a given network segment and ignoring all request is an > option that’s worth investigating. Turns out google has a project that > fits the bill (https://github.com/google/netboot). I’m trying to > establish a contact with project’s maintainers to find out about > dhcpv6 state (not currently implemented) and see if they need help. > > Cheers, > -d > > On Wed, Mar 8, 2017 at 11:53 AM, Lukas Zapletal wrote: > > We can always try to offload the work on platform team, I've been > > pretty successful in getting some work done in iPXE project for > > example. The only issue is this can take some time until it gets to > > the other team backlog. > > > > To be honest, I don't know which path you should take. I'd vote for > > the cleanest one, that is trying to push proper IPv6 into ISC. If > > there's no politics behind it, I don't believe they would not want to > > have this kind of feature. On the other hand, they've been resisting > > quite long time now (IPv6 is old how much, 20 years? :-) > > > > Since you already did great amount of investigation in the IPv6 field, > > do you want to give dnsmasq a look in this regard? If this turns out > > to be a good workaround, maybe the ISC IPv6 would not be so hot topic > > then (when I finish with my provider). > > > > LZ > > > > On Tue, Mar 7, 2017 at 5:37 PM, Dmitri Dolguikh > wrote: > >> On Tue, Mar 7, 2017 at 4:28 PM, Perry Gagne wrote: > >>> Wouldn't it be better to add support for fixed-address6 or is there > some > >>> issue with doing that? > >> > >> It looks to me like ISC aren’t really interested in extending > >> functionality of dhcpd. On top of this, it may actually be more work > >> than it looks: both memory db serialization and omapi need updates > >> (the latter accepts fixed-addresses only atm). I have a pretty > >> high-level understanding of dhcpd codebase, but even at this level it > >> looks like omapi-related change might be quite big in scope. > >> > >> -d > >> > >>> > >>> On Tue, Mar 7, 2017 at 11:27 AM, Dmitri Dolguikh < > witlessb...@gmail.com> > >>> wrote: > >>>> > >>>> On Tue, Mar 7, 2017 at 4:22 PM, Perry Gagne > wrote: > >>>> >> This is definitely the case as far as ipv6-specific dhcpd > >>>> >> configuration goes. The code I linked to is responsible for > >>>> >> persistence of in-memory host records, and it doesn’t support ipv6 > at > >>>> >> all. > >>>> > > >>>> > Maybe I am confused. Are you trying to add support for > fixed-address6 or > >>>> > trying to work around the support not being there? > >>>> > >>>> The latter. > >>>> -d > >>>> > >>>> > > >>>> > On Mon, Mar 6, 2017 at 11:32 AM, Dmitri Dolguikh < > witlessb...@gmail.com> > >>>> > wrote: > >>>> >> > >>>> >> On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne > wrote: > >>>> >> > > >>>> >> > Doesn't ISC DHCPD use " fixed-address6", "range6", etc for > DHCPv6. > >>>> >> > The > >>>> >> > code > >>>> >> > you linked seems to be related to "fixed-address" which is the > ipv4 > >>>> >> > variant. > >>>> >> > > >>>> >> > >>>&g
Re: [foreman-dev] Issues with support of IPv6/DHCPv6 in Smart-Proxy
I'm sorry I was a little confused, I thought we were talking about adding support for fixed-address6 to foreman. Not adding better support to ISC DHCP On Tue, Mar 7, 2017 at 11:37 AM, Dmitri Dolguikh wrote: > On Tue, Mar 7, 2017 at 4:28 PM, Perry Gagne wrote: > > Wouldn't it be better to add support for fixed-address6 or is there some > > issue with doing that? > > It looks to me like ISC aren’t really interested in extending > functionality of dhcpd. On top of this, it may actually be more work > than it looks: both memory db serialization and omapi need updates > (the latter accepts fixed-addresses only atm). I have a pretty > high-level understanding of dhcpd codebase, but even at this level it > looks like omapi-related change might be quite big in scope. > > -d > > > > > On Tue, Mar 7, 2017 at 11:27 AM, Dmitri Dolguikh > > wrote: > >> > >> On Tue, Mar 7, 2017 at 4:22 PM, Perry Gagne wrote: > >> >> This is definitely the case as far as ipv6-specific dhcpd > >> >> configuration goes. The code I linked to is responsible for > >> >> persistence of in-memory host records, and it doesn’t support ipv6 at > >> >> all. > >> > > >> > Maybe I am confused. Are you trying to add support for fixed-address6 > or > >> > trying to work around the support not being there? > >> > >> The latter. > >> -d > >> > >> > > >> > On Mon, Mar 6, 2017 at 11:32 AM, Dmitri Dolguikh < > witlessb...@gmail.com> > >> > wrote: > >> >> > >> >> On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne > wrote: > >> >> > > >> >> > Doesn't ISC DHCPD use " fixed-address6", "range6", etc for DHCPv6. > >> >> > The > >> >> > code > >> >> > you linked seems to be related to "fixed-address" which is the ipv4 > >> >> > variant. > >> >> > > >> >> > >> >> This is definitely the case as far as ipv6-specific dhcpd > >> >> configuration goes. The code I linked to is responsible for > >> >> persistence of in-memory host records, and it doesn’t support ipv6 at > >> >> all. > >> >> > >> >> > Another question I have, does DHCP really need to be the one > >> >> > assigning > >> >> > the > >> >> > address? Should DHCP just be providing config info, and leave the > >> >> > address up > >> >> > to SLAAC? [1] > >> >> > >> >> It is possible to use autoconf for IPv6 address (self-)assignment and > >> >> rely on dhcp for host configuration only. I’m not sure how useful > >> >> autoconf is in larger networks (anyone has experience with this?), > but > >> >> it has a potential for making our life harder. > >> >> > >> >> -d > >> >> > >> >> > > >> >> > > >> >> > [1] https://tools.ietf.org/html/rfc3736 > >> >> > > >> >> > >> >> -- > >> >> You received this message because you are subscribed to the Google > >> >> Groups > >> >> "foreman-dev" group. > >> >> To unsubscribe from this group and stop receiving emails from it, > send > >> >> an > >> >> email to foreman-dev+unsubscr...@googlegroups.com. > >> >> For more options, visit https://groups.google.com/d/optout. > >> > > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups > >> > "foreman-dev" group. > >> > To unsubscribe from this group and stop receiving emails from it, send > >> > an > >> > email to foreman-dev+unsubscr...@googlegroups.com. > >> > For more options, visit https://groups.google.com/d/optout. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "foreman-dev" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to foreman-dev+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Issues with support of IPv6/DHCPv6 in Smart-Proxy
Wouldn't it be better to add support for fixed-address6 or is there some issue with doing that? On Tue, Mar 7, 2017 at 11:27 AM, Dmitri Dolguikh wrote: > On Tue, Mar 7, 2017 at 4:22 PM, Perry Gagne wrote: > >> This is definitely the case as far as ipv6-specific dhcpd > >> configuration goes. The code I linked to is responsible for > >> persistence of in-memory host records, and it doesn’t support ipv6 at > >> all. > > > > Maybe I am confused. Are you trying to add support for fixed-address6 or > > trying to work around the support not being there? > > The latter. > -d > > > > > On Mon, Mar 6, 2017 at 11:32 AM, Dmitri Dolguikh > > wrote: > >> > >> On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne wrote: > >> > > >> > Doesn't ISC DHCPD use " fixed-address6", "range6", etc for DHCPv6. The > >> > code > >> > you linked seems to be related to "fixed-address" which is the ipv4 > >> > variant. > >> > > >> > >> This is definitely the case as far as ipv6-specific dhcpd > >> configuration goes. The code I linked to is responsible for > >> persistence of in-memory host records, and it doesn’t support ipv6 at > >> all. > >> > >> > Another question I have, does DHCP really need to be the one assigning > >> > the > >> > address? Should DHCP just be providing config info, and leave the > >> > address up > >> > to SLAAC? [1] > >> > >> It is possible to use autoconf for IPv6 address (self-)assignment and > >> rely on dhcp for host configuration only. I’m not sure how useful > >> autoconf is in larger networks (anyone has experience with this?), but > >> it has a potential for making our life harder. > >> > >> -d > >> > >> > > >> > > >> > [1] https://tools.ietf.org/html/rfc3736 > >> > > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "foreman-dev" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to foreman-dev+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to foreman-dev+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Issues with support of IPv6/DHCPv6 in Smart-Proxy
> > This is definitely the case as far as ipv6-specific dhcpd > configuration goes. The code I linked to is responsible for > persistence of in-memory host records, and it doesn’t support ipv6 at > all. Maybe I am confused. Are you trying to add support for fixed-address6 or trying to work around the support not being there? On Mon, Mar 6, 2017 at 11:32 AM, Dmitri Dolguikh wrote: > On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne wrote: > > > > Doesn't ISC DHCPD use " fixed-address6", "range6", etc for DHCPv6. The > code > > you linked seems to be related to "fixed-address" which is the ipv4 > variant. > > > > This is definitely the case as far as ipv6-specific dhcpd > configuration goes. The code I linked to is responsible for > persistence of in-memory host records, and it doesn’t support ipv6 at > all. > > > Another question I have, does DHCP really need to be the one assigning > the > > address? Should DHCP just be providing config info, and leave the > address up > > to SLAAC? [1] > > It is possible to use autoconf for IPv6 address (self-)assignment and > rely on dhcp for host configuration only. I’m not sure how useful > autoconf is in larger networks (anyone has experience with this?), but > it has a potential for making our life harder. > > -d > > > > > > > [1] https://tools.ietf.org/html/rfc3736 > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Issues with support of IPv6/DHCPv6 in Smart-Proxy
Doesn't ISC DHCPD use " fixed-address6", "range6", etc for DHCPv6. The code you linked seems to be related to "fixed-address" which is the ipv4 variant. Another question I have, does DHCP really need to be the one assigning the address? Should DHCP just be providing config info, and leave the address up to SLAAC? [1] [1] https://tools.ietf.org/html/rfc3736 On Mon, Mar 6, 2017 at 10:53 AM, Dmitri Dolguikh wrote: > I'm working on adding support for IPv6/DHCPv6 on smart-proxy side, and > have come across several issues on which I'd like to hear your > thoughts. > > - It is not possible to assign ipv6 addresses to host records > (reservations) when ISC dhcpd is used. > > This is due to a limitation in host record serialization code in dhcpd > [1], which assumes that fixed address is always four octets long. > > I can see two possible approaches to compensate for this. One approach > would be to define host records without ip addresses. To ensure that > dns records stay valid, preferred-lifetime dhcpv6 option can be used > to extend lease duration. On host removal, lease state or lease expiry > date can be updated, or lease object can be destroyed altogether. As > ipv6 addresses are managed by a dhcp server in this scenario, after a > host has been created, an additional call to smart-proxy will be > required to discover its ip address. > > Another approach is to delegate dns record updates to dhcp server. > Client fqdn or partial hostname can be passed to dhcp server via > “client fqdn” option [2]. This approach may require additional client > configuration — I don’t know how various linux distributions configure > their dhcpclient (I think recent windows clients send this information > by default). > > > - It is difficult to determine host’s client id (dhcp unique > identifier, AKA DUID) > > its value depends on os, dhcp client, and even version of the client. > DUID is persistent across system reboots, but may be lost on os > (re)installation. [3] has more details on how various client generate > DUID. To simplify host management/reduce support issues, it might be > necessary to configure host DUID during system install, possibly by > using uuid value from system’s DMI table [4]. > > > - PXE uses client id (UUID/GUID) that is different from that of the host. > > This will result in two ipv6 addresses being allocated to every host > that uses PXE. One approach is allocate ipv6 addresses from different > pools with different preferred-lifetime options. In this approach PXE > pool would have very short lease durations. Clients that belong to the > PXE pool can be identified by the presence of “boot file url” dhcp > option. > > Another approach is to have smart-proxy act as a simple dhcp server. > It would answer dhcp requests containing “boot file url” itself and > ignore/relay all other requests to the main dhcp server. This approach > could result in less orchestration in Foreman: for example, with this > approach pxe boot configuration can be generated on demand and served > via http, without any config files created/updated on a tftp server. > > > > Thoughts? > -d > > > [1] https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a= > blob;f=server/db.c;h=94f1584fd44e17ac0dfecf9fc9e3fd3da01ecb8d;hb=HEAD#l395 > [2] https://tools.ietf.org/html/rfc4704#section-4 > [3] https://wiki.fysik.dtu.dk/it/IPv6_configuration#dhcpv6- > unique-identifier-duid > [4] https://wiki.fysik.dtu.dk/it/IPv6_configuration#id25 > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
