18:00:09 <elmiko> #startmeeting sahara
18:00:09 <openstack> Meeting started Thu Nov 12 18:00:09 2015 UTC and is due to finish in 60 minutes.  The chair is elmiko. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:12 <openstack> The meeting name has been set to 'sahara'
18:00:18 <elmiko> hi all
18:00:24 <AndreyPavlov> hi)
18:00:28 <crobertsrh> hel\o
18:00:30 <elmiko> #topic roll call
18:00:31 <huichun> hello
18:00:33 <vgridnev> hi
18:00:47 <NikitaKonovalov> o/
18:00:52 <elmiko> we'll give folks a minute or 2 =)
18:01:11 <elmiko> everyone recovered from summit?
18:01:22 <crobertsrh> almost
18:01:49 <elmiko> ok, let's get rolling
18:01:58 <elmiko> #topic sahara@horizon status (crobertsrh, vgridnev)
18:02:04 <elmiko> anything to report?
18:02:39 <crobertsrh> Several patches available for review, not much action.
18:02:50 <elmiko> i -1'd something yesterday =)
18:02:52 <crobertsrh> Hopefully, we can start moving on our repo move someday soon.
18:02:57 <vgridnev> I have nothing at this topic today.
18:02:57 <elmiko> +1
18:02:58 <crobertsrh> elmiko:  Yes, I noticed that
18:03:18 <elmiko> i think we can probably move this topic down further in our agenda too
18:03:28 <NikitaKonovalov> crobertsrh: anything stopping us from doing it now, rather the pushing patches to horizon?
18:03:31 <elmiko> or, we should once we separate the repos
18:03:41 <elmiko> good question NikitaKonovalov
18:04:02 <tmckay> I think the sooner, the better.  Same pain, might as well do it early
18:04:08 <tmckay> assuming agreement from the horizon folks
18:04:13 <crobertsrh> I believe that david-lyle was doing a bit of work/poking on what the extraction would take.  I need to follow up with him.
18:04:21 <elmiko> cool
18:04:23 <NikitaKonovalov> ok
18:04:43 <elmiko> should we start to develop an etherpad to lay out our strategy for migrating to a new repo?
18:04:43 <tmckay> #action croberts to follow up with dlyle on sahara repo extraction
18:05:04 * tmckay hopes he did that right
18:05:18 <crobertsrh> I'll follow-up first, and see how much or how little is involved
18:05:29 <elmiko> or really, crobertsrh, would you be willing to work on an etherpad for migration?
18:05:57 <elmiko> or NikitaKonovalov, or vgridnev
18:06:18 <elmiko> i think we should have some sort of plan we can all look at
18:06:28 <tmckay> +1
18:06:41 <tmckay> it can be a placeholder at first, containing feedback from dlyle
18:06:43 <elmiko> who's willing to take an action on this one... ?
18:06:48 <elmiko> yea, that works
18:07:09 <crobertsrh> I will
18:07:16 <elmiko> cool, thanks
18:07:17 <crobertsrh> sorry..was fighting devstack
18:07:24 <elmiko> lets ammend that previous action
18:07:27 <elmiko> #undo
18:07:28 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x972d210>
18:07:34 <tmckay> what??? devstack?
18:07:38 * pino|work sees devstack doing a supplex and beating crobertsrh once again
18:07:55 <elmiko> #action crobertsrh to followup with david-lyle about separating sahara ui, and create an etherpad for migration plans
18:08:09 <elmiko> ok, thanks
18:08:16 <elmiko> #topic News/Updates
18:08:21 <elmiko> so, what's everyone working on?
18:09:02 <tmckay> I put up a spec for smoothing overlap between is_default and is_protected, +2s just needs a merge
18:09:07 <vgridnev> I am working on collecting nice-to-have changes for stable/liberty and make backports
18:09:11 <egafford> Throwing around and testing image generation possibilities; should start posting specs by EONW.
18:09:19 <huichun> Fix some unit test on edp engine
18:09:33 <tmckay> #link https://review.openstack.org/#/c/241773/
18:09:46 <NikitaKonovalov> Still in internal performance testing
18:09:51 <AndreyPavlov> few patches to client from me
18:09:53 <elmiko> i'm getting back into improved secret storage, and starting for the next phase of apiv2
18:10:16 <crobertsrh> I've been doing shares on active clusters
18:10:19 <tmckay> also, I am thinking about a spec to allow "is_public" to be set even if "is_protected" is set.  Thinking about UI workflow, public should just be a checkbox you can toggle without unprotect/toggle/re-protect
18:10:24 <elmiko> tmckay: looks like egafford gave that a +A
18:10:27 <tmckay> what do you all think?  ^^
18:10:41 <tmckay> if such a spec will be dead-on-arrival, I won't bother writing it
18:10:54 <elmiko> #topic is_public/is_protected
18:10:56 <tmckay> is_public is just meta-info, not object content
18:11:03 <elmiko> the floor is yours tmckay
18:11:26 <vgridnev> tmckay, FYI there is already an change that implements acl operations from ui https://review.openstack.org/#/c/239671/
18:11:52 <elmiko> tmckay: only the owner would be able to set is_public?
18:12:00 <tmckay> yes
18:12:08 <tmckay> vgridnev, how does it handle this?
18:12:23 <tmckay> from the CLI, I had to unprotect, change public, reprotect
18:12:37 <tmckay> seems unnecessary
18:13:01 <tmckay> if a payload contains only "is_public", I think we should honor it (as long as the tenant check passes"
18:13:06 <elmiko> i don't have an objection to the owner being able to set is_public on a protected resource
18:13:51 <vgridnev> You can create is_public / protected object and also can make updates of these fields for several templates in 1 click
18:14:12 <vgridnev> templates -> objects
18:14:17 <tmckay> vgridnev, but what if public is false on a protected object, and I want to set public true
18:14:18 <elmiko> how is it implemented, does it unprotect/set public/reprotect?
18:14:47 <tmckay> I have to set protected = false, public = true, submit, then set protected = true, submit again, right?
18:14:51 <egafford> Thinking about it, we need protected objects to be able to be made public while protected; otherwise there's a window in which they are freely editable.
18:15:00 <tmckay> that's two forms to turn on public
18:15:10 <tmckay> egafford, also true
18:15:14 <elmiko> egafford: +1
18:15:14 <egafford> Could be pretty suboptimal.
18:15:25 <vgridnev> tmckay, there is no way to do so, because of restrictions on sahara side
18:15:29 <elmiko> it's all metadata anyways, this operation should be allowed by the owner
18:15:41 <tmckay> vgridnev, right, which is what my spec will fix! :)
18:15:42 <elmiko> vgridnev: right, tmckay is proposing we make a change on sahara
18:15:55 <egafford> I suppose there are potential issues with making a public, protected object non-public (what if someone needs it?)
18:15:56 <tmckay> vgridnev, do you think it's a good idea?
18:16:23 <tmckay> egafford, up to the owner.  That can happen now.
18:16:26 <elmiko> egafford: ooh, good point
18:16:27 <egafford> But I don't think this affects that problem (the owner can just unprotect and the unpublish anyway.)
18:16:30 <egafford> tmckay: Right.
18:16:48 <tmckay> we could put a reference check on it, I suppose. maybe a different spec/bug
18:16:50 <elmiko> as long as it's limited to the owner, i think it's a good change
18:16:51 <vgridnev> Looks good for owner, I think
18:17:13 <egafford> Best practice should probably be to copy public resources if you strictly depend on them.
18:17:13 <elmiko> tmckay: i wouldn't do the reference check. that way lies madness
18:17:13 <tmckay> okay.  It sounds like there is support, so I'll write it up.  Should be a short, simple spec
18:17:26 <tmckay> egafford, ack
18:17:26 <egafford> elmiko: +1 to the maw of refs.
18:17:45 <elmiko> egafford: agreed about the copy
18:17:50 <tmckay> elmiko, alright, we can change topics, I got the warm fuzzies I was hoping for
18:17:54 <elmiko> cool
18:18:05 <elmiko> #topic post summit recap
18:18:16 <elmiko> so, we had some really good sessions at summit
18:18:31 <elmiko> any specific issues that folks would like to discuss from them?
18:19:17 <pino|work> i have few questions about the image generation session, but if it is too long i can always pestt^W anno^W ask egafford later
18:19:35 <elmiko> go ahead pino|work, ask away =)
18:20:38 <pino|work> * Idempotent steps capable of creating an image either before or after nova spawn
18:20:44 <pino|work> (reading from the pad)
18:20:51 <pino|work> what does the above mean?
18:20:54 <egafford> pino|work: Essentially, we came to "we are slightly concerned about switching away from DIB or from DIB style elements, but we are agreed that we need an engine that reproducibly works. We also all want to move image generation into the API itself and make image gen process part of each plugin, and make sure that we can run the same logic to pack images as we can to build from clean images."
18:21:05 <egafford> pino|work: Essentially that last bit.
18:21:27 <pino|work> so no more a single script/repo for all the image types?
18:21:51 <egafford> Basically, we want to make sure that we can pack images that the plugins can test to make sure they're up to spec, build them out further if they're not right, or use them as-is if they are.
18:22:10 <egafford> That probably means enforcing idempotence (or at least check-then-act) in all cases.
18:23:07 <egafford> pino|work: That's certainly what SergeyLukjanov and I agreed should probably happen. We really only get version mismatch that way, and moving it into plugins lets us eventually make a 1-click build image button in OpenStack itself.
18:23:28 <egafford> Especially as our options grow, we'll want to expose that ability to public cloud users easily.
18:23:48 <pino|work> aha, i see
18:24:04 <pino|work> but still leaving the possibility for pre-built images, right?
18:24:19 <egafford> In the end, if we go to plugins-as-real-plugins-in-separate-repos, we won't be able to support a single repo for images anyway.
18:24:23 <egafford> Yes, absolutely.
18:24:27 <huichun> egafford: so we will not have a repo for all images?
18:25:12 <egafford> huichun: It doesn't really scale to n plugins and it introduces versioning issues besides, and it doesn't help us build image gen into our actual flow.
18:25:32 <egafford> huichun: So eventually, yeah, I think that's the direction we want to go as of the summit discussion.
18:26:15 <elmiko> i suppose, as long as we can run sahara in an isolate mode and still generate images that would be cool
18:26:34 <egafford> elmiko: Yup.
18:26:35 <sreshetnyak> if OpenStack environment doesn't have internet access, how build image?
18:26:36 <elmiko> it would be a loss, imo, if you need to have a full openstack cloud going to generate images
18:26:50 <egafford> sreshetnyak: If the whole OpenStack env doesn't, then yeah, we can't.
18:26:50 <elmiko> sreshetnyak: good question
18:26:52 <pino|work> egafford: is this break-up of the image generations also matching a potential break-up of the plugins in own repos?
18:27:12 <egafford> pino|work: It's a foundational step to help breaking up plugins into their own repos.
18:29:02 <NikitaKonovalov> so the envs w/o internet we can have images published somewhere
18:29:32 <egafford> sreshetnyak: I believe that we'll likely want to provide a command-line wrapper around the image gen process as well, so that folks can build images anywhere if they don't want to on OpenStack.
18:30:05 <elmiko> this process still has a long way to go though, we don't even have a spec to beat around yet
18:30:36 <elmiko> any other topics related to summit?
18:30:56 <egafford> elmiko: Yeah, I expect the spec to have the tar beaten out of it (validly.)
18:31:04 <elmiko> egafford: +1
18:31:09 <sreshetnyak> egafford, SIE is a good command line wrapper for building images
18:31:26 <elmiko> pino|work: did you have other questions?
18:31:46 <pino|work> elmiko: not at the moment, thanks (egafford too)
18:31:49 <egafford> sreshetnyak: :)
18:31:54 <elmiko> np
18:32:25 <elmiko> so, i have a question related to the improved secret store. this came up at summit and ideally i'd love to hear from SergeyLukjanov, but i'm curious what the group thinks...
18:32:34 <elmiko> so, i'm wrapping the castellan configuration options
18:32:53 <elmiko> previously, i had been exposing them, but SergeyLukjanov recommended that we wrap them in sahara specific options
18:33:15 <elmiko> is it ok if i just create a sahara specific config option like "use_barbican_key_manager"?
18:33:30 <elmiko> instead of using castellan's api specific class config
18:34:07 <egafford> elmiko: If you can wrap it in a single boolean without losing functionality that we need, that's great.
18:34:14 <tmckay> hmm, if we're wrapping castellan, I don't see why not
18:34:17 <crobertsrh> Yeah, single boolean is lovely
18:34:21 <egafford> elmiko: Less burden on the user. Question, though, is what we lose.
18:34:26 <elmiko> i'm thinking about how to make it simple for a deployer
18:34:27 <tmckay> hiding is hiding, after all
18:34:57 <elmiko> i guess is an infra issue that is starting to get traction, in terms of wrapping config options for libraries instead of exposing them
18:35:02 <egafford> elmiko: +1 if we can do it. One man's hiding is another man's encapsulation.
18:35:09 <elmiko> it's a tough issue with regard to oslo.config
18:35:32 <elmiko> ok, thanks. next question, should i update the spec to reflect these changes?
18:35:40 <elmiko> (just for completeness sake)
18:36:11 <elmiko> i'm fine not updating it, but wanted to see if there were any objectsions
18:36:15 <elmiko> objections even
18:37:13 <elmiko> ok, then... any other summit related topics?
18:37:25 <tmckay> minor detail, I think you can skip spec update
18:37:31 <tmckay> comment it in the change
18:37:43 <elmiko> yea, will do. plus i'm writing docs as well
18:37:56 <elmiko> #topic apiv2
18:38:02 <elmiko> just wanted to bring this up
18:38:18 <elmiko> we had some great discussion at summit about the path forward, but it will require input from the group
18:38:39 <elmiko> i'd like to ask everyone to take a look at the etherpad and the review
18:38:42 <elmiko> #link https://etherpad.openstack.org/p/sahara-mitaka-apiv2
18:38:49 <elmiko> #link https://review.openstack.org/#/c/212172/
18:39:07 <elmiko> in the next few weeks i will be trimming the list of changes and looking to update the spec
18:39:10 <tmckay> will do
18:39:24 <elmiko> if you have any comments or suggestions for the first draft of apiv2, please add them
18:39:25 <tmckay> I'll add the job type name change stuff there too
18:39:30 <elmiko> awesome, thanks!
18:39:37 <tmckay> MapReduce -> map-reduce
18:39:50 <tmckay> more openstacky
18:39:51 <elmiko> i'll add a section at the bottom of the etherpad for suggestions
18:40:14 <tmckay> or just mapreduce in that case, maybe, but you get the idea
18:40:37 <elmiko> yea
18:40:56 <elmiko> #topic Open Discussion
18:41:00 <elmiko> any other business or topics?
18:41:40 <crobertsrh> nothing from me
18:41:55 <NikitaKonovalov> nothing from me either
18:42:09 <elmiko> going once...
18:42:15 <elmiko> twice...
18:42:22 <vgridnev> stable guardians, please review the stable/liberty changes https://review.openstack.org/#/q/status:open+project:openstack/sahara+branch:stable/liberty,n,z
18:42:38 <elmiko> #link https://review.openstack.org/#/q/status:open+project:openstack/sahara+branch:stable/liberty,n,z
18:42:41 <elmiko> good point, thanks vgridnev
18:43:15 <vgridnev> also, please note that we need release notes modifications in stable branch now
18:43:33 <elmiko> is there a guide for that vgridnev ?
18:44:06 <vgridnev> #link  http://docs.openstack.org/developer/reno/usage.html#creating-new-release-notes
18:44:11 <elmiko> thanks
18:44:54 <tmckay> elmiko, good meeting
18:45:19 <elmiko> if nothing else, let's take back 15 minutes =)
18:45:23 <elmiko> going once...
18:45:25 <tmckay> +1
18:45:27 <elmiko> twice...
18:45:32 <elmiko> SOLD!
18:45:34 <elmiko> thanks all
18:45:37 <elmiko> #endmeeting