Re: Proposal to use repo files in Anaconda environment
On Thu, 2019-09-26 at 08:26 -0700, Brian C. Lane wrote: > On Thu, Sep 26, 2019 at 02:25:49PM +0200, jkone...@redhat.com wrote: > > On Fri, 2019-09-20 at 10:21 -0700, Brian C. Lane wrote: > > > On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkone...@redhat.com > > > wrote: > > [snip] > > > > With an updates.img solution like you are describing here is > > > there > > > anything > > > to be done? Can't it already drop new repos into > > > /etc/yum.repos.d/ or > > > /etc/anaconda.repos.d/ ? > > > > In general no, it should work without changes. That is a great > > benefit > > of this solution. The only thing is if we want to create a tool for > > the > > updates image creation. > > > > I was also thinking about a behavior nuances. Like, if we want to > > change default behavior of how Anaconda works with these > > repositories > > than it may be interesting to have a separate folder to found out > > these > > repositories. > > > > > With my lmc patch for certs I am doing something like this, but > > > only > > > with the cert files, not the repo files. updates.img > > > > > > https://github.com/weldr/lorax/pull/839 > > > > Our idea is to have everything as part of the updates image, repo > > files > > and certificates. > > > > > From the perspective of lmc no-virt mode and lorax-composer > > > (which > > > use anaconda directly) it would be most useful to add a --repo > > > and/or > > > --repodir cmdline option to anaconda that adds the repos to the > > > dnf > > > base > > > object, similar to the way that lorax does things: > > > > > > https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L114 > > > > > > updates.img doesn't help with these use cases. > > > > Seems interesting. I'm just thinking if we don't want to rather use > > configuration files for Anaconda. Not sure, it would require a > > change > > in the Anaconda but shouldn't be that hard. > > > > FYI: Configuration files were added to Anaconda recently to be able > > override behavior and it is the replacement for install classes. > > For > > you it would mean that you will create the configuration file (ini > > format) in the specified directory to tell us where to look for the > > repo files. > > > > There is also a question, is there a use for the --repodir which > > can't > > be solved by changing configuration files of Anaconda or otherwise > > what > > is the preferred way here? > > Oh, interesting! I wasn't aware of that, I'll take a look at it and > see > if I can make it work w/o any other changes. Yes, I think it will be interesting for your. However, we have to first implement the drop dir solution to avoid changing system anaconda configuration. It's on our TODO list and if you have any use for that now, we can make it higher priority. > > > > > I totally agree with the goals here, the repo command in > > > kickstart is > > > getting too long, but we need a way to handle special cases where > > > people > > > need access to more of the dnf options. > > > > > > At the same time I'm worried about the loss of information that > > > this > > > can > > > cause. Although I don't want to just dump dnf repo files into > > > kickstart > > > -- that defeats the purpose of making it (somewhat) disconnected > > > from > > > the > > > specific backends like yum vs dnf. > > > > I think you have the same even now. The default settings for Fedora > > depends on what variant are you using. Based on the environment you > > are > > using for the installation you will get the result. > > With kickstart you don't use the host environment's repos, unless you > specifically reference them (at least that's how it used to work). > eg. > you can enable the updates repo shipped on the boot.iso with 'repo > --name=updates' but if you don't do that the only repos used are the > ones in the kickstart. Yes that is true and it is still supported. Also you can set closest mirror without kickstart which will use pre-installed fedora repo files . That is basically the same as repo --name solution but from GUI. The point is that this feature depends on a stage2 environment and that is exactly what I meant. Thanks to this you are able to create KS file which don't have all the information. I'm not convinced that adding repo files more support from Anaconda will make this situation any worse. > > > > Another option may be to use %pre to write out the repo files > > > (I'm > > > not > > > sure if anaconda will currently pick those up, but it should be > > > possible > > > to fix if it doesn't). > > > > We are thinking about tweaking existing sections to be able to just > > dump a general file somewhere (could be a script which will be run > > in > > the other section or repo file). That would be better solution for > > the > > %pre sections repo dumping. It would look like: > > > > %pre --dump-file=/anaconda.repos.d/my.repo > > > > %end > > > > However, this will not solve GPG key files or certificates so we > > are > > more thinking
Re: Proposal to use repo files in Anaconda environment
On Thu, Sep 26, 2019 at 02:25:49PM +0200, jkone...@redhat.com wrote: > On Fri, 2019-09-20 at 10:21 -0700, Brian C. Lane wrote: > > On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkone...@redhat.com wrote: [snip] > > With an updates.img solution like you are describing here is there > > anything > > to be done? Can't it already drop new repos into /etc/yum.repos.d/ or > > /etc/anaconda.repos.d/ ? > > In general no, it should work without changes. That is a great benefit > of this solution. The only thing is if we want to create a tool for the > updates image creation. > > I was also thinking about a behavior nuances. Like, if we want to > change default behavior of how Anaconda works with these repositories > than it may be interesting to have a separate folder to found out these > repositories. > > > > > With my lmc patch for certs I am doing something like this, but only > > with the cert files, not the repo files. updates.img > > > > https://github.com/weldr/lorax/pull/839 > > Our idea is to have everything as part of the updates image, repo files > and certificates. > > > > > From the perspective of lmc no-virt mode and lorax-composer (which > > use anaconda directly) it would be most useful to add a --repo and/or > > --repodir cmdline option to anaconda that adds the repos to the dnf > > base > > object, similar to the way that lorax does things: > > > > https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L114 > > > > updates.img doesn't help with these use cases. > > Seems interesting. I'm just thinking if we don't want to rather use > configuration files for Anaconda. Not sure, it would require a change > in the Anaconda but shouldn't be that hard. > > FYI: Configuration files were added to Anaconda recently to be able > override behavior and it is the replacement for install classes. For > you it would mean that you will create the configuration file (ini > format) in the specified directory to tell us where to look for the > repo files. > > There is also a question, is there a use for the --repodir which can't > be solved by changing configuration files of Anaconda or otherwise what > is the preferred way here? Oh, interesting! I wasn't aware of that, I'll take a look at it and see if I can make it work w/o any other changes. > > I totally agree with the goals here, the repo command in kickstart is > > getting too long, but we need a way to handle special cases where > > people > > need access to more of the dnf options. > > > > At the same time I'm worried about the loss of information that this > > can > > cause. Although I don't want to just dump dnf repo files into > > kickstart > > -- that defeats the purpose of making it (somewhat) disconnected from > > the > > specific backends like yum vs dnf. > > I think you have the same even now. The default settings for Fedora > depends on what variant are you using. Based on the environment you are > using for the installation you will get the result. With kickstart you don't use the host environment's repos, unless you specifically reference them (at least that's how it used to work). eg. you can enable the updates repo shipped on the boot.iso with 'repo --name=updates' but if you don't do that the only repos used are the ones in the kickstart. > > Another option may be to use %pre to write out the repo files (I'm > > not > > sure if anaconda will currently pick those up, but it should be > > possible > > to fix if it doesn't). > > We are thinking about tweaking existing sections to be able to just > dump a general file somewhere (could be a script which will be run in > the other section or repo file). That would be better solution for the > %pre sections repo dumping. It would look like: > > %pre --dump-file=/anaconda.repos.d/my.repo > > %end > > However, this will not solve GPG key files or certificates so we are > more thinking about this for an image creation which in general can > generate the repo files in a drop dir and used that directory. Yeah, I'm not sure what the benefit there is, it's pretty easy to do a: %pre cat > /etc/rc.d/init.d/livesys << EOF STUFF AND THINGS EOF %end -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Proposal to use repo files in Anaconda environment
On Fri, 2019-09-20 at 10:21 -0700, Brian C. Lane wrote: > On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkone...@redhat.com wrote: > > Hello everyone, > > > > We (the Anaconda installer team) want to solve multiple problems by > > one > > solution and we want > > > > *YOUR FEEDBACK!* > > > > > > In short we are proposing to use custom repo files when configuring > > Anaconda for image creation instead of adding even more complexity > > to > > the kickstart repo command. For more details see the link below. > > > > Purpose of this mail is to give everyone interested in the topic a > > place to discuss our proposal to find out if we didn't miss > > something > > or better case, if you agree with it :). It could be that this is > > not > > applicable for Lorax / Pungi / live-cd tool in that case please > > write a > > response to the document. > > > > You can read details here: > > > > https://hackmd.io/@prJIqOTeSxC-W0RNGKIGbQ/ByzIz3kIH/edit > > > > Please, all the relevant comments should stay in the document if > > possible. If that solution won't work because of higher traffic > > then we > > will find a better solution but the point is to have everything on > > one > > place. > > Sorry, I really don't like the hackmd.io thing, we regularly use > email > for discussions like this and should continue the discussion on the > feoora-devel list. That's fine. I wanted to create a living document to have everything on one place but it looks that email is preferred. I don't mind moving the conversation here. > > With an updates.img solution like you are describing here is there > anything > to be done? Can't it already drop new repos into /etc/yum.repos.d/ or > /etc/anaconda.repos.d/ ? In general no, it should work without changes. That is a great benefit of this solution. The only thing is if we want to create a tool for the updates image creation. I was also thinking about a behavior nuances. Like, if we want to change default behavior of how Anaconda works with these repositories than it may be interesting to have a separate folder to found out these repositories. > > With my lmc patch for certs I am doing something like this, but only > with the cert files, not the repo files. updates.img > > https://github.com/weldr/lorax/pull/839 Our idea is to have everything as part of the updates image, repo files and certificates. > > From the perspective of lmc no-virt mode and lorax-composer (which > use anaconda directly) it would be most useful to add a --repo and/or > --repodir cmdline option to anaconda that adds the repos to the dnf > base > object, similar to the way that lorax does things: > > https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L114 > > updates.img doesn't help with these use cases. Seems interesting. I'm just thinking if we don't want to rather use configuration files for Anaconda. Not sure, it would require a change in the Anaconda but shouldn't be that hard. FYI: Configuration files were added to Anaconda recently to be able override behavior and it is the replacement for install classes. For you it would mean that you will create the configuration file (ini format) in the specified directory to tell us where to look for the repo files. There is also a question, is there a use for the --repodir which can't be solved by changing configuration files of Anaconda or otherwise what is the preferred way here? > > I totally agree with the goals here, the repo command in kickstart is > getting too long, but we need a way to handle special cases where > people > need access to more of the dnf options. > > At the same time I'm worried about the loss of information that this > can > cause. Although I don't want to just dump dnf repo files into > kickstart > -- that defeats the purpose of making it (somewhat) disconnected from > the > specific backends like yum vs dnf. I think you have the same even now. The default settings for Fedora depends on what variant are you using. Based on the environment you are using for the installation you will get the result. > > Another option may be to use %pre to write out the repo files (I'm > not > sure if anaconda will currently pick those up, but it should be > possible > to fix if it doesn't). We are thinking about tweaking existing sections to be able to just dump a general file somewhere (could be a script which will be run in the other section or repo file). That would be better solution for the %pre sections repo dumping. It would look like: %pre --dump-file=/anaconda.repos.d/my.repo %end However, this will not solve GPG key files or certificates so we are more thinking about this for an image creation which in general can generate the repo files in a drop dir and used that directory. Best Regards, Jirka ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: Proposal to use repo files in Anaconda environment
On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkone...@redhat.com wrote: > Hello everyone, > > We (the Anaconda installer team) want to solve multiple problems by one > solution and we want > > *YOUR FEEDBACK!* > > > In short we are proposing to use custom repo files when configuring > Anaconda for image creation instead of adding even more complexity to > the kickstart repo command. For more details see the link below. > > Purpose of this mail is to give everyone interested in the topic a > place to discuss our proposal to find out if we didn't miss something > or better case, if you agree with it :). It could be that this is not > applicable for Lorax / Pungi / live-cd tool in that case please write a > response to the document. > > You can read details here: > > https://hackmd.io/@prJIqOTeSxC-W0RNGKIGbQ/ByzIz3kIH/edit > > Please, all the relevant comments should stay in the document if > possible. If that solution won't work because of higher traffic then we > will find a better solution but the point is to have everything on one > place. Sorry, I really don't like the hackmd.io thing, we regularly use email for discussions like this and should continue the discussion on the feoora-devel list. With an updates.img solution like you are describing here is there anything to be done? Can't it already drop new repos into /etc/yum.repos.d/ or /etc/anaconda.repos.d/ ? With my lmc patch for certs I am doing something like this, but only with the cert files, not the repo files. updates.img https://github.com/weldr/lorax/pull/839 >From the perspective of lmc no-virt mode and lorax-composer (which use anaconda directly) it would be most useful to add a --repo and/or --repodir cmdline option to anaconda that adds the repos to the dnf base object, similar to the way that lorax does things: https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L114 updates.img doesn't help with these use cases. I totally agree with the goals here, the repo command in kickstart is getting too long, but we need a way to handle special cases where people need access to more of the dnf options. At the same time I'm worried about the loss of information that this can cause. Although I don't want to just dump dnf repo files into kickstart -- that defeats the purpose of making it (somewhat) disconnected from the specific backends like yum vs dnf. Another option may be to use %pre to write out the repo files (I'm not sure if anaconda will currently pick those up, but it should be possible to fix if it doesn't). -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Proposal to use repo files in Anaconda environment
Hello everyone, We (the Anaconda installer team) want to solve multiple problems by one solution and we want *YOUR FEEDBACK!* In short we are proposing to use custom repo files when configuring Anaconda for image creation instead of adding even more complexity to the kickstart repo command. For more details see the link below. Purpose of this mail is to give everyone interested in the topic a place to discuss our proposal to find out if we didn't miss something or better case, if you agree with it :). It could be that this is not applicable for Lorax / Pungi / live-cd tool in that case please write a response to the document. You can read details here: https://hackmd.io/@prJIqOTeSxC-W0RNGKIGbQ/ByzIz3kIH/edit Please, all the relevant comments should stay in the document if possible. If that solution won't work because of higher traffic then we will find a better solution but the point is to have everything on one place. Have a great day everyone, Jirka ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
