15:00:29 <TheJulia> #startmeeting ironic
15:00:30 <TheJulia> o/
15:00:30 <openstack> Meeting started Mon Feb 25 15:00:29 2019 UTC and is due to finish in 60 minutes.  The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:33 <openstack> The meeting name has been set to 'ironic'
15:00:34 <iurygregory> o/
15:00:34 <TheJulia> Good morning everyone!
15:00:42 <iurygregory> morning
15:00:45 <kaifeng> o/
15:00:45 <bdodd> o/
15:00:46 <dnuka> o/
15:00:47 <arne_wiebalck_> o/
15:00:49 <jroll> \o
15:01:15 <rpittau|sardegna> o/
15:01:20 <rloo> o/
15:01:26 <etingof> o/
15:01:26 <w14161_1> o/
15:01:30 <mgoddard> \o
15:02:02 <dtantsur> o/
15:02:06 <TheJulia> Our agenda this morning is fairly run of the mill with some announcements, so hopefully we'll get through things quickly.
15:02:10 <TheJulia> Of course this is always my hope.
15:02:16 <baha> o/
15:02:23 <TheJulia> Our agenda can be found on the wiki, as always.
15:02:26 <TheJulia> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
15:02:36 <TheJulia> #topic Announcements/Reminders
15:02:50 <mjturek> o/
15:02:56 <stendulker> o/
15:03:07 <hjensas> o/
15:03:28 <TheJulia> #info This week is the Stein release deadline for non-client libraries. (R-6)
15:03:32 <TheJulia> #link https://releases.openstack.org/stein/schedule.html
15:04:15 <TheJulia> #info Forum/Topic discussions are underway at our forum/ptg planning etherpad. Please add ideas. We should co-ordinate submitting topics this week.
15:04:19 <TheJulia> #link https://etherpad.openstack.org/p/DEN-train-ironic-brainstorming
15:04:59 <TheJulia> #info TheJulia will be traveling Wednesday and at an on-site meeting Thursday/Friday so will likely be moderately unavailable.
15:05:17 <TheJulia> #info dtantsur will be handling non-client library releases on Thursday
15:05:26 <rloo> TheJulia: how do we decide what is in the Forum and what is in PTG?
15:05:27 <TheJulia> #info dtantsur will also be out on Wednesday.
15:05:57 <TheJulia> rloo: Forum is what runs during the summit in order to serve as requirements collection/larger discussions with operators/users to identify needs/wants/gaps
15:06:13 <TheJulia> PTG is our time as a team to have focused discussions on how to solve those problems.
15:06:42 <TheJulia> So there is some things that will naturally blend across both, and may need time in both. Those are likely the best topics!
15:06:59 <TheJulia> Does anyone else have anything to announce or remind us of this week?
15:07:07 <rloo> TheJulia: thx, so people don't need to specify forum or ptg when they put things down on that etherpad
15:07:18 <TheJulia> ++
15:07:27 <rloo> TheJulia: might be useful to mention, client packages are next week?
15:07:42 <rloo> TheJulia: stein release deadline for client packages
15:08:10 <TheJulia> #info Client library release deadline is next week.
15:08:20 <TheJulia> Anything else?
15:09:08 <dtantsur> and FF is also next week
15:11:12 <TheJulia> #info Feature freeze is next week as well. Direct user facing features will likely be pushed to Stein. Non-using facing features "MAY" be considered before we need to branch for Stein. As we have learned int he past, ironic has to be ready to branch earlier than other projects, so that will also reduce chances of new features merging.
15:12:03 <TheJulia> Are we good to proceed?
15:12:51 * dtantsur is good
15:12:52 <TheJulia> Since we have no action items from last week, we will go directly to subteam status
15:12:55 <TheJulia> #topic Review subteam status reports
15:13:10 <TheJulia> #link https://etherpad.openstack.org/p/IronicWhiteBoard
15:13:33 <TheJulia> Starting at line 292.
15:13:47 <TheJulia> I looked through things earlier and, and everything looked good to me
15:13:48 <dtantsur> I think we should clear it from items that are clearly not making stein
15:13:55 <TheJulia> Yeah
15:14:28 <TheJulia> I can do that after the meeting
15:14:45 <dtantsur> thnx
15:14:50 <rloo> for py3, if we want to update python-ironicclient to py3, do we need to do it before end of next week cuz of deadline? it doesn't affect the code (i hope not)
15:15:35 <jroll> rloo: as in, update the CI jobs?
15:15:52 <rloo> jroll: yup. L306
15:16:06 <jroll> that seems fine to me to do any time
15:16:38 <jroll> if it affects the code, and we want that code released for stein, it needs to be before the deadline. otherwise press on
15:17:17 <TheJulia> It seem slike we really should just launch functional or tempest with py3
15:20:04 <TheJulia> Does anyone have a few minutes to submit that as a change to python-ironicclient this week?
15:20:05 <rloo> wrt smartnic support, is all the stuff on ironic side done? I only see one PR for neutron (L417ish)
15:20:15 <TheJulia> well, in the next couple days
15:20:33 <asettle> Question to all: We've been looking at this Ironic stable/rocky doc build error for 2 days now and it's not solving itself. For context's sake: Why is Ironic publishing the API docs?
15:20:56 <rpittau|sardegna> TheJulia, I can check that as I'm already on the py3 wave
15:21:03 <dtantsur> asettle: we're in a meeting now, maybe ask in the Open Discussion section?
15:21:05 <TheJulia> rloo: Seems that way minus some docs I believe
15:21:12 <asettle> dtantsur, in a chan?
15:21:27 <TheJulia> but additional docs are likely useless until neutron also merges the change
15:21:30 <dtantsur> asettle: yeah, we moved the meeting here some time ago
15:21:41 <asettle> Sorry dtantsur
15:21:43 * asettle backs out
15:22:01 <dtantsur> no worries, it's not obviously different from our usual chatter :)
15:22:52 <rpittau|sardegna> so many strikes in the whiteboard
15:23:02 <rpittau|sardegna> :/
15:23:15 <dtantsur> yeah, this also needs periodic cleanup
15:24:13 <TheJulia> Yeah, struck out things that I'll remove after the meeting
15:25:54 <TheJulia> Are we good to proceed?
15:26:01 <dtantsur> ++
15:26:22 <rpittau|sardegna> ++
15:27:15 <iurygregory> ++
15:27:37 <TheJulia> #topic Priorities for the coming week
15:27:49 * TheJulia removes the merged items from the list for this next week :)
15:27:55 <TheJulia> (of which, there are a decent number \o/)
15:31:41 <TheJulia> I think that looks fairly good for the next week
15:32:19 <mgoddard> shall I add deploy templates patches?
15:32:31 <TheJulia> mgoddard: please
15:32:31 <dtantsur> mgoddard++
15:32:34 <dtantsur> otherwise looking good
15:32:47 <TheJulia> mgoddard: do you feel the conductor patch is going to be ready in the next week or two?
15:33:08 <mgoddard> TheJulia: yeah, I have a fairly free week this week
15:33:37 <mgoddard> API is ready for review, once I push (today)
15:33:44 <TheJulia> Awesome
15:33:46 <mgoddard> assume we can accept API before conductor?
15:34:01 <mgoddard> would take the pressure off, and allow client and tempest to go in
15:34:08 <TheJulia> I'd prefer not to, but if it is an easy wire-together and would land in short order, I guess it would be okay
15:34:38 <TheJulia> Is the conductor patch actually really minor?
15:34:41 <dtantsur> ideally API goes last to avoid a period of non-working API. but it's not hard blocking.
15:34:44 <TheJulia> i.e. not api invoked?
15:35:14 <mgoddard> the conductor side isn't minor, but it's not huge
15:35:30 <TheJulia> Yeah, broken api stuffs is ultimately what we want to avoid
15:35:33 <mgoddard> it's not directly triggered by the new API, it happens during validate/deploy
15:35:38 <TheJulia> I'm okay with it on a case by case basis
15:36:02 <TheJulia> Okay, that sounds promising
15:36:24 <mgoddard> I'll reorder the patches to put conductor last, we don't have to +A the API but that frees me up a bit to iterate and makes it easier to review the API
15:37:58 <TheJulia> okay, thanks
15:38:26 <TheJulia> I've updated the list to be a little cleaner, and moved sushy/sushy tools to the top since those are the main things with outstanding patches
15:38:37 <TheJulia> Getting those merged will help us in the long run
15:38:42 <TheJulia> Anyway, are we good to proceed
15:38:58 <TheJulia> ?
15:39:16 * TheJulia hears crickets
15:39:20 <rpittau|sardegna> let's move on :)
15:39:22 <dtantsur> yep
15:39:24 <TheJulia> #topic RFE Review
15:39:33 * TheJulia hands dtantsur the microphone
15:39:46 <dtantsur> #link https://storyboard.openstack.org/#!/story/2005083 Allow building simple configdrives inside Ironic
15:40:08 <dtantsur> what I suggest is building a simple configdrive building facility in ironic
15:40:22 <dtantsur> to stop people from cargo culting out genisoimage code from ironicclient ~ everywhere
15:40:36 <dtantsur> #link https://review.openstack.org/#/c/639050/ ready to review patch
15:40:36 <patchbot> patch 639050 - ironic - Allow building configdrive from JSON in the API - 5 patch sets
15:40:45 <TheJulia> Seems simple to me
15:40:47 <dtantsur> (note that it's less than 200 LoC)
15:40:59 <hjensas> I like it, maby in the future also add support for vendor_data and network_data? (Looks like a trivial change in the sdk and then ironic).
15:41:07 <jroll> dtantsur: whether we do this RFE or not, we're going to pull that (and nova's) code out into a library, right?
15:41:30 <dtantsur> jroll: I'm taking it from openstacksdk where I put it for metalsmith (and which is already our indirect dependency)
15:41:38 <dtantsur> * taking = importing, not copying
15:41:53 <dtantsur> hjensas: yeah, I did not want to extend openstacksdk so close to various deadlines. but yes, we can.
15:42:13 <TheJulia> those seem like reasonable iterations to me
15:42:20 <dtantsur> with cloud-init you can do anything via user_data though. ditto for ignition.
15:42:43 <jroll> cloud-init's networking doesn't come from user_data
15:43:02 <jroll> and for some clouds, that's the most important bit
15:43:21 <kaifeng> only nova has the network info i think
15:43:24 <TheJulia> But ignition, it does come purely from user data.
15:43:26 <jroll> (once it's full featured) should we use this thing instead of building the config drive in nova?
15:43:35 <TheJulia> I believe kaifeng is correct
15:43:59 <dtantsur> jroll: if nova can provide it to us in a sane format - sure
15:44:05 <TheJulia> jroll: possibly, worth a discussion with the nova folks I think
15:44:16 <jroll> ok
15:44:36 <jroll> this feels like a bigger conversation IMO, figure out where we want to be instead of slapping a second format on the configdrive parameter
15:44:47 <dtantsur> okay, I can take a follow-up to extend sdk+ironic to support network stuff. but it will slip into train likely, so I'd like to start with user_data.
15:45:09 <dtantsur> jroll: I'm not sure I get the "where we want to be" bit
15:45:21 <kaifeng> will we support multi-file packaging for the user_data?
15:45:34 <jroll> dtantsur: for example, maybe it's worth deprecating passing a iso image in, and pushing everyone to pass user_data/etc instead
15:45:43 <dtantsur> kaifeng: user_data is one file from our perspective. then each vendor is doing something of their choice.
15:45:43 <TheJulia> kaifeng: I feel like user data would need to be pre-assembled however it is posted
15:46:09 <dtantsur> jroll: dunno, I see both as useful
15:46:23 <TheJulia> jroll: I'm -1 to deprecating passing an pre-built config drive image. We have operators that build in tools and additional files they need when they use standalone
15:46:24 <dtantsur> e.g. for particularly crazy cases with custom layout etc
15:47:00 <TheJulia> We already do a "is this a url or is this a blob of encoded data, adding a third of "is this a dict" seems reasonable to me
15:47:30 <jroll> another example, are we sure we don't want specific fields for this?
15:47:42 <jroll> which should nova use?
15:47:43 <kaifeng> okay, i just feel that would be easier for users, but no strong demands
15:47:43 <jroll> etc
15:47:48 <jroll> just feels like lots of questions
15:48:03 * dtantsur has not seen lots of questions so far
15:48:21 * rloo wonders if it would be useful to have the configdrive building code in a library, outside of openstacksdk.
15:48:23 <dtantsur> I mean, we can argue about small details and let standalone users suffer. or we can agree on something that may not be 100% perfect.
15:48:34 <TheJulia> I think the questions are that jroll is seeing it through eyes of nova, where dtantsur is seeing it purely from a standalone use case
15:48:49 <rloo> i think it is worth discussing with nova first
15:48:58 <dtantsur> we've been nova-centric for quite some time
15:49:00 <TheJulia> I don't think that actually helps us
15:49:03 <rloo> is dtantsur in a hurry cuz he wants to get something in stein?
15:49:08 <jroll> TheJulia: dtantsur: I'm seeing it from a perspective of "should we give folks more than 5 minutes in a meeting to think about this"
15:49:28 <dtantsur> rloo: I'd prefer to get it in stein, yes, although patching things downstream is certainly an option.
15:49:35 <jroll> you both know I'm open to small additions that aren't 100% perfect
15:50:20 <jroll> this is an API thing we need to support forever, I prefer not to slam those in a week before feature freeze
15:50:21 <dtantsur> I don't quite get why Nova is an argument here. Nova doesn't have problems with our configdrive building AFAIK. Standalone users seem to (esp. coming from new languages).
15:50:48 <TheJulia> The background on this is the gophecloud are rejecting config drive building support
15:50:49 <dtantsur> I nearly see it as a technical debt we've been shying away from because standalone users are 2nd class
15:50:58 <TheJulia> so either it gets cargo culted around in code that uses gophercloud
15:51:04 <dtantsur> (ditto for allocation API)
15:51:05 <TheJulia> or we add an API extension to support it
15:51:07 <jroll> I don't have an argument. I have questions about consistency, that also involve nova
15:51:42 <TheJulia> I think it is a good topic to discuss with them at the PTG
15:52:07 <mgoddard> I agree with the point about FF. We've got quite a lot features that have been planned for some time
15:52:14 <TheJulia> "We're thinking of heading further in this direction, but intend to maintain compatability for prior methods... does nova care?" in essence
15:52:47 <jroll> or would we prefer to do it this way in nova
15:52:57 <TheJulia> exactly
15:53:06 <jroll> TheJulia | The background on this is the gophecloud are rejecting config drive building support <- thank you for giving us the primary reason to do this
15:53:41 <dtantsur> I still think we should become less Nova-centric with time
15:53:43 * TheJulia somehow missed "folks" after gophercloud
15:53:48 <jroll> to be absolutely clear, this is a good idea and I'm not trying to block it. I'm just trying to slow down a bit and make sure we get it right
15:54:17 <TheJulia> dtantsur: I concur, and I think we already have the pattern established of double use of the field. so triple use is not a huge deal in my book
15:54:40 <jroll> dtantsur: I think of the nova driver as our code, not nova's code. I'm purely asking if we should also consider that code in part of this. (I have the same question for bifrost)
15:54:44 <dtantsur> for the record, I'm fine with 2-3-5 separate fields as well
15:55:03 * TheJulia worries 2-3-5 fields may actually cause lots of confusion....
15:55:10 <dtantsur> jroll: I think bifrost, metalsmith, etc will immediately benefit from this
15:55:21 <dtantsur> (I can surely say for metalsmith)
15:55:41 <TheJulia> Well, early next cycle if people have time
15:55:49 <TheJulia> Anyway, do we have consensus that it is a generally good idea?
15:55:58 <dtantsur> jroll: changing nova requires coupling between how nova builds configdrives and how we do
15:56:06 <dtantsur> which is something I'm a bit reserved about
15:56:25 <dtantsur> because I'm not planning on something that covers every possible layout of a configdrive in the world
15:56:28 <TheJulia> Which we may not be the only user of that code path either
15:56:40 <dtantsur> right, you can have configdrives with VMs
15:56:45 <dtantsur> (dunno why)
15:56:52 <TheJulia> heh
15:57:02 <mgoddard> security?
15:57:02 <TheJulia> magical metadata service is not that magical
15:57:05 <jroll> because metadata service was/is hard to scale
15:57:12 <hjensas> dtantsur: ipv6? afik metadata does'
15:57:16 <jroll> (probably more toward was)
15:57:22 <hjensas> nt work with v6.
15:57:24 <dtantsur> ah
15:57:29 <rloo> i don't think anyone disagrees; it is a good idea.
15:57:42 <TheJulia> anyway, we're heading in a bit of a tangent
15:57:50 <jroll> right, good idea, I would like more discussion, I can drop questions on the story
15:58:00 <TheJulia> I believe that is reasonable
15:58:17 <TheJulia> So we have 2 minutes left
15:58:27 <TheJulia> I guess time for open discussion and let asettle ask her question
15:58:50 <TheJulia> #topic Open Discussion
15:59:04 <TheJulia> asettle: could you provide some background regarding your question
15:59:08 <asettle> Mellow hello yes
15:59:10 <asettle> Sorry for interrupting
15:59:17 <asettle> Please :) thanks TheJulia
16:03:12 <jroll> I suspect asettle is waiting for TheJulia to provide background, and vice versa :)
16:03:26 <TheJulia> jroll: I was just wondering the same thing
16:03:31 <jroll> should we end the meeting and just discuss as regular chatter?
16:03:35 <TheJulia> Yeah, I think so
16:03:39 <TheJulia> Thanks everyone!
16:03:41 <rpioso> o/
16:03:43 <TheJulia> #endmeeting