Monday, 2015-02-02

*** kebray has quit IRC01:29
*** kebray has joined #openstack-barbican01:47
*** dimtruck is now known as zz_dimtruck02:17
*** zz_dimtruck is now known as dimtruck04:08
*** crc32 has joined #openstack-barbican04:12
*** ajc_ has joined #openstack-barbican04:28
*** dimtruck is now known as zz_dimtruck05:21
*** jaosorior has joined #openstack-barbican06:39
*** crc32 has quit IRC06:56
*** Nirupama has joined #openstack-barbican07:41
*** chlong has quit IRC08:00
*** woodster_ has quit IRC08:06
*** kebray has quit IRC08:35
*** darrenmoffat1 has quit IRC08:39
*** darrenmoffat has joined #openstack-barbican08:40
*** jaosorior has quit IRC08:46
*** nkinder has joined #openstack-barbican08:48
*** ajc__ has joined #openstack-barbican12:14
*** ajc__ has quit IRC12:15
*** miqui_away has quit IRC12:21
*** woodster_ has joined #openstack-barbican12:25
*** Nirupama has quit IRC12:28
*** ajc_ has quit IRC13:16
*** jaosorior has joined #openstack-barbican13:29
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Refactor exception handling in the app side
jaosoriorI'm getting some pep8 issues on the commit above, can someone help me out figuring out what's up with those?14:04
*** lisaclark1 has joined #openstack-barbican14:15
*** tkelsey has joined #openstack-barbican14:28
openstackgerritTim Kelsey proposed openstack/barbican-specs: Adding spec for Barbican MKEK Model.
*** lisaclark1 has quit IRC14:41
*** lisaclark1 has joined #openstack-barbican14:45
*** rm_work is now known as rm_work|away14:47
*** lisaclark1 has quit IRC14:51
*** openstackgerrit has quit IRC14:52
*** openstackgerrit has joined #openstack-barbican14:52
*** lisaclark1 has joined #openstack-barbican14:53
*** rm_work|away is now known as rm_work15:04
*** paul_glass has joined #openstack-barbican15:07
*** paul_glass has quit IRC15:10
*** zz_dimtruck is now known as dimtruck15:16
*** darrenmoffat has left #openstack-barbican15:17
*** lisaclark1 has quit IRC15:28
*** lisaclark1 has joined #openstack-barbican15:34
*** nkinder has quit IRC15:43
*** crc32 has joined #openstack-barbican15:48
*** crc32 has quit IRC15:52
*** kgriffs|afk is now known as kgriffs15:58
*** SheenaG1 has joined #openstack-barbican16:01
*** lisaclark1 has quit IRC16:14
*** lisaclark1 has joined #openstack-barbican16:17
*** david-lyle_afk is now known as david-lyle16:19
*** kebray has joined #openstack-barbican16:19
*** crc32 has joined #openstack-barbican16:24
aleewoodster_, rm_work , morganfainberg -responded to comments in
*** crc32 has quit IRC16:25
woodster_alee will take a look after our standup16:30
aleewoodster_, thanks16:30
rm_workalee: lookin' good :P16:33
aleethanks :)16:33
*** kgriffs is now known as kgriffs|afk16:43
*** paul_glass has joined #openstack-barbican16:43
jaosoriorwoodster_, alee, rm_work, jvrbanac are you guys acquainted with the i18n stuff? I'm getting some strange pep8 issues because of it that I haven't figured out in this CR
jvrbanacjaosorior, I think you linked the wrong CR?16:48
jaosoriorLol yes16:49
jaosoriorThat one16:50
*** gyee has joined #openstack-barbican16:50
rm_workjaosorior: they have weird rules for i18n16:50
rm_workit violates everything that you're used to doing16:50
rm_workyou have to import _LE / _LW / etc directly16:50
woodster_rm_work you don't because we import16:51
rm_workand use those (not just _())16:51
woodster_'u' instead of _16:51
rm_workright but16:51
rm_workyou're not supposed to16:51
rm_workeven though it violates typical pep8 stuff16:51
rm_workthe openstack i18n stuff is different16:51
woodster_well it passes their gate!  the one we are using anyway :)16:52
rm_workfor example:
rm_workthey mandate the imports in that format16:52
woodster_jaosorior could the issue be with the format(*args, **kwargs)?....I think the {slot} mode for format requires a key/value mapping maybe?16:53
jaosoriorI have no clue :/16:53
rm_workOH the just a string error16:53
woodster_rm_work I'd think this would be a valid import: from barbican import i18n as u16:53
rm_workthis is an easy fix16:54
rm_workwoodster_: normally yes but they require weird shit <_<16:54
jaosoriorI was stomping my head for a fair bit16:54
rm_workyeah jaosorior16:54
woodster_jaosorior, can you remove the *args part there? ARe you seeing this locally or just in the gate?16:54
rm_workjaosorior: so on line 8016:54
rm_workjaosorior: you have u.("sometext".format(thing))16:55
woodster_rm_work I remember seeing an example that does the _LE stuff, but I didn't take that as prescriptive if we have a better way of doing it 8^)16:55
rm_workput an extra parens around the stuff16:55
rm_workit'll work16:55
rm_worki have not yet figured out WHY, but it's a peculiarity of how it handles the parsing of .format()16:56
woodster_really? That doesn't make sense unless some sort of pre-parsing thing?16:56
rm_workat the point at which the i18n macros deal with stuff16:56
rm_workit hasn't figured it out yet16:56
*** crc32 has joined #openstack-barbican16:56
rm_workif you understand WHY, feel free to explain it to me, but it works16:56
rm_workanywhere you do a .format() inside a u._()16:57
rm_workjust need extra parens :)16:57
woodster_oh I see...checkout this:
rm_workyou can do that too16:57
woodster_jaosorior, you need to keep the slot in the I18n text for translation, but the .format is performed outside of that16:58
rm_workhmm, we may need to fix some stuff in our code in that case... lol16:58
woodster_rm_work the double parens is not'll never get a localization match that way16:58
rm_workyeah I may have to dig through and find where we did that16:58
rm_workit was ... a few places16:59
*** lisaclark1 has quit IRC16:59
woodster_jaosorior ^^^^ Please see
jaosoriorLet's see17:00
jaosoriorOoooh I see!17:02
jaosoriorI'll try it when I get home17:02
*** lisaclark1 has joined #openstack-barbican17:02
jaosoriorThanks people :D17:03
rm_workdo you guys remember if %s type string substitution was deprecated in favor of .format()?17:04
woodster_I recall .format is more pythonic than %17:06
rm_worki guess
rm_worksays "The new system does not collide with any of17:08
rm_work    the method names of the existing string formatting techniques, so17:08
rm_work    both systems can co-exist until it comes time to deprecate the17:08
rm_work    older system."17:08
rm_workso I guess that *implies* that at some point the old system would be deprecated?17:08
openstackgerritThomas Dinkjian proposed openstack/python-barbicanclient: Adds base behaviors, secret behaviors and the secret smoke tests
*** lisaclark2 has joined #openstack-barbican17:23
*** lisaclark1 has quit IRC17:26
jvrbanacrm_work, they don't collide, and % isn't fully deprecated yet; however, .format() is the preferred method for normal strings as it has better error handling mechanisms and more functionality17:31
jvrbanacrm_work, in Barbican. I believe our policy is .format() for everything other than log messages17:31
*** xaeth has joined #openstack-barbican17:32
jvrbanacrm_work, or unless you have a really good reason ;)17:32
jvrbanachowever, those are quite rare17:34
*** SheenaG1 has quit IRC17:36
*** jkf has joined #openstack-barbican17:39
openstackgerritOpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements
*** atiwari1 has quit IRC17:46
*** kebray has quit IRC17:49
*** kebray has joined #openstack-barbican17:59
*** lisaclark2 has quit IRC18:00
*** SheenaG1 has joined #openstack-barbican18:08
*** atiwari has joined #openstack-barbican18:08
*** dimtruck is now known as zz_dimtruck18:12
rm_workredrobot: you there?18:14
rm_workredrobot: redrobot~~18:18
rm_workoh, probably at lunch <_<18:18
*** zz_dimtruck is now known as dimtruck18:21
*** bdpayne has joined #openstack-barbican18:28
openstackgerritThomas Dinkjian proposed openstack/python-barbicanclient: Adds base behaviors, secret behaviors and the secret smoke tests
openstackgerritMerged openstack/barbican: Updated from global requirements
*** lisaclark1 has joined #openstack-barbican18:55
openstackgerritThomas Dinkjian proposed openstack/python-barbicanclient: Adds base behaviors, secret behaviors and the secret smoke tests
*** lisaclark1 has quit IRC19:02
*** kgriffs|afk is now known as kgriffs19:19
*** kgriffs is now known as kgriffs|afk19:29
jaosoriorjvrbanac: You're on fire reviewing today :D19:48
jvrbanacjaosorior, ?19:49
jaosoriorjust read a couple of particularly good reviews19:50
jvrbanacjaosorior, ahh lol19:50
rm_workredrobot: around?19:51
*** kfarr has joined #openstack-barbican19:53
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Refactor exception handling in the app side
jaosoriorrm_work, jvrbanac, woodster_: It worked :D19:54
*** lisaclark1 has joined #openstack-barbican19:57
rm_workyeah, I'm glad we had that talk because I didn't realize there was a technical difference between double-parens and moving the .format() outside19:58
rm_workso, now I know it matters :P19:58
woodster_alee, rm_work, I added comments to the rbac bp...basically agreeing with you guys\19:59
redrobotthe barbican weekly meeting is starting now on #openstack-meeting-alt20:00
rm_workredrobot: I need to talk to you after :P20:01
* redrobot hides20:01
redrobotalee you around for the meeting?20:02
openstackgerritJuan Antonio Osorio Robles proposed openstack/barbican: Drop old namespace for some oslo libraries
openstackgerritMerged openstack/barbican: Fix error in "tenants to projects" migration script
openstackgerritMerged openstack/barbican: Fix downgrade for revision 254495565185
aleeSheenaG1, ping20:46
SheenaG1what's up alee?20:46
aleeSheenaG1, were you going to send me an abstract?20:46
aleeSheenaG1, or did you send it already and I missed it ..20:46
SheenaG1alee: we're working on it - I have Chelsea taking a look right now, we'll try to have it over to you in the next day or so20:47
*** lisaclark1 has quit IRC20:47
aleeSheenaG1, OK great thanks20:47
SheenaG1alee: no problem, we haven't forgotten - it's just not in a state that's worth reviewing yet, IMO20:47
aleeSheenaG1, ok --- deadline's in a week though20:48
SheenaG1alee: understood.  We'll definitely want your input before we submit20:49
*** paul_glass has quit IRC20:54
*** paul_glass has joined #openstack-barbican20:57
*** lisaclark1 has joined #openstack-barbican21:00
morganfainbergjaosorior, so the reason we started collapsing is the migrations are hard to maintain as things like oslo.db update21:00
*** lisaclark1 has quit IRC21:01
jaosoriorcan you elaborate?21:01
morganfainbergjaosorior, sure, the original migrations (go look at essex and such) are very simplistic21:01
morganfainbergand needed a lot of work to carry forward when exceptions changed etc21:01
morganfainbergso, we collapsed and make the first migration just create the schema expected at n-221:02
morganfainbergthat way you have work to maintain the collapsed start21:02
morganfainbergbut it's a small scope of migrations21:02
morganfainberg*and* it eliminates all the migration test maintenance21:02
jaosoriorthat sounds good!21:02
morganfainbergif we move to alembic we would either need to forever maintain SQL-A migrate or convert everything to alembic21:02
morganfainbergboth are unfun21:02
morganfainbergso this way we can say when we move to alembic, we only have 2 releases where SQL_A migrate is used [if we don21:03
morganfainberg't convert everything]21:03
woodster_morganfainberg, we did our alembic stuff before oslo db I believe. Do you think we should move away from alembic?21:03
morganfainbergstay with it21:03
morganfainbergwe're planning on moving to it21:03
morganfainbergbut we have to wait for some fixes to land in oslo.db21:04
*** lisaclark1 has joined #openstack-barbican21:04
morganfainbergspecific to how we do migrations21:04
woodster_morganfainberg, oh I see. So moving *from* oslo.db eventually then? I wasn't expecting that :)21:04
morganfainbergwell no21:04
morganfainbergalembic is migrations21:04
morganfainbergoslo.db is the layer over SQL-Alchemy21:05
*** kfarr has quit IRC21:05
morganfainberg(not to be confused with sql-alchemy-migrate which alembic replaces)21:05
*** tkelsey has quit IRC21:05
morganfainbergoslo.db works fine for us w/ sql-a-migrate, but alembic not yet.21:05
morganfainbergoslo.db we're happy with [for the most part]21:05
jaosoriormorgainfainberg: We are using straight SQL-Alchemy, how good has oslo.db for you? Should we start migrating to oslo.db soonish?21:05
morganfainbergoslo.db is just a way to do config over sql-a, nice way to be consistent21:06
morganfainbergsome openstack-specific unification21:06
morganfainbergi can't tell you if barbican would benefit from it. but it would make you gjuys more consistent with the rest of OpenStack21:07
morganfainbergmight also reduce some code you need to carry21:07
jaosoriorI'll take a look into it (later this week)21:07
jaosoriorprobably will see how it's used in keystone anyway21:07
*** kgriffs|afk is now known as kgriffs21:07
jaosoriormorgainfainberg: Thanks for the info Mr. :D21:08
jaosoriorredrobot, woodster_: So... I'm guessing the conclusion is that I should fix this ?21:08
redrobotjaosorior what is rev 4070806f6972?21:09
jaosoriorthe script's hash21:09
redrobotjaosorior right, but what point in time is it?  Juno-final?21:10 idea21:10
redrobotjaosorior so, I think that being able to upgrade from Juno->Kilo is a must-have for us.  I consider downgrades a "nice-to-have"21:11
jaosorior4070806f6972  dsa in container type modelbase_to21:11
jaosoriorupgrade works21:11
jaosoriorfor all the other ones above it21:11
jaosoriorI have no idea if the upgrade for that specific script works21:12
jaosoriorbecause I can't downgrade to it...21:12
openstackgerritSteve Heyman proposed openstack/barbican: Add the ability to use either identity v2 or v3 API
jaosoriorit's actually this script 2ab3f5371bde_dsa_in_container_type_modelbase_to.py21:13
jaosoriorgot confused with the hash, sorry21:13
jaosorioratiwari: are you around?21:13
atiwarijaosorior, yes21:14
jaosoriorcan you help me out?21:14 I can't figure out that script... Sorry :/21:14
jaosoriorthe downgrade doesn't seem to work for me (I use Postgres,)21:14
jaosoriorand I'm trying to make it database independant21:14
jaosorior(or independent... however the actual word in english is..)21:15
jaosoriorfirst, what did you mean by dsa in container type modelbase_to ?21:15
jaosorior"dsa in container type modelbase_to"21:15
atiwariwait, let me see21:15
atiwariI am off for sometime21:15
jaosoriorwell, it's quite late here (Finnish time)21:17
jaosoriorso i'm gonna go soon21:17
jaosoriorbut when you have time21:17
jaosoriorcan you help me out figuring out what it was meant for initially in this bug ?21:17
*** kgriffs is now known as kgriffs|afk21:17
atiwariwe have added rya and dsa type in the container table21:17
atiwaribefore it was just generic and certificate21:18
jaosoriorand also21:19
jaosoriorin the upgrade and downgrade functions21:19
jaosoriorthe alter table operations are actually the same21:19
jaosorioris that the way it was intended?21:20
jaosorioroh no21:20
jaosoriorwait up21:20
jaosoriorsorry, I mis-read that part21:20
jaosoriorthey do change21:20
jaosoriornow I get it21:20
atiwarino it is not same21:20
jaosoriorwill fix it tomorrow21:20
jaosoriorthanks atiwari21:20
rm_workredrobot: so, you around/21:25
xaethalee, if i wanted to have a conversation around the rpm spec file you provided, who would i have that w/21:26
aleexaeth, me most likely :)21:27
xaethso i'm going through and doing some general cross release bits, like el6 vs fedora (since it has upstart bits, and we'd be using el6 internally)21:27
xaethand as i was doing this i noticed lots of overlap on file ownership21:28
xaethi've tried to clean some of that up, but i'm wondering if it wouldn't be better to go back to their original common package with a sub for api and worker ? the model in yours is that the common is the api21:28
aleexaeth, just a sec -- let me pull up the rpm21:30
*** chipmanc has joined #openstack-barbican21:30
xaethalee, this might be easier:
aleexaeth, possibly -- I think this was done this way to b more in line with what had been done for openstack-cinder and openstack-glance21:35
xaethmakes sense, which is why i wasn't going to move away from that at first.  Do either of those have the concept of worker nodes?21:35
aleexaeth, not to say that it couldn't be done as you suggest -- we should just choose to do what makes sense.21:36
*** kebray has quit IRC21:36
xaethor a parrallel21:36
aleexaeth, let me look at the other two ..21:36
xaethi didn't see one in glance21:36
xaethhadn't looked at cinder21:36
aleexaeth, in openstack-cinder, there is no worker mode21:38
aleebut what is common in the fedora packaging is the idea that the common library code is in python-*21:38
xaethproblem is that its configs not code21:39
aleeso for example, in openstack-cinder, you have openstack-cinder which is the server, and python-cinder which is the underlying code21:39
xaethright, and in this python-barbican is the underlying code21:40
xaethi added another file to that gist. this one includes a -qlp dump on the main and worker rpms21:40
aleexaeth, I'm checking the client to see what it depends on21:40
aleexaeth, I was checking the python-cinderclient to see if I depended on python-cinder ..21:43
aleewith the idea being that the "common code" would be the code that was common to client and server21:43
aleebut it doesn't21:43
aleelet me look at another -- glance say21:43
xaethwoodster_, redrobot : does work log to barbican-api.log ?21:44
woodster_xaeth, worker logs to barbican-worker.log21:45
xaethhrmm... kk :) your missing a logrotate entry then21:45
*** lisaclark1 has quit IRC21:45
woodster_xaeth, ha nice!21:46
*** kebray has joined #openstack-barbican21:47
*** lisaclark1 has joined #openstack-barbican21:47
xaethwoodster_, i would also imagine that the api nodes shouldn't own the db manage script?21:47
aleexaeth, ok - so it looks like python-X  is the python code, openstack-X is the init scripts/config files/scripts21:48
aleexaeth, are we not following that model .. looking?21:48
xaeththe model we are following is that both packages have both21:48
xaethbad statement21:49
xaethpython-X is the python code21:49
xaethopenstack-X and openstack-X-worker have a lot of the same stuph21:49
rm_workredrobot >_>21:49
redrobotrm_work what up?21:49
aleexaeth, right -- but I would think they would not be deployed on the same machine , right?21:50
rm_workredrobot: PM21:50
redrobotxaeth barbican-worker is just a python script.  It logs to wherever you send the std-out and std-err.21:51
redrobotxaeth looks like we have it set up to log to barbican_worker.log
aleeredrobot, xaeth , woodster_ I think we need some clarification as to how these workers are deployed21:52
xaethi guess i would too21:53
aleethat is do you expect to see a barbican worker on the same server as a barbican server?21:53
xaethi'm under the impression that while they can be deployed together in a small environment, they are designed to be deployed separately for scale21:53
aleexaeth, and you could well be right :)21:53
aleexaeth, in which case I'd be curious as to which files it would need to share with barbican-server21:54
aleecan you have multiple workers on the same machine?21:54
redrobotalee xaeth the intention is for the worker to run in it's own machine21:54
aleeredrobot, and barbican-server is not on the same machine as a barbican-worker?21:55
*** chipmanc has quit IRC21:56
redrobotalee correct, see the first diagram here
woodster_xeath so the worker process and keystone listener are optional on a worker node, the database manage script is optional on any of the nodes really. Rackspace probably run that on a dedicated node/process, with a different set of db user credentials for example.21:56
redrobotalee each box is its own machine21:56
aleeredrobot, look at  lines 173-187 -- are these the files that correspond to a worker?21:57
aleewoodster_, ^^21:57
woodster_the nuance is things lke the worker and keystone listener and (eventually) a retry/scheduler service. They could all be deployed on one worker node, or else optionally installed if desired. I'm not sure if keeping them separate is worth the rpm hassle though21:58
woodster_alee, no not all of those files are relevant21:58
xaethquestion... why separate out worker ?21:59
xaethsounds like it shares enough with the main that its all just configuration at that point21:59
woodster_alee in fact most are irrelevant. Only the /etc/barbican/barbican-api.conf and associated rotate file are relevant21:59
xaeththe actual binary being the main difference21:59
aleeredrobot, woodster_ the key thing is to separate out what consitutes a server and what constitutes a worker21:59
woodster_not sure what /etc/init/barbican-api.conf is...22:00
xaeththats the upstart config22:00
woodster_...where server is defined as an api node?22:00
woodster_xaeth, oh yes, thanks22:00
aleeonce we know what is in each of those are we can determine how to separate them out22:00
redrobotxaeth the reason we separate them is that we want to separate the concerns22:01
woodster_the  /etc/barbican/barbican-api.conf files is the only one shared between the api and worker node types22:01
aleewoodster_, redrobot - in this spec file, the line 155-166 are in an api node, 173-187 are in the worker node22:01
woodster_the remainder are for the api only22:01
xaethredrobot, ya i understand the general concept.22:02
woodster_alee, can you link to that file?22:02
woodster_alee, sorry my client just render the top part...going direclty to link to see the rest of the stuff there....22:03
aleexaeth, if there is enough of an overlap, you could consider a openstack-barbican-common subpackage  I suppose -- but I suspect it won't come to that.22:05
redrobotxaeth sorry, I'm not sure I understood your question then...  I suppose the reason we originally separated the worker is so that you could "yum install barbican-worker" on the worker nodes... no real technical reason beyond that.22:06
woodster_alee, xaeth, redrobot, I think line 160 (the db manage script) is the only one I could see separating into another package, but IMHO not worth it.  #181 and #182 (assuming they are recurve grabbing vassal stuff too) are probably too broad, when only the barbican-api.conf file is needed.22:07
xaethSo as long as we drop it down so that only the api.conf is shared, then i think its pretty reasonable22:07
woodster_alee, xaeth, redrobot,  that all said...I've been bugged that the worker's conf file is called 'barbican-api.conf' :)22:07
xaethand yes, i'd love to see it split so that it doesn't share that22:08
woodster_...or just call it barbican.conf, though I'd hate to accidently swap an api one for a worker one22:09
xaethredrobot: my question was geared around the fact that they seemed to both include the same files, aside from the final binary. so if there isn't much of a split, why bother splitting? but if thats not the actual case and they should be fully split maybe we should get there?22:09
xaethwoodster_, i'd definitely lean towards separate because of that22:09
woodster_xeath, redrobot, alee yeah the api and worker share much code in common so no point in splitting that. The division is really more of configuration files, and in the case of worker nodes some specific processes that can be run on them (but also using that same shared code base).22:14
redrobotxaeth, I should also point out that uwsgi is not a requirement22:16
xaeththanks redrobot, i'll blame alee for that :)22:16
redrobotxaeth Rackspace deployment uses uwsgi, but barbican can be deployed using any server you like22:16
redrobotxaeth recently I've been running my dev environment server under Gunicorn22:17
xaethactually i think its in the main spec file too so *shrug*22:17
xaethbut ya understood22:17
redrobotxaeth I wrote the original spec file, so it's probably my fault >_<22:17
aleeredrobot, xaeth - well you need something ..22:17
redrobotalee xaeth  it would be worthwhile looking into what openstack-keystone uses to run their server22:18
xaethalee: yes, but it doesn't look like glance or keystone have one listed22:19
redrobotalee it's possible to run it using the built-in wsgi host...22:19
xaethredrobot, most of those commonalities are far as code goes are in python-barbican22:19
aleexaeth, redrobot ok22:19
redrobotwhich I think is what keystone is doing?22:19
redrobotxaeth so by extension, the vassals files are not necessary22:20
xaethhrm... so that is uwsgi specific?22:21
redrobotyes, uwsgi loads the vassal files, which point to the paste files, where the actual config is22:21
xaethwe could include them in the %docs or %datadir as a reference ... i saw that in one of hte other projects for something22:21
xaethwe dont have too. just could22:21
redrobotI'd rather not put any server specific stuff in, to avoid having to answer questions about it later :)22:22
redrobotxaeth I would think that we need to write a script, which loads the barbican wsgi app and runs it in the built in wsgi host22:26
xaethmakes sense22:27
*** kebray has quit IRC22:31
*** kebray has joined #openstack-barbican22:37
xaethgot the shared list dropped down to just hte config and pushed the keystone listener to a separate package22:54
xaeth(which is what is in the spec file in barbican proper)22:54
xaethupdate spec and output in the gist22:56
*** kgriffs|afk is now known as kgriffs22:56
*** xaeth is now known as xaeth_afk23:05
*** kgriffs is now known as kgriffs|afk23:06
rm_workhey tdink_ / hockeynut / jvrbanac: the Barbican functionaltests23:07
rm_workare they "tempest" tests?23:08
rm_worklike, I see they pull in stuff from tempest, but23:08
rm_workthey are SO different from the normal tempest tests I see, that I am not sure if they actually count :P23:08
jvrbanacrm_work, they are not23:09
rm_workso they don't count for the purposes of openstack's testing requirements?23:09
rm_workdoes Barbican have any real tempest tests anywhere?23:09
jvrbanacrm_work, they are just barbican functional tests23:09
openstackgerritVenkat Sundaram proposed openstack/barbican-specs: Add Quota support for Barbican resources
jvrbanacrm_work, not that I know of. Tempest tests would go in the tempest repo. But if I recall correctly, that is aimed for integration between projects23:10
*** chlong has joined #openstack-barbican23:12
rm_workjvrbanac: err, I thought tempest tests were in the project-tree now23:12
jvrbanacrm_work, I don't know. I haven't kept up with that stuff. hockeynut should be able to trace that down though23:14
hockeynutrm_work the tests in tempest repo are indeed more integration-type23:14
rm_workhockeynut: so there ARE barbican tests in the tempest repo?23:14
hockeynutrm_work the tests in our repo are our funtional tests23:14
rm_workI thought tempest tests were supposed to be in the project repo now23:14
*** paul_glass has quit IRC23:15
hockeynutrm_work none of our tests are in tempest repo23:15
*** crc32 has quit IRC23:15
rm_workok so23:15
rm_workdoesn't openstack require "tempest tests"?23:16
hockeynutrm_work you are correct - tempest tests go in our repo.  the id is that our curent functional tests are (or will become) the "tempest tests"23:16
rm_workhockeynut: err, so23:16
*** SheenaG1 has quit IRC23:16
rm_workhockeynut: we're trying to figure out if we can do our required "tempest tests" in the way you guys did23:16
rm_workor whether we have to stick closer to the style of the ones in the main tempest repo (which kinda suck)23:17
rm_workwho actually decides if the tests we write fulfill for the openstack testing requirements?23:17
hockeynutrm_work I believe that is the TC so Sean Dague I think is the tempest guy23:18
hockeynutrm_work I'23:18
redrobotrm_work soooooooooo  all that stuff is in flux23:18
hockeynutcast in jello23:18
rm_workwho can we ask for some direction? >_>23:18
redrobotrm_work does your project have a QA liasion?23:19
rm_workI don't know?23:19
rm_workI don't think so? maybe?23:19
hockeynutrm_work redrobot I've spoken a bit with Matt Trenish about this.  He had some takes (mostly "more tests, please") but nothing clear23:20
rm_workI guess Salvatore23:20
rm_workwe're neutron but kinda not23:20
rm_workwe aren't on that project list yet :P23:21
redrobotso, with the "big tent" changes coming down the pipeline, it's not clear what anything means anymore23:21
rm_workthanks redrobot, makes me very comfortable :P23:21
hockeynutrm_work please hook me up with your QA/QE person and we can discuss23:21
rm_workhockeynut: alright I guess that'd be fnaval (Franklin)23:21
redroboteventually they'll define some sort of testing-related "tags" and at that point the requirements for the tags will clear up what it is that needs to be done23:21
rm_workI'll get you guys talking tomorrow23:21
redrobotrm_work that's my hope anyway... all that stuff is super confusing now. >_<23:22
hockeynutrm_work sounds good!23:22
rm_workkk thanks23:22
*** lisaclark1 has quit IRC23:23
*** lisaclark1 has joined #openstack-barbican23:36
*** dimtruck is now known as zz_dimtruck23:39
*** lisaclark1 has quit IRC23:46
*** jaosorior has quit IRC23:46
*** lisaclark1 has joined #openstack-barbican23:49
*** kgriffs|afk is now known as kgriffs23:57

Generated by 2.14.0 by Marius Gedminas - find it at!