21:00:16 <dhellmann> #startmeeting crossproject
21:00:17 <dhellmann> courtesy ping for Qiming TravT gordc dirk mriedem SergeyLukjanov
21:00:17 <dhellmann> courtesy ping for daemontool jroll boris-42 redrobot flaper87 rhochmuth
21:00:17 <dhellmann> courtesy ping for fungi flwang dims vipul johnthetubaguy rakhmerov
21:00:17 <dhellmann> courtesy ping for docaedo stevemar mtreinish bswartz adam_g adrian_otto
21:00:18 <openstack> Meeting started Tue Feb 16 21:00:16 2016 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:18 <dhellmann> courtesy ping for zigo Piet sdake mugsie sheeprine thinrichs
21:00:19 <dhellmann> courtesy ping for jklare loquacities smelikyan Daisy skraynev odyssey4me
21:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:21 <openstack> The meeting name has been set to 'crossproject'
21:00:21 <dhellmann> courtesy ping for catherineD dhellmann dprince hyakuhei notmyname devkulkarni
21:00:33 <docaedo> o/
21:00:35 <elmiko> o/
21:00:35 <cdent> o/
21:00:36 <redrobot> ohai!
21:00:38 <dulek> o/
21:00:40 <diablo_rojo> hello :)
21:00:43 <jgregor> Hello
21:00:44 <dhellmann> thingee asked me to lead the meeting until he's on a stable wifi connection, which should happen shortly
21:00:44 <dhellmann> #chair thingee
21:00:45 <openstack> Current chairs: dhellmann thingee
21:00:47 <samueldmq> hi all
21:00:52 <adam_g> o/
21:01:02 <samueldmq> dhellmann: may I have my name added to the list of courtesy ping too ? :)
21:01:27 <loquacities> o/
21:01:28 <dhellmann> samueldmq : yes, I'll make a note of that (I'm not sure if thingee has a separate list, I got this one from last week's meeting)
21:01:42 <dhellmann> #action thingee to add samueldmq to the courtesy p ing list
21:01:45 <dhellmann> #undo
21:01:46 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x98b4290>
21:01:48 <dhellmann> #action thingee to add samueldmq to the courtesy ping list
21:01:52 <nikhil> o/
21:02:00 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting our agenda for today
21:02:12 <dhellmann> #topic Team announcements (horizontal, vertical, diagonal)
21:02:13 <dhellmann> who has announcements?
21:02:40 <dhellmann> #info release team: final non-client library releases coming up Feb 22-26
21:02:45 <dhellmann> #info release team: feature freeze for Mitaka coming up Feb 29-4
21:02:49 <nikhil> dhellmann: add me to courtesy reminders too
21:02:51 <dhellmann> #link http://releases.openstack.org/mitaka/schedule.html the release schedule
21:02:59 <dhellmann> #action thingee add nikhil to courtesy ping list
21:03:12 <samueldmq> dhellmann: thanks
21:03:25 <bknudson_> Ops mid-cycles going on
21:03:27 <sdake> sup dhellmann
21:03:29 <cdent> last week we had some discussion about quota; I went back to nova-last to ask for an interested party to participate. alaski said he would keep an eye on that.
21:03:40 <sdake> oh crossproject roger
21:03:42 <cdent> s/nova-last/nova-land/
21:03:45 <nikhil> cool
21:03:45 <dhellmann> bknudson_ : tell all the ops we said "hi"
21:03:59 <bknudson_> I'm not there! also, maybe it's done already
21:04:04 <dhellmann> hi, sdake :-)
21:04:04 <nikhil> we'd have the x-prj spec up later this week
21:04:05 <mtreinish> dhellmann: I'm not sure whether this is worth mentioning here or not: http://lists.openstack.org/pipermail/openstack-dev/2016-February/086706.html
21:04:14 <dhellmann> bknudson_ : oh, well
21:04:26 <dhellmann> mtreinish : sure, that's what this section of the meeting is for
21:04:31 <mtreinish> but it's removing a ML that used to be there, which seems sorta cp
21:04:39 <dhellmann> #info the openstack-qa mailing list is officially shut down
21:04:52 <bknudson_> I didn't know about http://status.openstack.org/openstack-health/#/g/build_queue/periodic
21:05:12 <dhellmann> mtreinish : do you have a link to your blog post about the dashboard handy?
21:05:26 <flwang> o/
21:05:28 <mtreinish> dhellmann: this one: http://blog.kortar.org/?p=279
21:05:40 <dhellmann> that's the one
21:05:53 <dhellmann> #link http://blog.kortar.org/?p=279 mtreinish wrote up a nice description of the new openstack health dashboard
21:06:24 <dhellmann> what other cp teams do we have represented today? docs? stable?
21:07:18 <dhellmann> cdent : sorry, I missed your comment earlier. is there some place we need to make a note about alaski's participation in that (I missed last week's meeting)
21:07:40 <fungi> infra, but we don't have any cross-project announcements this week afaik
21:07:41 <cdent> dhellmann: no, don't think so. as long as the people driving the x-spec are aware it's good
21:08:08 <dhellmann> fungi : ack, sorry to leave you out
21:08:13 <dhellmann> cdent : sounds good
21:08:17 <thingee> o/
21:08:20 <dhellmann> hi, thingee
21:08:35 <sheel> hi
21:08:36 <dhellmann> it sounds like that covers the announcements, unless thingee has anything?
21:08:37 * thingee unstable connection. will probably drop off in 22 mins
21:08:48 <thingee> nothing from me
21:08:54 <dhellmann> ok, let's move on then
21:08:55 <dhellmann> #topic A Common Policy Scenario Across All Projects
21:09:00 <dhellmann> #link https://review.openstack.org/#/c/245629/
21:09:13 <thingee> jamielennox: ^
21:09:21 <dhellmann> aha, I was just going to ask who is driving this
21:09:40 <jamielennox> So basically i was looking to get a broader cross project view on the above spec
21:10:02 <sballe> dhellmann: is this user policy? or somethign else
21:10:17 <jamielennox> more out of how services grew than anything else we've been stuck in an admin or non-admin kind of policy for a long time now
21:10:27 <dhellmann> sballe: yes, it's related to policy definitions within the applications for access control, etc.
21:10:49 <jamielennox> and from a keystone perspective we keep trying to add new security features that really aren't a lot of help when operators have to use the admin role to get anything done
21:11:22 <jamielennox> the goal of the spec is to define a scenario, a couple of roles that everyone can agree on and would implement by default
21:11:28 <dhellmann> jamielennox : I see some comments in recent reviews about names of things, which makes me think this is not so controversial but needs some time to think about little details. is that your understanding of the state of the spec, or do you think there might be uncovered issues?
21:11:51 <dhellmann> s/uncovered/as yet uncovered/
21:11:56 <jamielennox> this would not prevent any operator from defining their own roles and policy as they do now, but it would significantly increase the security of those deployments who don't want to change policy files
21:12:05 <cdent> I think there's also some concern about size/extent, dhellmann
21:12:08 * notmorgan is lurking (sorry)
21:12:13 <jamielennox> dhellmann: so there is some questioning of naming (as always)
21:12:32 <jamielennox> but the other question that dolphm and i have been going back and forward on and could use some broader scrutiny is how extensive we want this to be
21:12:47 <dolphm> sorry, joined just a second ago
21:12:58 <jamielennox> initially the plan was to just provide some basic roles and improve on the current scenario
21:13:01 <dhellmann> jamielennox : a phased approach does have some appealing aspects
21:13:22 <jamielennox> the spec sort of grew from there to doing fairly fine grained roles
21:13:48 <jamielennox> either work and the appeal of doing this in one go is not having to update every project's policy.json multiple times
21:13:56 <diablo_rojo> jamielennox: I got a few cinder cores to weigh in and they are all saying the proposed roles are more complicated than they need to be but agree that there should be more than just admin and non admin
21:14:46 <mugsie> yeah - i like the new project / read only roles, but not the more permjssion style roles
21:14:48 <dolphm> diablo_rojo: that's part of the intent - it's more roles than any one user / deployer needs, but covers all the bases for everyone
21:14:51 <elmiko> seemed to me that you don't *have* to descend into the deep end of the role configurations in that spec right away, or even ever. but, they seemed like nice options.
21:15:01 <jamielennox> diablo_rojo: so we asked for feedback at the tokyo summit and have talked to operators since and this seemed to cover 90% of their use cases, we're definetly looking at this from an ops perspective rather than de
21:15:07 <dolphm> by convention, there's probably a role defined for what you need
21:15:25 <jamielennox> with the per manager roles i think we would cover everything
21:15:45 <breton> don't orgs already have their idea about what their policy is? Maybe our efforts to polish policy.json should rather go into re-using existing orgs' roles and policies?
21:15:46 <dolphm> elmiko: i'd want to split the granular (api managers and per capabilities roles in particular) into a separate spec if we're going to go halfway on anything
21:15:52 <dolphm> instead* of going halfway
21:15:53 <jamielennox> dolphm: ++
21:16:05 <dolphm> breton: that is exactly where this conversation stems from
21:16:13 <elmiko> dolphm: i think that's fair and most likely sensible
21:16:41 <elmiko> i don't have an objections to the fine grained stuff, but i see it as optional to the end-user/deployer
21:16:42 <jamielennox> breton: yes, we want to polish policy - the problem is we want all services to polish their policy in a consistent way
21:16:54 <dolphm> elmiko: absolutely is optional, as proposed
21:17:05 <jamielennox> breton: hence defining a scenario that they would all aim for rather than everyone make up their own roles
21:18:40 <jamielennox> essentially i want people to take the spec back to their ops and project teams and comment on whether the proposed roles are sufficient as it'd be nice to not need to take this through to summit
21:19:02 <dhellmann> ok, that's a good call to action for this one
21:19:15 <dhellmann> does anyone else have any questions to raise right now?
21:19:23 <jamielennox> dolphm: do you have a different timeline there?
21:19:29 <jamielennox> dolphm: or action?
21:19:38 <dolphm> nope, that's my goal
21:19:49 <dolphm> i'd like to propose the resulting policy to at least keystone and nova
21:19:55 <dolphm> i've done keystone, but i went all the way with it
21:20:08 <dolphm> if we're going to break the spec down, i'll do two separate patch sequences
21:20:37 <dolphm> for example, my current patch sequence for keystone starts here: https://review.openstack.org/#/c/274143/
21:20:47 <jamielennox> dolphm: given the nature of keystone i actually don't mind if it goes per manager roles, but obviously on top of the basic ones and not necessarily something we recommend to all projects
21:20:54 <dolphm> i add an identity_admin, then managers, then observers, then per-capability roles
21:21:20 <dhellmann> #info the goal is to review the proposed roles before the summit
21:21:26 <dhellmann> #action everyone please review the common policy spec with your teams
21:21:32 <dolphm> jamielennox: still want to split the effort apart then. my goal in working keystone and nova is to illustrate the impact of this spec to all the services under big tent
21:21:45 <jamielennox> dolphm: ok
21:21:53 <dolphm> implementing in other projects should be low hanging fruit from there
21:22:11 <dolphm> except for project's like ironic :P where there's a bigger hurdle to climb first (using policy at all)
21:22:30 <jamielennox> can we put us back on the agenda for a fortnight?
21:22:38 <jamielennox> ahh, that's 2 weeks
21:22:54 <bknudson_> we don't use the metric system here
21:22:57 <nikhil> I have a question around implementation of this
21:22:58 <dhellmann> jamielennox : sure, you can do that by editing the wiki page
21:23:13 <jamielennox> dhellmann: yep, just aiming to give a timeframe to the project teams
21:23:15 <dolphm> i'll be afk for this meeting in 2 weeks
21:23:30 <nikhil> what level/aspects of services are expected to adhere to this granular sample policy file?
21:23:32 <dolphm> nikhil: ask!
21:23:44 <diablo_rojo> \whois dolphm
21:23:49 <nikhil> (sorry the first one was to avoid last min topic switch)
21:23:50 <dolphm> nikhil: what do you mean by level/aspects ?
21:23:53 <dolphm> diablo_rojo: =)
21:23:59 <diablo_rojo> dolphm: Lol sorry :)
21:24:05 <nikhil> yeah, I will take glance as example
21:24:08 <dolphm> nikhil: Dolph Mathews @ Rackspace
21:24:21 <dolphm> oops, diablo_rojo ^
21:24:25 <nikhil> :)
21:24:33 <nikhil> is it merely roles that are elaborated or
21:25:04 <nikhil> do we have a this sample deployment that points to roles for say "protected properties" that may be used
21:25:05 <nikhil> ?
21:25:25 <nikhil> dunno, this may be on the edge of what we want to provide and what we can actually provide
21:25:26 <dolphm> nikhil: elaborated is a good way to put it
21:25:37 <nikhil> gotcha
21:25:51 <samueldmq> dolphm: jamielennox: I also have a question :)
21:25:59 <stevemar> samueldmq: ask away!
21:26:07 <dolphm> protip: never ask for permission to ask questions
21:26:11 <samueldmq> the per capability roles are the finest we provide right ?
21:26:22 <dolphm> samueldmq: yes, as currently proposed by the spec
21:26:36 <samueldmq> so, isn't it going to be hard to an operator to sync all those fined grained roles inside keystone
21:26:47 <samueldmq> as projects add/remove APIs
21:26:48 <dolphm> there isn't anything finer unless you're talking about per-resource RBAC (like this user has this capability on this particular VM, regardless of the VM's tenancy)
21:27:01 <dolphm> samueldmq: you don't need to create any of these roles in keystone
21:27:02 <samueldmq> are we willing to provide tools to help them in that task ?
21:27:04 <dolphm> samueldmq: not one
21:27:21 <samueldmq> dolphm: don't they come from the token ?
21:27:26 <dolphm> samueldmq: and yes, we could totally provide a openstack role gotta-create-them-all <policy.json>
21:27:40 <dolphm> samueldmq: the roles a user actually has are expressed in the token, yes
21:27:51 <dolphm> samueldmq: the roles a user needs to have is expressed in policy
21:28:15 <samueldmq> dolphm: yes, I am in the most complex case, where one uses all the per-capability roles in his org
21:28:26 <dolphm> this change would make policy read like: admin OR identity_admin OR catalog_manager OR endpoint_manager OR endpoint_create
21:28:31 <samueldmq> so he could make use of such a tool to load the roles in his keystone
21:28:39 <dolphm> samueldmq: sure, why not
21:28:47 <samueldmq> dolphm: nice
21:29:02 <samueldmq> I was just making sure about this, I like the idea (and you know!)
21:29:12 <samueldmq> :)
21:29:25 <samueldmq> dolphm: thanks
21:29:47 <dhellmann> we do have another topic for today, are we ready to move on?
21:30:01 <dolphm> or for a read-only operation like "list endpoints", policy would effectively be: admin, observer, identity_admin, identity_observer, catalog_manager, endpoint_manager, list_endpoints
21:30:11 <dolphm> we can move on if there's another topic
21:30:24 <dhellmann> dolphm : I don't want to cut you short, I thought we'd hit a lull
21:30:29 <dolphm> dhellmann: ++
21:30:38 <jamielennox> dhellmann: i'm done
21:30:46 <dhellmann> ok, we can come back during open discussion if anyone thinks of other questions
21:30:49 <dhellmann> #topic Support for 4-byte unicode for naming volume, snapshot, instance etc.
21:30:55 <dhellmann> sheel & jgregor, you're up
21:30:59 <jgregor> Hello
21:31:04 <sheel> dhellmann: yes we are there
21:31:25 <dhellmann> can you give a brief introduction of the issue? it sounds like a mysql configuration change?
21:31:32 <dhellmann> #link https://review.openstack.org/#/c/280371/
21:31:42 <jgregor> So as of right now MySQL does not support 4 byte unicode
21:31:51 <sheel> ok, so here we want to discuss for support for 4 byte unicode characters in different components..
21:31:52 <bknudson_> keystone doesn't configure mysql as far as I know
21:32:02 <notmorgan> bknudson_: ++
21:32:02 <bknudson_> we just use whatever it's got
21:32:20 <dhellmann> jgregor : it doesn't support them in any configuration at all?
21:32:31 * dhellmann was drafted to chair at the last minute and didn't read the spec ;-)
21:32:52 <jgregor> dhellmann: Not currently
21:33:20 <dulek> From reading the spec I believe it's DB/table/column charset problem? By default it's not 4-byte?
21:33:24 <jgregor> So this was brought up in a Cinder meeting, and it was pointed out there that this could be cross project worthy
21:33:36 <jgregor> By default it is not
21:33:44 <sheel> dulek: right
21:33:50 <jgregor> We would need to update the char set to utf8mb4
21:34:00 <bknudson_> we have had problems in the past where we didn't set the charset on the columns...
21:34:01 <dhellmann> yes, I think we would want all databases to be configured with this setting the same way
21:34:12 <notmorgan> hm. i worry we're going to run into charset utf-8 issues again.
21:34:16 <dhellmann> is that something we do within the schemas in each project?
21:34:22 <notmorgan> but it's not an unreasonable thing to ask.
21:34:33 <notmorgan> dhellmann: in most cases we specify now, iirc, utf-8
21:34:41 <jgregor> notmorgan: What issues were you running into?
21:34:43 <dhellmann> notmorgan : where?
21:34:51 <bknudson_> keystone does this: 'ALTER DATABASE %s DEFAULT CHARACTER SET utf8'
21:34:57 <notmorgan> dhellmann: in the migrations.
21:35:11 <notmorgan> jgregor: we have had many issues with the check to make sure things are utf-8 in keystone
21:35:14 <dhellmann> maybe someone from nova can comment, but I thought they were trying to get away from huge impact migration scripts to support rolling upgrades without downtime
21:35:16 <bknudson_> and all our tables do mysql_engine='InnoDB', mysql_charset='utf8'
21:35:20 <notmorgan> jgregor: it's openstack code, not mysql issues.
21:35:39 <cdent> dhellmann: yes, that's an open question, discussed on the spec
21:35:41 <nikhil> yeah, no consistency here is making the code ugly in a lot of places
21:35:44 <notmorgan> dhellmann: on new tables and on initial creats
21:36:02 <dulek> dhellmann: It's would still be possible to make such migration while keeping the rolling-upgrades guidelines.
21:36:08 <notmorgan> dhellmann: but yes all tables would need an alter.
21:36:09 <dulek> It's just a lot of additional work.
21:36:10 <nikhil> there are these corner cases to be handled in different places that if missed are resulting into 5xx responses
21:36:14 <dhellmann> is the setting table-wide, or column-specific?
21:36:18 <nikhil> and I'd say that really bad
21:36:21 <notmorgan> dhellmann: table wide in mysql
21:36:23 <nikhil> that's*
21:36:28 <dhellmann> notmorgan : thanks
21:36:46 <notmorgan> i've never tried a column specific charset.
21:36:55 <notmorgan> nor looked to see if it even exists
21:37:00 <cdent> nikhil: there's two problems/goals, right? One is to trap the exception that is currently causing the 500 and return a 400 instead. The other is to make it possible to use the wide charsets. We shouldn't conflate those two.
21:37:01 <Kiall> Dumb Q I don't see answered in the spec, what languages make use of 4byte Unicode and can't be represented in 3 bytes?
21:37:18 <samueldmq> notmorgan: bknudson_: ++ keystone migration https://github.com/openstack/keystone/blob/5b868ab849d931b24c8832075fc4d36aef54550b/keystone/common/sql/migrate_repo/versions/067_kilo.py#L36-L37
21:37:24 <jgregor> cdent: That is correct
21:37:34 <sheel> Kiall: Some example in different projects where we notify problem handling 4 byte unicodes:
21:37:43 <sheel> Nova:  https://bugs.launchpad.net/nova/+bug/1545729
21:37:43 <openstack> Launchpad bug 1545729 in OpenStack Compute (nova) "Use 4 byte unicode for entity names in mysql" [Undecided,Invalid] - Assigned to Sheel Rana (ranasheel2000)
21:37:44 <sheel> Keystone: https://bugs.launchpad.net/keystone/+bug/1545736
21:37:45 <sheel> Cinder:  https://bugs.launchpad.net/cinder/+bug/1542413
21:37:45 <sheel> Glance :  https://blueprints.launchpad.net/glance/+spec/
21:37:46 <sheel> heat :  https://bugs.launchpad.net/heat/+bug/1545740
21:37:46 <openstack> Launchpad bug 1545736 in OpenStack Identity (keystone) "keystone role create failed when 4 byte unicode character is provided in name field" [Wishlist,Triaged] - Assigned to Sheel Rana (ranasheel2000)
21:37:47 <openstack> Launchpad bug 1542413 in Cinder "Unable to use 4-bytes unicode when creating volume, volume_type, CG, etc" [Medium,Confirmed] - Assigned to Jacob Gregor (jgregor)
21:37:48 <openstack> Launchpad bug 1545740 in heat "support for unicode character handling in stack-create operation" [Undecided,New] - Assigned to Sheel Rana (ranasheel2000)
21:37:48 <jgregor> Kiall: Chinese, Japanese, Korean
21:37:53 <nikhil> oh gosh
21:38:03 <nikhil> cdent: and in glance we'd this issue were we are changing the responses for 500s to 4xx but that's just
21:38:26 <nikhil> pain as it's merely redressing issues for two types of DBs (one being MySQL)
21:38:27 <sheel> nikhil: cdent: yes but atleast in glance things are handled gracefully
21:38:30 <Kiall> jgregor: thanks, I somehow thought those were covered in 3byte.
21:38:36 * bswartz notices new topic
21:38:46 <nikhil> as we support more DBs I think we are going to run into multiple of such issues
21:38:53 <nikhil> sheel: sure, but after a ton!!! of work
21:38:59 <bswartz> +1 for 4-byte utf-8 support
21:38:59 <nikhil> and making the code ugly as hell
21:39:11 <sheel> nikhil: yep
21:39:11 <nikhil> and catching stuff where it shouldn't necessarily be
21:39:24 <bknudson_> I would prefer it if keystone didn't have to care about this.
21:39:40 <notmorgan> bknudson_: agreed
21:39:41 <nikhil> ++
21:39:47 <nikhil> same goes for glance
21:40:04 <mugsie> jgregor: are you sure they are not in utf8 3byte?
21:40:38 <sheel> mugsie: some of them are not there in 3 bytes...
21:40:39 <sheel> https://www.drupal.org/node/1314214
21:40:57 <Kiall> Another q.. Has anyone measured the performance impact of switching a large e.g. instances table over?
21:41:21 <dhellmann> Kiall : the impact of the migration itself, or of running with it that way after the migration?
21:41:22 <fungi> reminds me of during the vancouver summit when we discovered that putting a 4-byte codepoint in a pad caused etherpad to go into a mad crash-and-restart loop
21:41:25 <notmorgan> so, it's some kanji not all that are affected.
21:41:36 <dhellmann> fungi : yep
21:41:41 <notmorgan> not all.
21:41:42 <bswartz> I understood it the issue in mysql was that tables consumed much more disk/memory
21:41:50 <Kiall> Running with it after migration
21:41:53 <dulek> Kiall: Well, online-schema-upgrades guidelines Nova have would block such migration. It would require an approach with a table copy probably.
21:42:12 <bswartz> any performance concerns would be related to exploded resource consumption
21:42:15 <dulek> Kiall: Ah, okay, my asnwer assumed migration itself.
21:42:35 <bknudson_> does it expand utf to fixed-width?
21:42:39 <fungi> fwiw infra basically went through the necessary mysql changes to switch etherpad tables to 4-byte unicode encoding/collation, and the commands in the spec look like what i remember us doing
21:42:42 <bknudson_> (mysql)
21:42:51 <dhellmann> fungi : cool, that's good to know
21:43:37 <dulek> We seem to agree that this is a lot of work for any project. Is it really worth it?
21:44:11 <stevemar> dulek: that's what i was asking when the spec was proposed
21:44:13 <bknudson_> what's the work involved?
21:44:28 <stevemar> i couldn't get a clear use case, aside from "i want to use 4-byte characters"
21:44:33 <notmorgan> so, for keystone, i don't see a huge reason why we wouldn't want this. it would be a change to create a new migration and update our starting one (we're not on the rolling migrations stuff yet)
21:44:41 <notmorgan> but, it is a chunk of work regardless.
21:44:50 <bswartz> I think it's worth it -- it's a matter of correctness
21:45:03 <dhellmann> yeah, I think if we have users or potential uses who can't put their language into the database, we should fix that.
21:45:08 <notmorgan> for nova or other serivices that are on the rolling schema thing, it's a ton of work.
21:45:09 <dhellmann> *potential users
21:45:10 <dulek> bknudson_: In case of Nova and Cinder migrations will get really complicated due to rolling upgrades support.
21:45:11 <smcginnis> bswartz: You want to use emojis for your share names, don't you.
21:45:17 <sheel> bswartz: +1
21:45:29 <bswartz> ¬_¬
21:45:37 <dhellmann> dulek : yeah, I think we're going to need more detail about how to make those scenarios work before approving the spec
21:45:46 <bknudson_> let's say the user configured mysql correctly, does openstack code force 3-byte?
21:45:54 <stevemar> openstack server create "(╯°□°）╯︵ ┻━┻)"
21:45:56 <notmorgan> bknudson_: our migrations would override it
21:45:56 <dhellmann> bknudson_ : oh, wow, I hope not
21:46:03 <notmorgan> bknudson_: but python shouldn't care
21:46:05 <smcginnis> stevemar: hah!
21:46:12 <dulek> dhellmann: Sure, I can try to PoC something with sheel for Cinder to make amount of work measurable.
21:46:14 <notmorgan> python has supported wide utf-8 since 2.2
21:46:16 <notmorgan> iirc
21:46:24 <dhellmann> stevemar : I think you mean terminate not create
21:46:28 <notmorgan> https://www.python.org/dev/peps/pep-0261/ i think
21:46:38 <stevemar> dhellmann: oh right, silly me
21:46:39 <cdent> the issue is with explicit charset declaration in migrations
21:46:40 <stevemar> :)
21:46:56 <cdent> and mysql's use of utf8 to _not_ meant 4byte. to get that you have to be explicit
21:46:57 <stevemar> dulek: that sounds like a good plan
21:47:00 <sheel> dulek: yep
21:47:07 <bknudson_> cdent: like mysql_charset='utf8' ?
21:47:10 <cdent> yes
21:47:13 <bknudson_> oops!!
21:47:22 <bknudson_> we did that to prevent some other problem!
21:47:28 <cdent> of course
21:47:36 <dhellmann> cdent : yeah, I wonder if we can build some tools to automate checks for that
21:47:51 <notmorgan> dhellmann: just don't do it in the migrate way oslo_db does for charset utf-8
21:48:04 <notmorgan> so it checks before a new migration, so you get wedged :(
21:48:17 <dhellmann> notmorgan : yeah :-(
21:48:25 <Kiall> notmorgan: that was fun.. Or not.
21:49:03 <dhellmann> sheel & jgregor: is it clear what your next steps are?
21:49:28 <jgregor> dhellmann: Yep
21:49:35 <bknudson_> can we just store strings in binary?
21:49:42 <sheel> dhellmann: yeah. I think measurement of actual work required for supporting it
21:49:51 <dhellmann> bknudson_ : gzip or bz2?
21:50:08 <dulek> jgregor, sheel: I can support you on the Cinder PoC from rolling upgrades perspective.
21:50:09 <notmorgan> dhellmann: base64 encode!
21:50:13 <notmorgan> dhellmann: everything!
21:50:16 <dhellmann> notmorgan :-)
21:50:23 * bswartz barfs
21:50:27 <notmorgan> dhellmann: including after we base64 the base64 encoded encoded string string
21:50:33 <jgregor> dulek: Sounds great
21:50:35 <sheel> dulek: yes, that would work..
21:50:57 <samueldmq> notmorgan: ++ to get it as small as possible
21:51:04 <samueldmq> :-)
21:51:36 <dhellmann> ok, sounds good
21:51:42 <dhellmann> #topic Open discussion
21:51:59 * notmorgan pushes soapbox back under the table.
21:52:07 <dhellmann> we have a few minutes, if we have any late announcements or need to revisit something we've already discussed
21:52:55 <dhellmann> going once
21:53:07 <dhellmann> going twice
21:53:24 <notmorgan> SOLD!
21:53:27 <dhellmann> ok, then, I think we'll call that done
21:53:33 <cdent> huzzah
21:53:34 <dhellmann> thanks for joining us everyone
21:53:40 <nikhil> thx
21:53:48 <dhellmann> #endmeeting