Monday, 2015-06-22

*** markvoelker has joined #openstack-ansible00:01
*** markvoelker has quit IRC00:05
*** abitha has joined #openstack-ansible00:14
*** annashen has joined #openstack-ansible00:48
*** JTen_ has quit IRC00:52
*** annashen has quit IRC01:10
*** annashen has joined #openstack-ansible01:17
*** annashen has quit IRC01:46
*** annashen has joined #openstack-ansible01:49
*** markvoelker has joined #openstack-ansible01:50
*** markvoelker has quit IRC01:55
*** georgem1 has joined #openstack-ansible01:56
*** stevemar has joined #openstack-ansible01:57
*** annashen has quit IRC02:01
*** galstrom_zzz is now known as galstrom02:46
*** sdake_ has quit IRC03:10
*** jmccrory has quit IRC03:14
*** jmccrory has joined #openstack-ansible03:16
*** galstrom is now known as galstrom_zzz03:29
*** annashen has joined #openstack-ansible03:34
*** galstrom_zzz is now known as galstrom03:34
*** markvoelker has joined #openstack-ansible03:38
*** galstrom is now known as galstrom_zzz03:41
*** markvoelker has quit IRC03:43
*** abitha has quit IRC03:49
*** annashen has quit IRC03:54
*** JRobinson__ is now known as JRobinson__afk03:57
*** sdake has joined #openstack-ansible04:04
*** georgem1 has quit IRC04:10
*** annashen has joined #openstack-ansible04:12
*** JRobinson__afk is now known as JRobinson__04:30
*** annashen has quit IRC04:31
*** radek has joined #openstack-ansible05:07
*** radek__ has joined #openstack-ansible05:18
*** stevemar has quit IRC05:19
*** radek has quit IRC05:21
*** markvoelker has joined #openstack-ansible05:27
*** shausy has joined #openstack-ansible05:27
*** markvoelker has quit IRC05:32
*** shausy has quit IRC05:38
*** shausy has joined #openstack-ansible05:40
*** shausy has quit IRC05:45
*** jmccrory has quit IRC05:52
*** jmccrory has joined #openstack-ansible05:57
*** javeriak has joined #openstack-ansible06:56
*** JRobinson__ has quit IRC07:10
*** markvoelker has joined #openstack-ansible07:16
*** markvoelker has quit IRC07:21
*** vincent_1dk has quit IRC08:13
*** vincent_vdk has joined #openstack-ansible08:14
*** javeriak has quit IRC08:54
*** markvoelker has joined #openstack-ansible09:05
*** markvoelker has quit IRC09:09
*** sdake has quit IRC10:43
*** britthou_ has quit IRC10:43
*** lbragstad has quit IRC10:43
*** dolphm has quit IRC10:43
*** _d34dh0r53_ has quit IRC10:43
*** odyssey4me_ has quit IRC10:43
*** persia has quit IRC10:43
*** eglute_s has quit IRC10:43
*** sigmavirus24_awa has quit IRC10:43
*** gus has quit IRC10:43
*** bgmccollum has quit IRC10:43
*** jroll has quit IRC10:43
*** persia has joined #openstack-ansible10:43
*** persia has quit IRC10:43
*** persia has joined #openstack-ansible10:43
*** bgmccollum has joined #openstack-ansible10:43
*** gus has joined #openstack-ansible10:43
*** britthouser has joined #openstack-ansible10:43
*** jroll has joined #openstack-ansible10:43
*** odyssey4me has joined #openstack-ansible10:43
*** lbragstad has joined #openstack-ansible10:44
*** sdake has joined #openstack-ansible10:44
*** dolphm has joined #openstack-ansible10:44
*** eglute has joined #openstack-ansible10:44
*** d34dh0r53 has joined #openstack-ansible10:45
*** sigmavirus24_awa has joined #openstack-ansible10:46
*** markvoelker has joined #openstack-ansible10:53
*** subscope has joined #openstack-ansible10:56
*** markvoelker has quit IRC10:58
svgdstanek: dolphm sigmavirus: testing requests to glance (triggering keystone) while I disable the [memcache] token memcached and the keystone in one to more containers: even after a time some requests fail ('Invalid OpenStack Identity credentials.').....11:00
svgso This is definitely not HA :(11:00
svgto give you an idea: of failure rate: https://dl.dropboxusercontent.com/u/13986042/20150622131444.png11:15
svggiven all keystones need to share the same set of caches, I don't see how to solve this (given in the past one got back from useing an LB endpoint)11:16
svgon the plus: this does not trigger long timeouts I saw earlier, so that has to be related to the regular [cache]11:16
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment: Allow galera wsrep_provider_options to be customised  https://review.openstack.org/19110611:17
*** sdake_ has joined #openstack-ansible11:27
*** jlvillal has quit IRC11:28
*** sdake has quit IRC11:30
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment: Allow galera wsrep_provider_options to be customised  https://review.openstack.org/19110611:39
*** andyhky` is now known as andyhky11:41
*** markvoelker has joined #openstack-ansible11:54
*** markvoelker has quit IRC11:59
openstackgerritgit-harry proposed stackforge/os-ansible-deployment: Add configurable option [cinder]/cross_az_attach  https://review.openstack.org/19410212:02
*** markvoelker has joined #openstack-ansible12:03
*** b3rnard0 has left #openstack-ansible12:14
*** b3rnard0 has joined #openstack-ansible12:14
*** britthou_ has joined #openstack-ansible12:16
*** britthouser has quit IRC12:17
*** tobasco_ is now known as tobasco12:32
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment-specs: Spec for multiregion ansible deployment  https://review.openstack.org/19242112:40
openstackgerritgit-harry proposed stackforge/os-ansible-deployment: Add neutron.conf [database] options  https://review.openstack.org/19412412:45
*** KLevenstein has joined #openstack-ansible12:57
*** jmccrory has quit IRC13:14
*** jaypipes has joined #openstack-ansible13:15
*** jmccrory has joined #openstack-ansible13:15
*** tlian has joined #openstack-ansible13:15
*** 1JTAAA236 is now known as cloudnull13:22
cloudnullmorning13:22
cloudnullis "https://review.openstack.org/" timing out for folks ?13:22
odyssey4memorning cloudnull13:22
odyssey4menope, not for me13:23
cloudnullmorning odyssey4me13:25
odyssey4mecloudnull hmm, now it is timing out13:25
odyssey4mewell, it's very slow13:25
cloudnullyea. i cant even hit it from a cloudserver13:25
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: Updated kilo to the latest SHAs - 06.20.2015  https://review.openstack.org/19384513:31
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: Updated juno to the latest SHAs - 06.20.2015  https://review.openstack.org/19384613:33
*** jroll has quit IRC13:36
*** jroll has joined #openstack-ansible13:36
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: Updated master to the latest SHAs - 06.20.2015  https://review.openstack.org/19384413:37
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: Updated icehouse to the latest SHAs - 06.20.2015  https://review.openstack.org/19384813:37
*** rromans_ is now known as rromans13:48
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment-specs: Cleaned up all specs  https://review.openstack.org/19383213:51
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: [WIP] Updated keystone to use fernet as the default  https://review.openstack.org/19372913:55
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: Add support for deploying Keystone with Fernet  https://review.openstack.org/18999813:55
openstackgerritKen Johnston proposed stackforge/os-ansible-deployment-specs: Spec for keystone federation unusable deployment  https://review.openstack.org/19414713:55
svgI think I may conclude that keystone + memcache for Tokens is *not* higly available. Not even fault tolerant.14:02
dstaneksvg: exactly!14:04
dstanekit's not designed to be14:04
*** stevemar has joined #openstack-ansible14:04
svgit goes even a bit further than that14:06
svgbringing some of the token memcaches down obiously triggers issues14:07
svgbut bringing them back up is not enough14:07
dstanekmemcached will also silently drop your data when it needs to14:07
svgat that point, with deploying some heat stacks, we kept getting auth errors14:07
svg... until we erstarted all nova-api-os-compute services....14:07
dstanekif you cycle a memcache you lose all of your tokens on that node14:07
svgstill pretty weird that restarting a nova service helps here?14:08
dstanekis nova doing an auth to get a new token?14:09
svgbtw, I was not able to reproducue any troubles wit the plain [cache] - last week we saw terrible slow down in client respones (10's of seconds)14:09
svgI didn't notice / watch that I'm afraid14:10
svglong live the fernet alternative I guess...14:10
svgIs that planned to be backported to kilo?14:10
cloudnullso what im hearing is that we should make fernet a bigger priority for master/kilo14:10
cloudnullsvg: yes14:11
svgcloudnull: I would say so, yes.14:11
*** sigmavirus24_awa is now known as sigmavirus2414:12
svgright now, if one keystone container, or at least it;s memcaced goed awol, all hell breaks loose.14:12
openstackgerritKen Johnston proposed stackforge/os-ansible-deployment-specs: Spec for keystone federation unusable deployment  https://review.openstack.org/19414714:13
cloudnullwell that's no good.14:13
cloudnullsvg: you could change your driver to use sql backed tokens. that should go without issues.14:13
dstanekfyi...this has been reported several times in the past - just closed another related bug: https://bugs.launchpad.net/keystone/+bug/143632414:13
openstackLaunchpad bug 1436324 in Keystone "Keystone is not HA with memcache as token persistence driver" [Low,Won't fix] - Assigned to Boris Bobrov (bbobrov)14:13
svgcloudnull: I believe the sql config is not something that osad allows without patching?14:16
cloudnullyes, getting config one sec14:16
svgyeah, looking at   http://docs.openstack.org/kilo/config-reference/content/section_keystone.conf.html14:19
svgoh it is, seems like just changing the var keystone_token_driver14:21
svgkeystone.token.persistence.backends.sql.Token14:22
cloudnullsvg:  change `keystone_token_driver: "keystone.token.persistence.backends.sql.Token"` in your user_vars file and you should be good to go .14:22
cloudnullah. totally late there.14:22
cloudnullyou got it.14:22
svg:)14:22
svgthanks for confirmation, was not sure that was the only needed change14:22
*** Mudpuppy has joined #openstack-ansible14:26
openstackgerritKen Johnston proposed stackforge/os-ansible-deployment-specs: Spec for keystone federation unusable deployment  https://review.openstack.org/19414714:28
mancdazcloudnull I added a discussion point around bug/no bug for sha bumps and version bumps, for the next meeting, on the wiki. I can see both arguments, but it's worth chatting about it14:30
cloudnullgreat14:30
cloudnullso in your opinion are we looking to hold the current sha bumps until that discussion ?14:31
mancdazcloudnull no not really. We can always add a bug later and reference the reviews that went in14:32
mancdazit's less about having the bug referenced in the commit message for me, and more about having something that can be 'released' in launchpad14:32
mancdazso people can go to a milestone page and easily see what changed/was added14:32
odyssey4mecloudnull personally I can see the argument for skipping the bug/bp ref in master (as it's considered unstable)... but not for the other branches14:33
mancdazcloudnull I don't think it's worth holding up dev for14:33
*** galstrom_zzz is now known as galstrom14:33
odyssey4meit could easily be a bp without a spec14:33
cloudnullso do you think it better to have a bug/bp that we update every in two weeks for two supported branches for 15 months ? also you cant "release" a bp as implemented more than once so it would have to be new bug created every time.14:34
cloudnullfood for thought.14:35
mancdazyeah you're right it would need to be a bug14:35
cloudnullit could be the same bug re-created all the time, with a targeted series.14:36
*** mfisch` is now known as mfisch14:36
cloudnullso one bug per the two/three release branches.14:36
*** mfisch is now known as Guest8229014:36
mancdazright14:37
cloudnullbut made every two weeks.14:37
mancdaz'update to latest stable'14:37
cloudnullbut isn't that in the git log and the release notes for a released milestone?14:37
mancdazwell, docs team point people at the milestone page for release notes for juno releases currently14:38
odyssey4mehmm, if you re-use the same bug every time then you end up losing the reference for the previous milestone (as you have to re-target it).14:39
mancdazodyssey4me not the same bug14:39
mancdaza new bug each 2 weeks14:39
odyssey4meotherwise that would've been great\14:39
odyssey4menew bug every two weeks obviously caters for the need14:40
odyssey4meah, you mean a new bug for all software updates - then use partial- instead of closes-bug in the commit?14:40
cloudnullmancdaz: yes the docs team does point people at the milestone page, where they have the ability to click the change log button and read what happened in the release.14:41
mancdazodyssey4me not sure it matters - closes doesn't actually close the bug anyway14:41
odyssey4memancdaz closes-bug will mark it as fix-committed whereas partial-bug does not14:41
mancdazfor reals?14:42
mancdazdoes that work14:42
palendaeShould now that the stable/ fix is in14:42
cloudnullits supposed to14:42
mancdazacross multiple branches?14:42
odyssey4memancdaz yeah, as far as I've seen that's how it works14:42
odyssey4mepartial- and related- are tags designed for that purpose14:42
cloudnullthere are going to be things that go into a release that are not "targeted" and while its nice to see all the things that went in from a lp point of view the git log, which we are updating on every release, is the source of truth.14:43
mancdazcloudnull ok if we're adding a full diff between reelases to that part of the milestone page, I care less14:43
cloudnullhttps://launchpad.net/openstack-ansible/kilo/11.0.314:44
mancdazas long as we add dates/versions in the commit message title for those bumps14:44
odyssey4mecloudnull mancdaz ah, I had forgotten about the changelog - that's useful14:44
odyssey4mein that case I agree - as long as the subject line is specific enough, then it's great14:45
cloudnulla good example https://launchpad.net/openstack-ansible/icehouse/9.0.1014:45
cloudnull3 targeted, 6 changes .14:45
cloudnullmancdaz: +1 on the date change in the subject for the bumps. that was a great suggestion from odyssey4me14:46
palendaeI missed it, that's the date the SHAs were captured?14:46
mancdazdone14:46
mancdazpalendae yep14:46
palendaeMakes sense14:46
*** Mudpuppy_ has joined #openstack-ansible14:49
*** jlvillal has joined #openstack-ansible14:49
*** jlvillal has quit IRC14:51
odyssey4mecloudnull mancdaz palendae so I'm down with not doing bug/bp commit references ad long as the subject line appropriately covers the change (like package/sha updates with their version/date)... so how far do we extend this? We have a lot of bugs being reported at the moment which aren't bugs - many are simply to facilitate small feature additions or small changes to the way things work.14:51
*** jlvillal has joined #openstack-ansible14:52
*** Mudpuppy has quit IRC14:52
palendaeWell, those need tickets/issues/LP bugs still...14:52
openstackgerritAndy McCrae proposed stackforge/os-ansible-deployment: Move Cinder-volumes to "on metal"  https://review.openstack.org/19417614:52
odyssey4meI do think that there should be a conduit for these things, but perhaps some of them should just be committed?14:52
*** sdake_ has quit IRC14:52
cloudnullsmall feature change we should add a bug, medium to large feature change we should have a bp/spec.14:53
odyssey4meThat said, I think the reason I brought up the issue originally was because we had forgotten to backport something because there was no LP reference for it.14:53
mancdazthat's a good argument for having a bug to reference - tracking of backport tags etc14:54
odyssey4meSo perhaps the simple rule should be that if it may require a backport, then it should have a bug ref?14:54
odyssey4meBut then what about rabbitmq and other such updates - those should be backports, but doing a bug ref every time is silly.14:56
cloudnullidk if rabbitmq or galera should be backports.14:56
odyssey4mecloudnull well, galera gets from the current repo which only contains the latest version... so that's out of our hands14:57
cloudnullespecially if they're large bumps in the stack. or if we do backport something like galera + mariadb10 it should be in a feature version . 11.1.x14:57
odyssey4merabbitmq, however, we control the version14:57
cloudnullthats true galera gets the current version but in the 5.5 series14:58
cloudnullbut with one of the updated reviews we're pushing to 1014:58
cloudnulli'd say the same goes with rabbitmq too.14:58
palendaeWould it make sense to only backport if missing version forces us to?14:58
palendaeLike an old version drops off upstream repos?14:58
odyssey4meah yes, so that's good to differentiate - if it's a major version change then there should be a bp/spec14:58
cloudnullid say so14:59
odyssey4mepalendae not really, consider security hotfixes14:59
palendaeTrue14:59
mancdazoh that reminds me, we might be able to move to active/active/active etc on the galera side15:01
mancdazsince the OS projects have largely resolved their bad handling of locks15:01
odyssey4memancdaz oh, is that in kilo or liberty?15:01
mancdazwell ok, liberty probably15:02
openstackgerritMerged stackforge/os-ansible-deployment: Add global endpoint_type_proto options  https://review.openstack.org/19357315:02
openstackgerritMerged stackforge/os-ansible-deployment: Correct local_settings when AVAILABLE_REGIONS is set  https://review.openstack.org/19100415:02
odyssey4memancdaz I'm thinking that we should let https://review.openstack.org/189998 through the gate and resolve the key rotation and max_keys issue in later patches once we can have some more testing done to figure out what works best?15:04
openstackgerritMerged stackforge/os-ansible-deployment: Add configurable option [cinder]/cross_az_attach  https://review.openstack.org/19410215:06
mancdazodyssey4me especially since key rotation and specifically distribution is largely an issue in traditional multi-region type deployments15:06
openstackgerritMerged stackforge/os-ansible-deployment: Add neutron.conf [database] options  https://review.openstack.org/19412415:06
mancdazso yeah15:06
mancdazoh wait that wasn't being accounted for anyway - just container - container distribution]15:07
*** Mudpuppy_ is now known as Mudpuppy15:09
mancdazis there some way to exclude an external CI system from stackalytics?15:09
odyssey4memancdaz I would guess that the way to do it would be to have it vote properly - ie verify instead of review15:12
cloudnullhas the external CI been fixed, it seems to be unhappy all the time.15:13
mancdazcloudnull it's been turned off I think15:14
mancdazhttps://github.com/stackforge/stackalytics/blob/master/etc/default_data.json#L1205615:14
mancdaznice alias for rackspace15:14
mancdaz"Korea Telcom, friends with lots of people"15:15
mancdaz??15:15
openstackgerritKen Johnston proposed stackforge/os-ansible-deployment-specs: Spec for keystone federation ansible deployment  https://review.openstack.org/19414715:15
cloudnulldolphm: dstanek: http://logs.openstack.org/29/193729/6/check/os-ansible-deployment-dsvm-check-commit/20f11a4/console.html#_2015-06-22_14_46_08_643 - seems that fernet is presently incompatible with tempest ?15:15
*** daneyon has joined #openstack-ansible15:17
dolphmcloudnull: hmm, i had a conversation about that check a few weeks ago, but it was the opposite issue then. i'll investigate today15:18
cloudnullin that last run i pulled the latest tempest just to be sure.15:18
*** georgem1 has joined #openstack-ansible15:19
cloudnullsame error as before "ValueError: time data '2015-06-21T13:41:25.824964Z' does not match format '%Y-%m-%dT%H:%M:Z'"15:19
cloudnullit seems that fernet is too exact . =)15:19
openstackgerritKen Johnston proposed stackforge/os-ansible-deployment-specs: Spec for keystone federation ansible deployment  https://review.openstack.org/19414715:21
dolphmcloudnull: wait, the expected format is missing seconds altogether?15:22
cloudnullthats what it says.15:22
*** jwagner is now known as jwagner_away15:22
*** jwagner_away is now known as jwagner15:22
cloudnullit has seconds.15:23
cloudnulljust not microseconds .15:23
dolphmcloudnull: the format you pasted (?) has no seconds at all ('%Y-%m-%dT%H:%M:Z'")15:23
cloudnulli think thats a paste failure15:24
cloudnullhttp://logs.openstack.org/29/193729/6/check/os-ansible-deployment-dsvm-check-commit/20f11a4/console.html#_2015-06-22_14_46_08_64315:24
dolphmcloudnull: okay, just wanted to make sure you weren't looking at something i was missing15:26
*** daneyon_ has joined #openstack-ansible15:26
*** daneyon has quit IRC15:29
cloudnulldolphm:  do you know of a specific tempest lib bug tracker or is it all wrapped up in https://bugs.launchpad.net/tempest15:30
dolphmcloudnull: i'm not aware of a separate one15:30
cloudnullok15:30
cloudnulllooks like it may be fixed in master temptest-lib15:33
cloudnullhttps://github.com/openstack/tempest-lib/blob/master/tempest_lib/auth.py#L319-L32315:33
cloudnullbut they've not released a new version since april.15:33
palendaeCourse not15:34
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: [WIP] Updated keystone to use fernet as the default  https://review.openstack.org/19372915:37
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: [WIP] Updated MariaDB to the new release version  https://review.openstack.org/17825915:39
odyssey4mecloudnull it sounds like we may have to track a newer sha for tempest and tempest-lib?15:39
openstackgerritIan Cordasco proposed stackforge/os-ansible-deployment: Add support for deploying Keystone with Fernet  https://review.openstack.org/19419415:41
*** metral is now known as metral_zzz15:41
cloudnullodyssey4me:  i added that to the fernet review . just to see if it goes.15:41
cloudnullbut im not all that hopeful15:41
cloudnullwe're already on https://github.com/stackforge/os-ansible-deployment/blob/master/playbooks/defaults/repo_packages/openstack_other.yml#L4115:41
cloudnullwell maybe not15:42
cloudnullthe change to fix was authored may515:43
cloudnullbut merged june 20 https://review.openstack.org/#/c/180355/15:43
*** rrrobbb has joined #openstack-ansible15:45
cloudnulldolphm: so all the things may already be fixed. as of the 20th. we're testing now. https://jenkins01.openstack.org/job/os-ansible-deployment-dsvm-check-commit/492/15:47
sigmavirus24cloudnull: unfortunately 'recerify' doesn't work ;)15:47
cloudnullfuck spelling . . .15:48
cloudnullthanks for the catch/fix15:48
dolphmcloudnull: i don't think that _verify_expiry method maintains the spirit of that change... it appears to check multiple formats and will fail if either are incorrect?! unless i'm misreading the test, that makes no sense15:50
cloudnull:\15:51
cloudnullyes it appears that the test for the auth test may be broken.15:52
sigmavirus24http://logs.openstack.org/50/193850/2/gate/os-ansible-deployment-dsvm-check-commit/fc2ca78/console.html#_2015-06-22_15_42_48_372 btw is why your patch failed cloudnull15:54
svgcloudnull: seems sql now complains about  Too many connections  :)15:54
cloudnullsigmavirus24:  yup and thats related to https://github.com/ansible/ansible-modules-core/issues/149715:55
cloudnullsvg: welcome to the game15:55
cloudnullsvg:  how many connections were there ?15:56
*** galstrom is now known as galstrom_zzz15:57
svgstill looking15:58
*** metral_zzz is now known as metral16:02
svgThe calcculated value is 800, most nodes are around 600, one node has 485716:04
svglet's try with another lb method on f516:05
openstackgerritgit-harry proposed stackforge/os-ansible-deployment: Add configurable option [cinder]/cross_az_attach  https://review.openstack.org/19421316:06
*** galstrom_zzz is now known as galstrom16:07
*** Guest82290 is now known as mfisch16:10
*** mfisch has quit IRC16:10
*** mfisch has joined #openstack-ansible16:10
odyssey4mehmm, so with regards to https://review.openstack.org/194194 - should this perhaps wait for a major/minor release and not be allowed into a hotfix patch?16:11
sigmavirus24hm16:12
sigmavirus24good question odyssey4me16:12
palendaeThat sounds reasonable to me16:12
sigmavirus24Also, thanks for inadvertantly pointing out that review -x is different than review -X16:12
sigmavirus24and I fubar'd that cherry-pick16:12
palendaeI thought it was an 11.1.0 thing16:12
odyssey4meyep, I think that backport should be held back for 11.116:13
openstackgerritIan Cordasco proposed stackforge/os-ansible-deployment: Add support for deploying Keystone with Fernet  https://review.openstack.org/19419416:13
*** javeriak has joined #openstack-ansible16:32
openstackgerritMerged stackforge/os-ansible-deployment: Updated kilo to the latest SHAs - 06.20.2015  https://review.openstack.org/19384516:37
openstackgerritMerged stackforge/os-ansible-deployment: Updated juno to the latest SHAs - 06.20.2015  https://review.openstack.org/19384616:37
*** javeriak has quit IRC16:39
*** Mudpuppy has quit IRC16:43
*** Mudpuppy_ has joined #openstack-ansible16:43
*** javeriak has joined #openstack-ansible16:45
*** daneyon has joined #openstack-ansible16:46
openstackgerritMerged stackforge/os-ansible-deployment: Allow galera wsrep_provider_options to be customised  https://review.openstack.org/19110616:46
openstackgerritMerged stackforge/os-ansible-deployment: Remove invalid client config option  https://review.openstack.org/19383316:46
openstackgerritMerged stackforge/os-ansible-deployment: Remove invalid client config option  https://review.openstack.org/19384116:46
*** daneyon_ has quit IRC16:47
*** javeriak has quit IRC16:50
*** daneyon_ has joined #openstack-ansible16:58
*** daneyon has quit IRC16:58
*** daneyon has joined #openstack-ansible16:59
sigmavirus24So, is fernet a pre-requirement for federation or am I making things up/17:01
dolphmsigmavirus24: not related17:01
sigmavirus24okay17:01
* sigmavirus24 thought it was for some reason17:01
* sigmavirus24 goes to read more docs17:02
sigmavirus24oh a summit talk17:02
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment: Allow galera wsrep_provider_options to be customised  https://review.openstack.org/19423617:02
* sigmavirus24 goes to watch that17:02
*** daneyon_ has quit IRC17:03
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: [WIP] Updated keystone to use fernet as the default  https://review.openstack.org/19372917:03
*** javeriak has joined #openstack-ansible17:03
odyssey4mecloudnull sigmavirus24 perhaps launchpad needs a milestone for 11.1.0 to add https://bugs.launchpad.net/openstack-ansible/+bug/1463569 to :)17:09
openstackLaunchpad bug 1463569 in openstack-ansible trunk "Add tasks for Keystone deployment using Fernet tokens" [Medium,In progress] - Assigned to Ian Cordasco (icordasc)17:09
*** dkalleg has joined #openstack-ansible17:12
*** galstrom is now known as galstrom_zzz17:14
*** galstrom_zzz is now known as galstrom17:15
*** galstrom is now known as galstrom_zzz17:16
*** sdake_ has joined #openstack-ansible17:18
*** daneyon has quit IRC17:18
*** daneyon has joined #openstack-ansible17:19
*** daneyon has quit IRC17:20
openstackgerritDolph Mathews proposed stackforge/os-ansible-deployment-specs: Spec for keystone federation ansible deployment  https://review.openstack.org/19414717:21
*** daneyon has joined #openstack-ansible17:21
*** dkalleg has quit IRC17:22
*** daneyon has quit IRC17:23
*** annashen has joined #openstack-ansible17:29
*** daneyon has joined #openstack-ansible17:30
openstackgerritMerged stackforge/os-ansible-deployment: Added flag to instruct yaprt to ignore tempest  https://review.openstack.org/19385017:31
openstackgerritMerged stackforge/os-ansible-deployment: Add support for deploying Keystone with Fernet  https://review.openstack.org/18999817:31
openstackgerritKen Johnston proposed stackforge/os-ansible-deployment-specs: Spec for accepting ADFS as identity provider  https://review.openstack.org/19425517:35
stevemardolphm, anything in particular i should look out for re: federationy support?17:38
*** Verilium_ is now known as Verilium17:38
openstackgerritMiguel Grinberg proposed stackforge/os-ansible-deployment: [WIP] Keystone idp configuration  https://review.openstack.org/19425917:40
openstackgerritMiguel Grinberg proposed stackforge/os-ansible-deployment: [WIP] Keystone idp configuration  https://review.openstack.org/19425917:43
*** dkalleg has joined #openstack-ansible17:45
*** abitha has joined #openstack-ansible17:49
sigmavirus24odyssey4me: seems reasonable17:50
dolphmstevemar: the review above ( https://review.openstack.org/194147 ) just covers the use cases we're pursuing against kilo. a sanity check would always be appreciated!17:51
*** Mudpuppy_ is now known as Mudpuppy17:55
*** Mudpuppy_ has joined #openstack-ansible18:05
*** Mudpuppy_ has quit IRC18:07
*** Mudpuppy_ has joined #openstack-ansible18:07
*** Mudpuppy_ has quit IRC18:08
*** Mudpuppy has quit IRC18:08
*** Mudpuppy has joined #openstack-ansible18:09
*** alextricity_r has joined #openstack-ansible18:49
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment-specs: Spec for keystone federation ansible deployment  https://review.openstack.org/19414719:00
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment-specs: Spec for keystone federation ansible deployment  https://review.openstack.org/19414719:03
*** galstrom_zzz is now known as galstrom19:08
sigmavirus24odyssey4me: since you're clearly still up19:08
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment-specs: Spec for multiregion ansible deployment  https://review.openstack.org/19242119:09
odyssey4mesigmavirus24 you rang, master? :p19:09
sigmavirus24Are we splitting further up between ADFS work and Keystone federation work? If so, do we know who is going to work on which team?19:09
* sigmavirus24 needs to look at miguelgrinberg's stuff to see what he already has but I think etherpads will be helpful once again19:09
odyssey4mesigmavirus24 I think in general it's you and me on ADFS, with miguelgrinberg and hughsaunders on Keystone-Keystone... but to start with we need miguelgrinberg's starter work up so that we can use it as the base.19:10
sigmavirus24Good to know :D19:10
miguelgrinbergodyssey4me sigmavirus24: I'm not going through the reviews on the keystone SP stuff on my fork. I will have a review up hopefully soon.19:11
miguelgrinbergs/not/now/19:11
odyssey4mesigmavirus24 I just volunteered you to work with me, as you're late to the party (ie you didn't volunteer yourself). :p19:11
sigmavirus24odyssey4me: figures19:11
sigmavirus24I was looking at keystone federation stuff and saw a clear order of dependence that I thought I'd doc out19:11
sigmavirus24But I also don't know what miguelgrinberg has finished so I wasn't going to just write down everything he did ;)19:12
odyssey4mesigmavirus24 care to doc that into the spec?19:12
sigmavirus24oh cool, https://review.openstack.org/#/c/189998/ merged finally19:12
sigmavirus24odyssey4me: I'll take a gander19:12
sigmavirus24Or at least, it seems to me that to test this stuff we have a clear order of dependencies19:12
sigmavirus24that said, I'm still learning keystone federation things and stuff so I could be wrong ;)19:13
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment-specs: Multi-region Compute Deployment  https://review.openstack.org/19242119:13
odyssey4mesigmavirus24 yeah, perhaps we should stab at the spec early next week when we have most of it done and understand it all better?19:13
sigmavirus24odyssey4me: not a bad idea19:13
odyssey4meor perhaps do it on Wed in time for the meeting on Thu19:14
sigmavirus24It just seems like we need to be able to deploy a cloud as a Service Provider before we can deploy a cloud that talks to one19:14
sigmavirus24That way we can test how an OSAD cloud would talk to a Service Provider (that also happens to be OSAD)19:14
sigmavirus24that was probably obvious to everyone else, but I have 0 experience with this stuff so ¯\_(ツ)_/¯19:15
palendaesigmavirus24: I'm pretty sure there was a meeting about how's working on what just now19:15
odyssey4mesigmavirus24 yep, that's kinda what miguelgrinberg's work is almost ready to do - with that base we can also then configure an external IDP19:15
* sigmavirus24 needs to find miguelgrinberg's work now19:16
sigmavirus24palendae: how's working on what just now19:16
odyssey4mesigmavirus24 https://github.com/stackforge/os-ansible-deployment/compare/master...miguelgrinberg:federation19:16
palendaewho's19:16
stevemarsigmavirus24, feel free to bug me about federationy bits19:16
stevemarthough dolphm is pretty knowledgable about it too19:16
odyssey4methanks stevemar :) the more SME's the better19:17
stevemarodyssey4me, +119:17
odyssey4mestevemar do you happen to also have any expertise on fernet tokens?19:17
stevemarodyssey4me, nope, that's all dolphm and lbragstad19:18
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment-specs: Keystone Federation Deployment  https://review.openstack.org/19414719:18
odyssey4meah stevemar thanks - I asked the wrong question, actually - I should have asked whether you're aware of anyone running with fernet tokens in production?19:19
odyssey4meWe'd like to chat about a few things related to running with fernet tokens in production.19:19
dolphmodyssey4me: time warner is putting them into production in the next couple weeks cc- mfisch19:20
*** rrrobbb has quit IRC19:24
*** galstrom is now known as galstrom_zzz19:24
odyssey4medolphm it'd be great to have some views on what a good number for 'max_active_keys' is in production, and how key rotation should be managed in a multi-node environment. We're having a discussion about that in the next Thu meeting. cc mfisch19:26
*** Mudpuppy has quit IRC19:26
*** Mudpuppy has joined #openstack-ansible19:28
sigmavirus24miguelgrinberg: https://github.com/stackforge/os-ansible-deployment/compare/master...miguelgrinberg:federation#diff-921dfcc80a6a5dcf3a922884a5a04c75R70 should have a when keystone_idp is defined, yes?19:28
miguelgrinbergsigmavirus24: yes, I actually caught that in the version I'm preparing to upload to gerrit19:28
*** annashen has quit IRC19:29
miguelgrinbergsigmavirus24: actually that one is already out: https://review.openstack.org/#/c/194259/19:30
*** annashen has joined #openstack-ansible19:31
*** annashen has quit IRC19:32
*** annashen has joined #openstack-ansible19:32
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment-specs: Keystone Service Provider with ADFS Identity Provider Deployment  https://review.openstack.org/19425519:36
openstackgerritJesse Pretorius proposed stackforge/os-ansible-deployment-specs: Keystone Service Provider with ADFS Identity Provider Deployment  https://review.openstack.org/19425519:36
mfischodyssey4me: we're just doing 3 keys for now with the idea we can add more whenever. We are not using keystone's rotation tools19:37
odyssey4memfisch ah ok - so your plan is quite literally to just run with a small set of keys ad infinitum or until something happens to change your mind?19:38
mfischwe'll probably rotate every 2 weeks or so19:38
mfischor when a core team member leaves that will also trigger it19:38
mfischwe're storing them in eyaml and deploying with puppet19:38
odyssey4meI'm trying to gauge what sort of security impact there is of having a small number of active keys?19:39
mfischI have a jenkins job to rotate keys and propose a review of the change to keep humans in the loop19:39
mfischour token expire is 2 hours19:39
mfischso as long as we dont do 2 rotations in 2 hours we're ok19:39
odyssey4meso when the rotation is implemented, am I right in saying that one key falls off and another is generated to replace it... and this is done with the specified maximum number of keys always kept active19:41
mfischyes that sounds right19:41
mfischthe old primary becomes a backup key so you can decode old tokens19:41
mfischthe old old primary goes away19:41
mfischthe new key becomes on-deck19:41
mfischand the old on-deck becomes primary19:41
mfischmy blog has what I think is a good write up19:41
odyssey4memfisch ah, that's probably the blog entry that made me aware that these were good questions to ask :)19:42
mfischwe've been in dev for 3-4 weeks and going to prod on Wed19:43
*** alextricity_r has quit IRC19:44
odyssey4memfisch thank you for that - it has helped :) we'd love to hear your war stories once you've been running it production for a while19:44
mfischwill do19:44
mfischI'll also have some numbers19:44
mfischperf #s19:44
odyssey4meyeah, that'll be great - although dolphm's stats post it would seem that the performance will improve quite a bit19:45
mfischwell I'm seeing some of that but not all19:46
mfischdolph is re-running some numbers for me19:46
mfischI will have apples to apples numbers on Thursday19:46
odyssey4memfisch actually, it was lbragstad's post I've seen - do you have the URL to yours?19:49
odyssey4memfisch this one? http://www.mattfischer.com/blog/?p=64819:50
mfischtop post here19:50
mfischhttps://bfd-gerrit.os.cloud.twc.net/#/c/4763/19:50
mfischderp thats a code review19:50
mfischyeah thats it19:50
mfischnever trust your paste buffer19:50
odyssey4melol19:50
*** rrrobbb has joined #openstack-ansible19:51
mfischodyssey4me: FYI from what I've seen we have a 20-30 second keystone outage19:53
mfischthen because we have an old copy of keystone-middleware still I have a reboot the cloud ansible I run19:53
odyssey4memfisch ouch, that's no fun19:54
*** annashen has quit IRC19:54
odyssey4mebut really good to know19:54
mfischwe can live with it19:54
mfischit's a 2-3 min API outage19:54
mfischour customers dont mind that but get super angry when they lose net access19:54
mfischwe dont have Rax-like customers19:54
*** alextricity_r has joined #openstack-ansible19:55
odyssey4memfisch cool, thanks - it sounds like automated rotation is a bad idea... you want to rotate at a known date and time so that you can plan for the outage19:57
mfischoh sorry thats not it19:57
mfischits the token provider switch that is the outage19:58
mfischalso we19:58
odyssey4methis is something we should note in documentation, but not implement through cron I mean19:58
mfischwe're dogin a package upgrade19:58
mfischkey rotation is no outage19:58
mfischI owe a follow-up blog19:58
odyssey4memfisch ah ok, that's fair enough19:58
*** yaya has joined #openstack-ansible20:08
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: [WIP] Updated keystone to use fernet as the default  https://review.openstack.org/19372920:10
*** alextricity_r has quit IRC20:20
*** alextricity_r has joined #openstack-ansible20:21
*** alextricty has joined #openstack-ansible20:28
*** alextricity_r has quit IRC20:28
*** alextricty has quit IRC20:31
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: [WIP] Updated keystone to use fernet as the default  https://review.openstack.org/19372920:35
*** Mudpuppy has quit IRC20:42
*** Mudpuppy has joined #openstack-ansible20:46
*** javeriak has quit IRC20:49
*** georgem1 has quit IRC20:53
*** annashen has joined #openstack-ansible20:54
*** javeriak has joined #openstack-ansible20:54
*** sdake_ has quit IRC20:56
*** annashen has quit IRC21:00
*** rrrobbb has quit IRC21:11
openstackgerritKevin Carter proposed stackforge/os-ansible-deployment: Updated master to the latest SHAs - 06.20.2015  https://review.openstack.org/19384421:14
*** annashen has joined #openstack-ansible21:15
*** javeriak has quit IRC21:16
*** javeriak has joined #openstack-ansible21:20
*** tlian has quit IRC21:21
openstackgerritMiguel Grinberg proposed stackforge/os-ansible-deployment: [WIP] Keystone SP configuration  https://review.openstack.org/19439521:33
*** yaya has quit IRC21:33
*** KLevenstein has quit IRC21:36
*** fawadkhaliq has joined #openstack-ansible21:59
*** Mudpuppy has quit IRC22:02
*** georgem1 has joined #openstack-ansible22:03
*** georgem1 has quit IRC22:03
*** git-harry has quit IRC22:04
*** mancdaz has quit IRC22:04
*** andymccr has quit IRC22:05
*** git-harry has joined #openstack-ansible22:06
*** sigmavirus24 is now known as sigmavirus24_awa22:06
*** mancdaz has joined #openstack-ansible22:06
*** andymccr has joined #openstack-ansible22:07
*** fawadkhaliq has quit IRC22:12
*** fawadkhaliq has joined #openstack-ansible22:24
*** stevemar has quit IRC22:37
*** JRobinson__ has joined #openstack-ansible22:43
*** radek__ has quit IRC22:44
*** alextricity_r has joined #openstack-ansible22:45
*** alextricity_r has quit IRC22:46
*** daneyon has quit IRC22:52
*** daneyon has joined #openstack-ansible22:53
*** dkalleg has quit IRC22:55
*** dkalleg has joined #openstack-ansible22:56
*** dkalleg has quit IRC23:01
*** markvoelker has quit IRC23:16
*** JRobinson__ has quit IRC23:29
*** dkalleg has joined #openstack-ansible23:29
*** fawadkhaliq has quit IRC23:31
*** annashen has quit IRC23:31
*** annashen has joined #openstack-ansible23:34
*** darrenc is now known as darrenc_afk23:44
*** jaypipes has quit IRC23:46
*** annashen has quit IRC23:46
*** sigmavirus24_awa is now known as sigmavirus2423:48
*** sigmavirus24 is now known as sigmavirus24_awa23:51

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!