Difference between revisions of "Meetings/Ironic"
Jay Faulkner (talk | contribs) (→Agenda for next meeting) |
Ishii.vanou (talk | contribs) (→Agenda for next meeting) |
||
Line 28: | Line 28: | ||
* RFE review (if necessary) | * RFE review (if necessary) | ||
* Open discussion | * Open discussion | ||
+ | ** Vulnerability handling policy in Ironic (vanou): After handling vulnerability of vendor driver library used in iRMC driver[https://nvd.nist.gov/vuln/detail/CVE-2022-2996], I feel it's better to have basic vulnerability handling policy in Ironic community doc. (I apologize add this topic not 2 days before weekly meeting. So it's OK to skip this topic next meeting if we have no time) | ||
+ | *** In this case, cause of vulnerability is in vendor driver library (python-scciclient used in iRMC driver). Ironic community has responsibility of code quality of each driver (e.g. iRMC driver). On the other hand, each vendor has responsibility of code quality of vendor driver library (e.g. python-scciclient) and maintains that library. So, after discussion[https://storyboard.openstack.org/#!/story/2009801] with community member, we decided to fix this through public process like ordinal bug fix process ('''''caution:''''' in general, fixing vulnerability should be done in private process until fix patch is released). | ||
+ | *** There can be 4 situation | ||
+ | **** '''cause of vulnerability is in code hosted in Ironic repository (i.e. driver code) :''' In this case, we may agree on fixing that in private process. | ||
+ | **** '''cause of vulnerability is in vendor driver library code (there is no need to modify Ironic code) :''' In this case, vendor fix vendor driver library and assign new version. Then, Ironic community just updates version requirement of vendor driver library in Ironic repository. And that can be done through usual public Ironic review/merge process. | ||
+ | **** '''cause of vulnerability is in vendor driver library code (Ironic code should be modified to apply vulnerability fix: e.g. fix of vendor library adds parameter to vendor library function and Ironic code should use that parameter to fix vulnerability) :''' Ideally, if both Ironic code and vendor driver library should be modified, vendor fixes vendor driver library in private process and keep that fix secret till fixing Ironic code finish. And Ironic community can review Ironic code modification in public process. Then, if Ironic community finishes review and is ready to merge, vendor publishes fix of vendor driver library and Ironic community merge fix at the same time. | ||
+ | **** '''cause of vulnerability is in both Ironic repository code and vendor driver library code :''' In this case, fix of both Ironic code and vendor driver library code should be done in private process. Then vendor publishes vendor driver library at the same time Ironic publishes Ironic code fix. | ||
== Previous meetings == | == Previous meetings == |
Revision as of 08:28, 23 January 2023
Contents
Weekly Ironic Project Team Meeting
If you're interested in bare metal deployments within OpenStack, please join our weekly discussion about the Ironic project! The one-hour weekly meetings start at 15:00 UTC on Mondays (as of March 28th, 2022), are held in the #openstack-ironic
room on ircs://irc.oftc.net:6697
, and are chaired by Jay Faulkner (JayF), Julia Kreger (TheJulia), Dmitry Tantsur (dtantsur), Riccardo Pittau (rpittau) or Iury Gregory (iurygregory).
NOTE: Meeting time is UTC based and may need to be adjusted based on local time zone changes, eg. as a result of daylight savings, which changes on different days in different countries.
- ICS (Calendar) file for the meeting. You can add this to your calendar.
- Eavesdrop meeting page
Anyone is welcome to add topics to the agenda. However, topics should be posted at least two (2) days before the meeting to give folks time to get context, and should include the IRC handle of the proposer and a link to further information. This gives everyone time to review any material ahead of time so we can use the meeting time for actual discussion. Requests to have a patch reviewed should not be a topic and instead should be covered during the Open Discussion portion of the meeting.
- Example topic: (devananda) Let's talk about zebras. Reference: http://en.wikipedia.org/wiki/Zebra
Next Meeting
Meetings are held weekly. If one is cancelled, it will either be mentioned in the previous meeting or an email will be sent out to the openstack-discuss mailing list.
Agenda for next meeting
- Announcements / Reminder
- Standing reminder to review patches tagged ironic-week-prio and to hashtag any patches ready for review with ironic-week-prio: https://tinyurl.com/ironic-weekly-prio-dash
- Review action items from previous meeting: http://eavesdrop.openstack.org/meetings/ironic/2022/
- Review Ironic CI status & update whiteboard if needed
- 2023.1 Work in progress
- Review all expected 2023.1 workstreams https://specs.openstack.org/openstack/ironic-specs/priorities/2023-1-workitems.html
- Review 2023.1 workstream progress https://etherpad.opendev.org/p/IronicWorkstreams2023.1
- Use these as input into PTG planning https://etherpad.opendev.org/p/ironic-bobcat-ptg
- Future of Bugfix releases
- RFE review (if necessary)
- Open discussion
- Vulnerability handling policy in Ironic (vanou): After handling vulnerability of vendor driver library used in iRMC driver[1], I feel it's better to have basic vulnerability handling policy in Ironic community doc. (I apologize add this topic not 2 days before weekly meeting. So it's OK to skip this topic next meeting if we have no time)
- In this case, cause of vulnerability is in vendor driver library (python-scciclient used in iRMC driver). Ironic community has responsibility of code quality of each driver (e.g. iRMC driver). On the other hand, each vendor has responsibility of code quality of vendor driver library (e.g. python-scciclient) and maintains that library. So, after discussion[2] with community member, we decided to fix this through public process like ordinal bug fix process (caution: in general, fixing vulnerability should be done in private process until fix patch is released).
- There can be 4 situation
- cause of vulnerability is in code hosted in Ironic repository (i.e. driver code) : In this case, we may agree on fixing that in private process.
- cause of vulnerability is in vendor driver library code (there is no need to modify Ironic code) : In this case, vendor fix vendor driver library and assign new version. Then, Ironic community just updates version requirement of vendor driver library in Ironic repository. And that can be done through usual public Ironic review/merge process.
- cause of vulnerability is in vendor driver library code (Ironic code should be modified to apply vulnerability fix: e.g. fix of vendor library adds parameter to vendor library function and Ironic code should use that parameter to fix vulnerability) : Ideally, if both Ironic code and vendor driver library should be modified, vendor fixes vendor driver library in private process and keep that fix secret till fixing Ironic code finish. And Ironic community can review Ironic code modification in public process. Then, if Ironic community finishes review and is ready to merge, vendor publishes fix of vendor driver library and Ironic community merge fix at the same time.
- cause of vulnerability is in both Ironic repository code and vendor driver library code : In this case, fix of both Ironic code and vendor driver library code should be done in private process. Then vendor publishes vendor driver library at the same time Ironic publishes Ironic code fix.
- Vulnerability handling policy in Ironic (vanou): After handling vulnerability of vendor driver library used in iRMC driver[1], I feel it's better to have basic vulnerability handling policy in Ironic community doc. (I apologize add this topic not 2 days before weekly meeting. So it's OK to skip this topic next meeting if we have no time)
Previous meetings
Logs from previous meetings can be found here.
Related meetings
Review Jams
Ironic used to hold periodic review jam meetings. They have been discontinued.