[ironic] A new project for useful deploy steps?
juliaashleykreger at gmail.com
Mon Feb 8 16:09:34 UTC 2021
I concur. The only thing with RFE's and patch approvals is I think we
should remember that we want it to be easy. So processes like RFEs may
not be helpful to a "oh, this tiny little thing makes a lot of sense"
sort of things, since it quickly becomes a situation where you spend
more time on the RFE than the patch itself.
On Mon, Feb 8, 2021 at 7:43 AM Ruby Loo <opensrloo at gmail.com> wrote:
> Hi Dmitry,
> Thanks for bringing this up! We discussed this in our weekly ironic meeting . The consensus there seems to be to keep the ideas in IPA (with priority=0). The additional code will be 'negligible' in size so ramdisk won't be bloated due to this. Also, it keeps things simple. Having a separate package means more maintenance overhead and confusion for our users.
> Would be good to hear from others, if they don't think this is a good idea. Otherwise, I'm looking forward to Dmitry's RFEs on this :)
>  http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2021-02-08.log.html#t2021-02-08T15:23:02
> On Mon, Feb 8, 2021 at 8:02 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
>> Hi all,
>> We have finally implemented in-band deploy steps (w00t!), and people started coming up with ideas. I have two currently:
>> 1) configure arbitrary kernel command line arguments via grub
>> 2) write NetworkManager configuration (for those not using cloud-init)
>> I'm not sure how I feel about putting these in IPA proper, seems like we may go down a rabbit hole here. But what about a new project (ironic-python-agent-extras?) with a hardware manager providing a collection of potentially useful deploy steps?
>> Or should we nonetheless just put them in IPA with priority=0?
>> Opinions welcome.
>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
More information about the openstack-discuss