14:00:26 <ricolin> #startmeeting heat
14:00:27 <openstack> Meeting started Wed Jul 18 14:00:26 2018 UTC and is due to finish in 60 minutes.  The chair is ricolin. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:30 <openstack> The meeting name has been set to 'heat'
14:00:36 <ricolin> #topic roll call
14:00:49 <ramishra> hi
14:00:57 <ricolin> o/
14:01:59 <ricolin> zaneb, meeting time
14:03:21 <zaneb> o/
14:03:34 <ricolin> there you are!:)
14:03:58 <ifat_afek> Hi
14:04:05 <ricolin> ifat_afek, hi
14:04:17 <ricolin> #topic adding items to agenda
14:04:22 <ricolin> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282018-07-18_1400_UTC.29
14:05:48 <ramishra> ricolin: I've to leave early, the agenda looks pretty big:)
14:06:30 <ricolin> ramishra, NP, you have to go, you have to go:)
14:06:59 <ricolin> maybe have little time we can talk about SSL first?
14:07:03 <ricolin> ramishra,
14:08:14 <ramishra> sure, I think therve was of the opinion we don't need that, just ask everyone to install CA certs on heat engines
14:08:38 <ricolin> #topic SSL option in Remote Stack
14:09:01 <ricolin> ramishra, zaneb so I update a version of idea on https://review.openstack.org/#/c/480923
14:09:02 <ricolin> #link https://review.openstack.org/#/c/480923
14:09:29 <ricolin> basically use config to define what files we allows to import
14:10:21 <ricolin> will that be acceptable way
14:10:22 <zaneb> that's not interoperable
14:10:56 <zaneb> although I guess region names are cloud-specific anyway
14:11:19 <zaneb> but in any event it doesn't help at all with the multi-cloud case
14:11:28 <ricolin> For multi-cloud we can actually put ssl options into credential
14:12:40 <ramishra> I this case The user needs to know the file names, why not just the operator configures it for provider/region combination and it's picked up automatically?
14:13:03 <ramishra> As I proposed earlier
14:13:42 <ricolin> ramishra, we can approach that by reading from clouds.yaml, will that works for you?
14:14:29 <zaneb> I doubt private cloud operators are going to provide a custom clouds.yaml that includes their own region info
14:15:02 <ramishra> ricolin: I don't know. IMO if we're keeping a list of cert locations in config, then better have them per provider/region so, the user does not have to do anything
14:15:26 <ricolin> zaneb, they're not going to provide such info for config as well
14:16:10 <zaneb> ricolin: probably not, and they're probably not going to provide a whitelist and cert files either
14:16:12 <ricolin> ramishra, that will work
14:18:28 <ricolin> zaneb, but I think that's up to environment. Will be better if we can try to solve that, but if we can't figure out better idea, a map in config sounds like a plan to me
14:19:38 <ricolin> Or we can try harder to document things and skip this issue and leave it to user for now
14:20:17 <ricolin> these are two ways I can think of on how we approach this
14:20:52 <zaneb> the main thing I care about it multi-cloud, and not having a different interface for multi-cloud vs. multi-region
14:21:48 <zaneb> if we can have no interface at all for multi-region, that's ok with me
14:22:09 <zaneb> having different CAs for different regions sounds kind of crazy to me anyway
14:23:28 <ricolin> zaneb, we can get ssl options from credential like the format here https://docs.openstack.org/os-client-config/latest/user/configuration.html#ssl-settings
14:24:15 <ricolin> in that way we don't need any new property at all, but we still need the config(or something heat managable)
14:24:20 <zaneb> ricolin: we can't because again, those are just local filenames
14:26:28 <ricolin> zaneb, I guess I can at least put something in document for user, before we can fine a way to do it(which we all agree on)
14:27:54 <zaneb> maybe we should get the user to store the CA keys in barbican as separate secrets
14:28:25 <ricolin> zaneb, we still need it as a `file` before we give the file name to client
14:28:59 <ricolin> for now ssl option only allow file_name as input:/
14:29:23 <zaneb> we can use a tempfile. I don't think that's a big deal
14:29:45 <zaneb> or a FIFO even
14:29:49 <ricolin> zaneb, I was thinking about that, but what about the security about that file
14:30:19 <ricolin> do we care about that?
14:30:55 <zaneb> only really an issue for the private key one, but it's a fair point. FIFO (named pipe) would be secure I think
14:31:34 <ricolin> ramishra, what you think
14:32:09 <zaneb> it is an annoying API for the clients though
14:32:20 <zaneb> we should probably look in to fixing that
14:32:36 <ricolin> zaneb, yes we should
14:32:53 <zaneb> would be nice to at least be able to pass e.g. a StringIO object
14:33:14 <ricolin> or a secret?:)
14:34:18 <zaneb> as long as Barbican is optional I don't think we want to bake it in to all of the clients
14:34:37 <ramishra> sounds good, if we can change that interface then users can use get_file
14:35:06 <ricolin> This gonna take more discussion
14:35:12 <ricolin> maybe start with a ML
14:35:29 <ricolin> and fallow with a PTG session
14:35:58 <ricolin> anyone interested in the ML?:)
14:37:03 <ricolin> or we can just change it with small code?
14:37:30 <ricolin> I will look into it, welcome anyone join
14:38:12 <ricolin> let's move on,
14:38:42 <ricolin> #topic Hidden Aodh::Alarm resource https://review.openstack.org/#/c/580963/2/etc/heat/environment.d/default.yaml
14:39:13 <ricolin> So Alarm has been deprecated, and now we should try to hide it
14:39:50 <ricolin> for what I concern, what we gonna deal with those resources depends on that resource type
14:40:07 <ricolin> which their is a bunch under https://review.openstack.org/#/c/580963/2/etc/heat/environment.d/default.yaml
14:40:18 <zaneb> wait, the resource registry _is_ hidden isn't it? do any of those resources show up in the API/docs?
14:41:07 <ricolin> zaneb, I don't know actually:)
14:41:44 <zaneb> OS::Quantum* doesn't afaik
14:42:38 <ricolin> cool, so I think we can just remove them all!?
14:43:23 <ramishra> or map them to GnocchiAggregationByResourcesAlarm?
14:43:30 <zaneb> no, just leave them all I thought
14:43:40 <ricolin> ramishra, it can't directly map to
14:44:00 <ramishra> yeah, the resources would be replaced, but that should be ok, no
14:44:50 <ricolin> ramishra, AWS::CloudWatch::Alarm also require Alarm too
14:45:06 <ricolin> but which is a template contain Aodh::Alarm
14:46:09 <ricolin> #link https://github.com/openstack/heat/blob/master/etc/heat/templates/AWS_CloudWatch_Alarm.yaml#L63
14:46:25 <zaneb> so change the template?
14:47:42 <ricolin> zaneb, if that gonna match behavior of `AWS_CloudWatch_Alarm` in AWS?
14:48:19 <zaneb> probably no worse than it does now ;)
14:48:49 <ricolin> at least the parameters doesn't look compatible
14:49:18 <ramishra> I mean there is no ceilometer anymore, so we else we can do:)
14:49:28 <zaneb> it's a template. there is a yaql function ;)
14:50:07 <ramishra> IMO, Just drop those resources and mappings:)
14:50:24 <ricolin> ramishra, +1 on that
14:52:00 <ricolin> Time's running let's move on, we shall keep talking in that patch I guess
14:52:07 <ricolin> #topic Keypair resource in Stack
14:52:43 <ricolin> Keypair is binding with user and only that user can use/saw that keypair, if we update Stack with another user, resources depends on that resource might get error
14:53:10 <zaneb> urg
14:53:17 <ricolin> ramishra, zaneb ideas on that?
14:53:41 <ricolin> I think we can do replace when different user
14:54:04 <zaneb> so if the keypair is created with a public key, then easy(-ish) fix is just to add it for the new user as well
14:54:50 <ricolin> zaneb, yeah, that's the only workaround I know for now
14:55:19 <ricolin> actually it's just keypair name we need to consist with
14:55:31 <zaneb> if the keypair generates a private key itself, then I don't know how best to handle it
14:55:38 <ramishra> ricolin: replacing the key would replace the server resources, would that be acceptable?
14:55:58 <zaneb> this really is a bad API. I don't know why they chose to make it inconsistent with everything else in Nova
14:56:01 <ricolin> ramishra, not sure, but that's one way in my mind
14:56:18 <ramishra> deprecate that resource;)
14:56:24 <ricolin> ramishra, LOL
14:56:50 <ricolin> we can at least give a Known issue for release note
14:57:07 <ricolin> but wondering what will be the best way we can take from here
14:58:20 <zaneb> I don't think replace is the right thing, because we won't be changing the creator of any existing servers
14:58:36 <ricolin> zaneb, okay
14:58:51 <zaneb> but any new servers will be created with the new owner (and thus need access to they keypair under that user)
14:59:08 <zaneb> so we really need one keypair for each user who has ever touched the stack
14:59:42 <ricolin> zaneb, I guess that means nice releasenote
14:59:50 <zaneb> lol
15:00:25 <ricolin> Okay, running out of time
15:00:34 <ricolin> just two more things
15:00:47 <ricolin> I'm gonna release heatclient today
15:01:19 <ricolin> and please review multicloud patch:)
15:01:52 <ricolin> Also we for now remove monasca unittests
15:02:09 <ricolin> will revert it once that monasca issue fixed
15:02:18 <ricolin> Anything else?
15:03:59 <ricolin> Okay thanks zaneb ramishra
15:04:02 <ricolin> #endmeeting