Thursday, 2015-02-26

*** gordc has quit IRC00:10
*** david-lyle is now known as david-lyle_afk00:14
*** mdbooth has quit IRC00:29
openstackgerritMerged openstack/cliff: Hide prompt in batch/pipe mode  https://review.openstack.org/15799900:32
*** mdbooth has joined #openstack-oslo00:35
*** jaypipes has quit IRC00:40
*** ViswaV has quit IRC00:51
*** salv-orlando has quit IRC01:00
*** mtanino has quit IRC01:01
*** dims_ has joined #openstack-oslo01:11
*** dims_ has quit IRC01:11
*** dims_ has joined #openstack-oslo01:11
*** dims has quit IRC01:12
*** ViswaV has joined #openstack-oslo01:23
*** dims has joined #openstack-oslo01:37
*** dims_ has quit IRC01:40
*** sigmavirus24 is now known as sigmavirus24_awa01:44
*** ViswaV has quit IRC01:48
*** noelbk has quit IRC02:15
*** stevemar has joined #openstack-oslo02:49
*** takedakn has joined #openstack-oslo02:52
*** yamahata has quit IRC02:52
*** takedakn has quit IRC03:02
*** takedakn has joined #openstack-oslo03:03
*** dims has quit IRC03:24
*** takedakn has quit IRC03:49
*** wendar has quit IRC04:04
*** wendar has joined #openstack-oslo04:04
*** dims has joined #openstack-oslo04:25
*** dims has quit IRC04:30
*** jecarey has joined #openstack-oslo04:30
*** yamahata has joined #openstack-oslo05:00
*** jamespage has quit IRC05:05
*** jamespage has joined #openstack-oslo05:06
*** jecarey has quit IRC05:29
*** achanda has quit IRC05:50
*** noelbk has joined #openstack-oslo05:56
*** ajo has joined #openstack-oslo06:00
*** inc0 has joined #openstack-oslo06:06
*** ViswaV has joined #openstack-oslo06:11
*** ViswaV_ has joined #openstack-oslo06:15
*** ViswaV has quit IRC06:16
*** achanda has joined #openstack-oslo06:19
*** takedakn has joined #openstack-oslo06:27
*** takedakn has quit IRC07:04
*** ajo has quit IRC07:08
*** subscope has quit IRC07:14
openstackgerritSabari proposed openstack/oslo.vmware: Add get_datastore_by_ref method to oslo.vmware  https://review.openstack.org/15935707:42
*** dims has joined #openstack-oslo08:03
*** e0ne has joined #openstack-oslo08:03
*** dims has quit IRC08:07
*** achanda has quit IRC08:09
*** ihrachyshka has joined #openstack-oslo08:12
*** ViswaV_ has quit IRC08:15
*** dulek has joined #openstack-oslo08:22
*** dtantsur|afk is now known as dtantsur08:26
*** ihrachyshka has quit IRC08:36
*** salv-orlando has joined #openstack-oslo08:39
*** andreykurilin_ has joined #openstack-oslo08:49
*** rushiagr_away is now known as rushiagr08:49
*** yamahata has quit IRC08:53
*** i159 has joined #openstack-oslo08:54
*** stevemar has quit IRC08:57
*** dulek has quit IRC08:57
*** dulek has joined #openstack-oslo08:58
*** dulek_ has joined #openstack-oslo09:04
*** dulek has quit IRC09:04
*** SpamapS has quit IRC09:04
*** SpamapS has joined #openstack-oslo09:05
*** takedakn has joined #openstack-oslo09:05
*** MasterPiece has quit IRC09:10
*** SpamapS has quit IRC09:10
*** noelbk has quit IRC09:13
*** jgrimm is now known as zz_jgrimm09:15
*** dulek_ has quit IRC09:31
*** SpamapS has joined #openstack-oslo09:32
*** SpamapS has joined #openstack-oslo09:32
*** andreykurilin_ has quit IRC09:32
*** jaosorior has joined #openstack-oslo09:38
*** salv-orlando has quit IRC09:49
*** achanda has joined #openstack-oslo10:01
*** ajo has joined #openstack-oslo10:09
*** achanda has quit IRC10:17
*** takedakn has quit IRC10:20
*** ihrachyshka has joined #openstack-oslo10:41
*** achanda has joined #openstack-oslo10:50
*** dims has joined #openstack-oslo10:52
*** himangi has joined #openstack-oslo10:54
*** dims_ has joined #openstack-oslo10:55
*** dims has quit IRC10:58
*** amotoki has joined #openstack-oslo11:12
*** dtantsur is now known as dtantsur|bbl11:14
*** salv-orlando has joined #openstack-oslo11:15
*** achanda has quit IRC11:17
*** pcaruana has joined #openstack-oslo11:19
*** rushiagr is now known as rushiagr_away11:33
sdaguewhat's the path for oslo policy to not complain if this directory doesn't exist? - https://review.openstack.org/#/c/15208211:41
*** salv-orlando has quit IRC11:44
*** cdent has joined #openstack-oslo11:54
openstackgerritSergey Gotliv proposed openstack/oslo-incubator: Improve logging to debug invalid "extra_specs" entries  https://review.openstack.org/15943212:08
*** kgiusti has left #openstack-oslo12:11
*** dims_ has quit IRC12:14
*** dims has joined #openstack-oslo12:14
*** rodrigods is now known as rodrigods_12:16
*** rodrigods_ is now known as rodrigods__12:16
*** rodrigods__ is now known as rodrigod`12:16
*** rodrigod` is now known as rodrigods12:17
*** _amrith_ is now known as amrith12:17
*** himangi has quit IRC12:20
*** dtantsur|bbl is now known as dtantsur12:31
*** mtanino has joined #openstack-oslo12:33
*** takedakn has joined #openstack-oslo12:42
inc0dhellmann, dansmith, dims -> https://review.openstack.org/#/c/159380/ it turns out that I need global requirements after all...12:44
*** dulek has joined #openstack-oslo12:44
*** dulek_ has joined #openstack-oslo12:46
*** rodrigods is now known as rodrigod`12:51
dimsinc0: of course you do :)12:53
inc0I was kinda hoping that local heat requirements.txt would be enough12:53
*** rodrigod` is now known as rodrigods12:53
dimsinc0: there's a way to do, but won't recommend it12:53
*** salv-orlando has joined #openstack-oslo12:54
inc0please share12:54
kragnizdims: you tease12:54
inc0I just want reviews to start12:55
inc0k-3 is getting closer:(12:55
dimsinc0: can you please update projects.txt too? http://git.openstack.org/cgit/openstack/requirements/tree/projects.txt12:55
dimskragniz: not teasing, it a path for projects in stackforge that want to depend as much as possible on listed requirements but need a couple more that are not in global (say nova-docker needs docker-py). getting you that switch in a sec :)12:56
dimskragniz: inc0: REQUIREMENTS_MODE=soft from http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh#n33412:59
inc0dims, added to projects13:01
inc0I don't think heat uses this;) I guess I'll wait for global-reqirements13:02
openstackgerritMerged openstack/cliff: Fix pep8 tests for lambda  https://review.openstack.org/15577813:05
*** kgiusti has joined #openstack-oslo13:11
*** sputnik13 has quit IRC13:17
*** rushiagr_away is now known as rushiagr13:22
*** takedakn has quit IRC13:37
*** mtanino has quit IRC13:44
*** sigmavirus24_awa is now known as sigmavirus2413:59
*** viktors|afk is now known as viktors14:04
*** exploreshaifali has joined #openstack-oslo14:11
*** salv-orlando has quit IRC14:15
*** bknudson has quit IRC14:15
*** gordc has joined #openstack-oslo14:17
*** bknudson has joined #openstack-oslo14:36
*** jungleboyj has quit IRC14:36
*** zz_jgrimm is now known as jgrimm14:43
dhellmanninc0, dims : we aren't ready to add versionedobjects to the global requirements yet, are we?14:47
*** mriedem has joined #openstack-oslo14:49
inc0dhellmann, I thought I could avoid that by adding that to local requirements.txt of heat14:49
inc0I was wrong.14:50
inc0so for now we have unusable, released lib :(14:50
dhellmanninc0: what's stopping you?14:50
inc0zuul14:50
dhellmanninc0: "it doesn't work" doesn't help me debug -- do you have a log or something?14:50
inc0gate requirements14:50
inc0let me show you14:50
dimsdhellmann: so, heat wants to use o.vo in kilo itself14:51
*** jgrimm is now known as zz_jgrimm14:51
inc0https://review.openstack.org/#/c/146841/14:52
dhellmanndims: and when dansmith is sure the API is solid, then that should be fine. In the mean time, I *thought* we could test integration without adding the lib to the global requirements list14:52
inc0and there is gate in zuul called requirements which throws that oslo.versionedobjects is not in global requirements, so go away14:53
dimsdhellmann: to do what inc0 needs we have to switch off some of the requirements jobs and throw in REQUIREMENTS_MODE=soft in the gate jobs14:53
dimsright14:53
dhellmanndims: I didn't realize devstack was also testing the requirements, I thought we had a separate job for that14:53
dansmithdhellmann: this is what I was saying yesterday, I don't think devstack will even start a stack14:54
dimsdhellmann: i've done this for nova-docker (set things up so docker-py which is not in global reqs) can be used14:54
dhellmannbah14:54
dimsbut don't recommend it!14:54
dansmithdhellmann: it doesn't normally, but thought maybe you were indicating that it was overridden in the gate for testing new things14:54
dhellmannsdague: can we separate the testing of valid requirements sets from the installing and running of tempest so we can test early releases of libraries?14:54
dansmithdhellmann: isn't everyone that starts using this in a well-understood buyer-beware sort of situation?14:55
dhellmanndansmith: everyone always says they understand, and then gets pissy when it turns out that we do change something. So not in this Real Life. :-(14:55
dhellmanndims: isn't this how we did oslo.log? I thought we avoided adding it to the requirements list for a while.14:56
dansmithsigh14:57
dansmithdhellmann: I think that if heat isn't able to merge things nowish that use it, then we're pretty much sunk for kilo14:57
sdaguedhellmann: the g-r sync is actually really important in devstack, it's the reason it was created14:57
inc0maybe we should enable some sort of backdoor for selected projects for that?14:57
*** tedross_ has joined #openstack-oslo14:57
inc0we need gunea pigs...14:57
dansmithdhellmann: even if devstack would let us do testing, we still have to do the sync before they can merge, right?14:58
dimsdhellmann: digging up a review14:58
dhellmannsdague: I understand, but now I'm in a situation that I have to release an untested library with an unproven API (no offense dansmith) just to *try* it in a project. Is there some middleground? Split that into a separate job, maybe?14:58
sdaguebecause without it you get the old case, where projects install conflicting versions of the same library, then pkg_resources explodes on a service start14:58
dimsdhellmann: inc0: https://review.openstack.org/#/c/147641/14:59
dhellmannsdague: right, I'm saying run the sync in "light" mode inside devstack and run the full thing separately in another job to test the actual requirements match. Didn't we used to do that?14:59
*** exploreshaifali has quit IRC14:59
dimsdhellmann: inc0: you can use that technique to test14:59
sdaguedhellmann: no, g-r was created for the devstack case14:59
sdaguethat's actually the bug that we were fixing14:59
dhellmannsdague: at some point we had a job that *just* looked at the requirements list, though, I thought14:59
sdaguewe also have those jobs15:00
dhellmannright now the only case I need to support is adding a new lib to a project15:00
sdaguebut devstack has always worked this way15:00
sdaguesince we created g-r15:00
dhellmannok. I want to change it.15:00
sdagueit's really the point15:00
*** prad has joined #openstack-oslo15:00
sdagueso, I think that's a bad idea15:00
dimssdague: let's see how far inc0 gets with the technique i used above for oslo.log15:01
dhellmannwould it not work to sync the requirements in the same mode as projects that don't enforce g-r? that only allows new things, right?15:01
sdaguedhellmann: and it opens up this whole other wedge problem15:01
sdaguewhich is not theoretical, it was blocking us a couple times a month15:01
inc0uhh...should I do that in heat?15:01
dhellmannsdague: but if we're still also requiring that requirements actually match in a separate job, nothing that failed that would merge, right?15:01
sdaguedhellmann: I think we're talking past each other, maybe15:02
dhellmannsdague: what I'm saying is that we're combining the 2 tests now, "do all of these things work together" and "is this project using valid versions of the requirements"15:02
dhellmannand I want those tests to be distinct, so that I can try things that fail the second to see if they pass the first before I fix the second15:03
sdaguedhellmann: so, the problem with that15:03
sdagueis we install 20 projects15:03
sdagueor more15:03
dhellmannI don't understand why we have to do the requirements check inside devstack itself, I guess.15:03
dhellmannI understand why we need to sync there, but not check.15:04
*** daniel3_ has joined #openstack-oslo15:04
sdaguehmm....15:04
inc0dhellmann, but since we run gate tests, we should run these on same setup it would before merge15:04
inc0maybe just fail this test and allow installation of rest?15:05
dhellmanninc0: it would be. You would add a new requirement and the gate check would run with it. The *separate* requirements job would fail, until the global-requirements were updated and then you would have to re-run the gate check.15:05
inc0so I'll have one merge-blocking failed test, but I could work on it and rest of gates would produce meaningful output?15:05
dansmithinc0: that's what I was hoping for15:06
dhellmanninc0: right15:06
inc0well...it didn't..15:06
dhellmanninc0: yes, I misremembered how we did this for oslo.log and now I'm trying to see if we can change that aspect of the gate15:07
sdaguedhellmann: so, that's going to make an assumption that the requirements job covers all the inbound possible changes for this for all projects15:07
sdaguewhich... I'm not sure we have been careful about15:07
* dhellmann parses that sentence15:07
dhellmanndoes the requirement job not verify that the requirements listed in requirements.txt match exactly what is in global-requirements.txt?15:08
dhellmanninterestingly, I don't see the requirements job running for heat here: https://review.openstack.org/#/c/146841/15:08
sdagueit does, but I'm not sure what the guaruntees are for everything that can be specified in devstack15:08
sdagueand if something manages to bump that15:09
sdagueand slip in, then we end up wedged in devstack15:09
*** e0ne is now known as e0ne_15:09
dhellmannok, fair15:09
sdaguewe could create a job in the experimental queues that did the soft update15:09
sdagueso it wouldn't impact the main tests, but could be run on demand15:10
dhellmanncould we change the existing job to do the check at the end?15:10
dhellmannthat would let it actually try to run the tests, and then only fail if the requirements don't match properly (assuming the code works)15:10
sdagueno, I think you miss the fail condition15:10
sdaguewe do the sync15:10
sdaguewe install the requirements15:10
dansmithTBH, I don't see what the point of doing that is15:10
*** yamahata has joined #openstack-oslo15:11
dansmithinc0: is going to put up code that he know works, and if the gate verifies it, he's going to want to merge it15:11
sdaguethe failure condition is that project A installs requirements, project B installs different versions of same requirements15:11
dansmiththat doesn't tell us anything about the API or the fitness of the library other than that it does some basic stuff15:11
sdagueproject A can't start because the wrong versions are now available15:11
*** jecarey has joined #openstack-oslo15:11
dansmithit's weeks down the road where we might hit some snag, and that's going to be after he'll have wanted to be merging code15:11
dhellmanndansmith: because if it *doesn't* work when you do the same thing in nova, you're going to want to change the API and may break what was working for inc0 in another project15:11
sdagueit fails in an extremely cryptic tempest error15:11
dhellmannI'm trying to avoid having to honor our first draft of the API for all time15:11
dansmithdhellmann: but what about what we're discussing doing right now is going to fix that?15:12
dhellmanndansmith: I am prioritizing API stability over early adoption.15:12
*** sputnik13 has joined #openstack-oslo15:12
sdagueway after the real failure is, so it's really hard to sort out what's going on15:12
dhellmannit will let us test the library in several projects before committing to the API15:12
sdaguedhellmann: so I think in that case, what you *actually* want is a different job15:13
dansmithdhellmann: but I'll not be ready to test the library in nova for months, are we going to hold up inc0 that long?15:13
dhellmannsdague: ok, yeah. So how about the experimental job. How would that work? Can we set it up so all projects have it?15:13
dhellmanndansmith: if need be.15:13
dansmithhmm, that is not at all what I thought we were doing here15:13
dhellmanndansmith: we can have that conversation, but if you're ready to commit to the API that works for heat also working in nova, then for this lib we can go ahead. I am also trying to solve this problem for everyone else that comes later, though.15:13
*** salv-orlando has joined #openstack-oslo15:14
dansmithwell, it impacts me very little, compared to inc015:14
dhellmannMy goal for this lib was a release by the end of the cycle. I do not want to jeopardize long-term stability for an impatient early adopter.15:14
sdagueright, the issue being that if we bump the API for nova, heat can't stay on the old version, because we force them off with g-r. Which really is about the problems of having a system level install of libraries.15:15
inc0but while I agree nova is top priority for this, I think caucious early adoption would be very beneficial15:15
sdagueso... there is another possible option15:15
*** SridharGaddam has quit IRC15:15
inc0we'll catch out any nova-specific things in the process15:15
dhellmanninc0: the key word there is cautious, which is what I'm trying to be15:15
dhellmannsdague: what's that?15:16
sdaguehmmm.... actually, never mind, other ideas have problems15:16
dansmithso, I thought the point here was that this is our own library, we can evolve the API and the requirement as needed,15:16
inc0dhellmann, and I totally agree, but we won't find bugs unless we actually start using it15:16
dhellmanndansmith: we can, but we are constrained by the fact that all projects must always be using the same version of the library.15:16
dansmithif we find something that is a no-go for nova, we can iterate heat from 0.1.0 to 0.1.7 before we merge 0.1.8 which is what nova actually needs15:16
dansmithsure15:16
inc0can't we somehow restrict adoption of this for a time being?15:17
dhellmanninc0: no, there is no way to restrict adoption once we release the first version15:17
sdagueinc0: it's released on pypi, you can't15:17
dhellmannthe *only* thing stopping anyone from using it now is that it's not in global-requirements15:17
inc0also, I'll be here, if we find something hard for nova, I can work with dansmith to solve it in a way that will be ok for heat too15:17
sdagueI suppose you could put a big warnings.warn in it that this library interface is currently unstable15:17
sdagueuntil you are convinced it's not15:18
sdagueat least new adopters would see that when they ran tests15:18
dansmithsdague: nobody is going to use this but us.. we've been saying that15:18
inc0we could remove all docs about that and make code criptic enough for anyone to understand;)15:18
dhellmanndansmith: "us" includes all of stackforge15:18
dansmithsdague: so I honestly don't think it's even a concern15:18
dansmithdhellmann: stackwho? :D15:18
* dansmith kids15:18
*** e0ne_ has quit IRC15:19
sdagueyeh, so this feels like the standard snake eating it's tale of testing / releasing. You don't want to release until it's tested, but no one really uses it until it's released, which is a bunch of your testing.15:20
sdaguehonestly, I'd just go with release, and tell people the interface will evolve, use at your own risk15:20
sdagueand if people yell later, just point them at that part of the readme15:21
dhellmannsdague: right. our unique gate structure lets us release and test without pushing to production, though, and I'd like to take advantage of that15:21
dansmithlemme ask this:15:21
dhellmanndansmith: you're the lead for the library, so I'm going to defer to you. I would prefer to wait, and figure out a way to have test jobs going in multiple projects before we commit to an API, but if you want to go ahead we can. I'll direct questions and complaints to you, though. ;-)15:21
dansmithactually nevermind15:22
dansmithdhellmann: no, don't do that :)15:22
dansmith(defer I mean)15:22
dhellmannwell, you're going to be doing most of the work either way, so if this was what you planned and intended, I don't want to stand in the way. I can work with sdague to set up the testing I want for future libraries in parallel.15:24
dansmiththis is my first rodeo, so what I intended isn't entirely relevant here I don't think15:25
dansmithbut what I definitely didn't get,15:25
dansmithwas that you wanted to see happy runs of changes from nova, heat, and maybe cinder before we started using it at all15:25
dhellmannI'd be happy with 2, but yeah.15:25
dansmithand I feel like that's a tooon of queued up code for something like this15:26
dansmithI mean nova probably landed 50 patches to get this stuff in place before we actually started sending stuff over the wire15:26
dhellmannFor example, in oslo.policy we found when we integrated with keystone that they needed a bunch of data that hadn't been exposed publicly so they were pulling from config options.15:26
dhellmannso you're not planning to have a single patch to swap what's in nova to use the new lib?15:26
dansmithI will have to do some surgery on nova first15:27
dansmithit won't be one patch15:27
sdagueout of curiosity, where's the heat patch in question15:28
inc0hold on15:28
inc0https://review.openstack.org/#/c/146841/15:28
inc0and following patches15:28
sdagueconcrete examples might let me come up with other ideas that won't break other things we depend on15:28
dhellmanndansmith: ok, I also didn't anticipate that level of change being needed, I guess. In the past we've done adoption in one patch but those were smaller libs or matched more closely to the incubated API15:28
dansmithdhellmann: well, there were a lot of novaisms to remove, and we changed things about the registry that were very magical, and/or modifying application state15:29
dhellmannsdague: if it makes things simpler, the only case I care about this for is a new requirement. We get testing of requirement updates by modifying global-requirements itself.15:29
dhellmanndansmith: right15:29
inc0well, heat won't be frozen project eighter. If API would require a change, I think we can coordinate15:29
dansmithdhellmann: nothing was fundamental, but I'll have work to do to make it fit15:29
dhellmannwe have had to do that in the past, but we typically did it in one patch so there was a before and after rather than gradual transition15:30
inc0I think only problem we'll have would be rogue implementers who would ignore warnings of possible API changes15:30
dansmithso dhellmann, let me put up another straw man to shoot down:15:30
dhellmannmaybe the patch would be too big in nova15:30
sdagueso, yeh, heat is a good instance where if we backed that off, they'd be able to break the world here, as they don't have requirements enforcement job15:31
dhellmanninc0: There is no amount of education or publicity that will prevent that. And then when you change the API, they will say "Oslo broke my project!"15:31
sdaguehowever, inc0 what about making the heat functional job go to soft requirements15:31
dhellmannwhy doesn't heat have a requirements job?15:31
sdaguebecause at least for heat, most of your real testing is there anyway15:31
sdaguedhellmann: because no one ever added it?15:32
dhellmannsdague: ok, I thought maybe there was some reason not to have it15:32
sdaguethe job management is all manual, stuff gets missed all the time15:32
sdagueyeh, I don't know, I'm just looking at the job output15:32
dhellmannyeah, that's cool, I thought maybe there was some technical reason15:32
inc0sdague, how could I do that? I guess that would require messing up with heat CI, and that something I'd have to discuss with Angus (PTL)15:33
dhellmannsdague, inc0 : https://review.openstack.org/15950815:33
sdagueinc0: you would set REQUIREMENTS_MODE=soft in the definition of that job15:35
*** zz_jgrimm is now known as jgrimm15:35
dansmithsdague:  and that lets him start up a devstack with a local requirement out of sync?15:35
dimsdansmith: yes15:36
dansmithokay, so:15:36
dansmithif I can do that locally, I can try to sprint to a patch(set) for nova that uses the library for some amount of workyness15:36
dansmithI have no idea how long it will take15:36
dansmithbut I can try and get something up so we have an idea, or see if I hit any dragons15:37
dansmithI dunno that we want to define any new jobs for nova, maybe experimental15:37
dansmithbut that would maybe let us get some test runs on both projects for dhellmann ?15:37
*** jungleboyj has joined #openstack-oslo15:37
dimsdansmith: you can run it through gate too using this technique - https://review.openstack.org/#/c/147641/15:37
dansmithdims: with a cross-project linkage so zuul uses it?15:38
dimsdansmith: this predates Depends-On15:38
dimsbut yes, that can be tried too15:38
inc0or I could link Depends-On to global requirements patch15:38
dimsinc0: worth trying15:39
dansmithdims: I don't see how that works for testing an uncommitted nova change otherwise15:39
inc0I guess that would solve zuul problem as well15:39
dimsdansmith: you file a review against nova, and not merge it15:39
sdagueyeh, Depends-On actually solves this without any new jobs15:39
dimsdansmith: then you file a review similar to above and pull in the changeset from nova15:39
*** e0ne has joined #openstack-oslo15:39
dimssdague: hope so15:39
dansmithdims: oh right I didn't even finish reading it15:40
sdaguethat's actually probably the right way to do it, just Depends-On the requirements change15:40
dimssdague: +115:40
dansmithdhellmann: please send coffee to portland15:40
dimssdague: i just don't know if requirements repo can get pulled15:40
sdaguedims: yeh, it is15:40
sdaguethat should work15:40
dimscool15:40
dimsthere you go guys, try that first and then we have a fallback inc0 and dansmith15:41
dansmithjust so we're clear,15:41
dansmithwe're talking about inc0 depending his, and me writing something for nova that depends,15:41
dansmithso we can see that both work, yes?15:41
dimsyep15:41
inc0cool, I'll do that then, but forgive me if that will be tomoroow;)15:41
inc0dcan't we jyust both write depend on to requirement patch?15:42
dimsinc0: yes that's what you should try first15:42
inc0great15:42
dansmithyes15:42
inc0and if all will be well, we'll simply merge g-r15:43
inc0thanks guys15:43
dhellmannI like the depends on thing, dims! We should write that down.15:43
dhellmanndansmith: if portland needs more coffee, we're all doomed.15:43
dansmithhaha15:43
dansmithwell, one specific place in portland does..15:43
dimsdhellmann: y, let's try it with o.vo and i'll write it down15:43
dhellmanndims: yep15:44
dhellmannI have to run an errand, but it sounds like we have a way forward. Thank you all for working it out!15:44
ihrachyshkadhellmann, who's behind oslo.policy?15:48
dimsihrachyshka: Ian and Steve - http://stackalytics.com/?module=oslo.policy&metric=commits15:57
ihrachyshkadims, do they have irc nicks?15:58
ihrachyshkaoh, I think I can get that from gerrit names15:58
*** inc0 has quit IRC15:58
ihrachyshkasigmavirus24, hey15:58
sigmavirus24yes?15:59
sigmavirus24steve seems to not be on at the moment15:59
sigmavirus24Also I'm not core15:59
sigmavirus24So morganfainberg and bknudson and others should be asked this question as well15:59
sigmavirus24ihrachyshka: what's up?15:59
morganfainbergHi.15:59
morganfainbergWhat's up?16:00
ihrachyshkasigmavirus24, so I try to apply the lib to neutron, and I get errors due to register decorator not avail16:00
*** yamahata has quit IRC16:00
ihrachyshkawe apply @policy.register('tenant_id') to a Check class16:00
ihrachyshkaand it's missing in oslo.policy16:00
ihrachyshkathough docs still refer to iut16:00
ihrachyshka*it16:01
ihrachyshkahttp://docs.openstack.org/developer/oslo.policy/api.html#registering-new-special-checks16:01
morganfainbergOk hold on. I need to switch contexts here.16:01
morganfainbergWow. That's some descriptive docs. :P16:02
*** himangi has joined #openstack-oslo16:03
morganfainbergOk I found the code looking to see why you don't get it on import ihrachyshka16:04
morganfainbergihrachyshka: https://github.com/openstack/oslo.policy/blob/master/oslo_policy/_checks.py#L206 it's there.16:04
ihrachyshkamorganfainberg, but it's _checks16:05
ihrachyshkaprobably private16:05
ihrachyshkaI would expect it in policy.py?16:05
morganfainbergYes. Looks like it is missing from policy.py16:05
ihrachyshkamorganfainberg, what's the plan to release something official btw?16:06
morganfainbergIf it is meant to be public (docs indicate it should be)16:06
ihrachyshkamorganfainberg, neutron would be glad to switch prior to kilo16:06
morganfainbergihrachyshka: soon â„¢.16:06
morganfainbergKeystone as well16:06
ihrachyshkamorganfainberg, should I just send a patch moving the function to public place?16:07
morganfainbergWell don't "move" it. It probably just needs a reference in policy.py.16:07
*** sigmavirus24 is now known as Slackwarebot16:07
morganfainbergI'm looking now to see where it goes.16:07
*** Slackwarebot is now known as sigmavirus2416:07
ihrachyshkaok right, smth like generate = _checks.generate16:07
*** himangi has quit IRC16:08
morganfainbergYeah.16:08
*** himangi has joined #openstack-oslo16:08
morganfainbergThis was probably just missed. And is a valid bug. Since we are close to releasing officially you can fix it and we can get that added.16:09
ihrachyshkamorganfainberg, ack, on my way16:10
morganfainbergWe should be releasing soon. So changing over in kilo should be possible. Keystone really would like this as well.16:10
morganfainberg:). Good catch.16:10
ihrachyshkamorganfainberg, yeah, was tired of waiting for release and decided to try it out before16:12
morganfainberg^_^16:12
*** himangi has quit IRC16:12
openstackgerritIhar Hrachyshka proposed openstack/oslo.policy: Expose register decorator as part of public API  https://review.openstack.org/15952516:12
ihrachyshkamorganfainberg, ^^16:12
*** himangi has joined #openstack-oslo16:13
morganfainbergYep. We also see oslo.policy announcement in -keystone since most of the cores are keystone folks.16:13
morganfainberg:)16:13
ihrachyshkamorganfainberg, hm, other stuff is missing too16:16
ihrachyshkalike Check class16:16
ihrachyshkait's also in _checks.16:16
morganfainbergWe might have gotten a bit aggressive in internal api-ing things.16:17
morganfainbergIt is always easier to make something a public api from private than the inverse.16:17
ihrachyshkamorganfainberg, yeah, but that thing is mentioned in public docs16:18
ihrachyshkait's not like neutron got consuming something hidden16:18
morganfainbergAgain. Too aggressive. :).16:18
bnemecsdague: Not sure if you ever got an answer, but the missing policy.d thing should be fixed by https://github.com/openstack/oslo.policy/commit/d8129456855a63e124cef8435dc12b5bd4a82d0316:18
sdaguebnemec: cool, is that released?16:19
ihrachyshkamorganfainberg, ok, I'll add Check in the patch too16:19
bnemecsdague: I believe so, but I'm not sure if anyone has adopted the lib yet.16:19
bnemecSeems like most projects are still on the incubator version.16:20
morganfainbergsdague: it was tagged. Going to be officially released soon (needs a few bug fixes before it's ready for full consumption)16:20
sdaguebnemec: ok, could we fix the incubator as well then?16:20
sdaguebecause, that's a really noisy state to be in for the release16:20
sdagueif most projects aren't going to switch over16:20
morganfainbergKeystone has a patch to use it. Next tag + requirements update will likely go out soon (we were hoping this week)16:20
openstackgerritIhar Hrachyshka proposed openstack/oslo.policy: Expose register decorator as part of public API  https://review.openstack.org/15952516:20
bnemecsdague: Yeah, that would be fine with me.  I think dhellmann wanted to focus on getting the lib adopted instead, but this late in the cycle I don't know if that's still going to happen.16:21
*** exploreshaifali has joined #openstack-oslo16:22
morganfainbergbnemec: I think a couple projects will adopt. But not all.16:22
morganfainbergKeystone and neutron likely. I doubt nova will.16:22
sdagueyeh, and all of them are currently generating warnings on tihs16:22
bnemecYeah16:22
morganfainbergSo we should fix incubator.16:22
morganfainberg(Unfortunately)16:22
ihrachyshkamorganfainberg, re option registration, where is the best option to do it? when importing neutron.policy, or when calling neutron.policy.init()?16:24
viktorsdhellmann: around?16:24
morganfainbergihrachyshka: hm. Not sure how neutron sets all that up so I don't have a good answer :(. Keystone we register at fixed times.16:25
morganfainbergihrachyshka: I think it just depends on how neutron generally does that.16:26
ihrachyshkaI need to check, but the answer will probably be 'randomly'16:26
ihrachyshkathat's the neutron culture!16:26
ekarlsois oslo.policy released or ?16:28
*** tsekiyama has joined #openstack-oslo16:28
morganfainbergekarlso: tagged but needs another patch or so and another tag + requirements update before being used.16:29
morganfainbergekarlso: very very soon â„¢ it will be released imo.16:29
morganfainbergihrachyshka: not sure if I should laugh, cry, or something else ;)16:30
ihrachyshka#sadpanda is the right tag16:30
ihrachyshkaoh, it also adopted a new option group...16:33
*** viktors is now known as viktors|afk16:34
*** david-lyle_afk is now known as david-lyle16:36
*** rushiagr is now known as rushiagr_away16:40
*** himangi has quit IRC16:42
*** amotoki has quit IRC16:43
*** stevemar has joined #openstack-oslo16:44
openstackgerritGreg Hill proposed openstack/taskflow: add jobboard trash method  https://review.openstack.org/15845916:44
*** himangi has joined #openstack-oslo16:46
*** rushiagr_away is now known as rushiagr16:47
*** pcaruana has quit IRC16:50
*** salv-orlando has quit IRC16:53
*** takedakn has joined #openstack-oslo16:53
*** amotoki has joined #openstack-oslo16:54
dhellmannviktors|afk: sorry I missed you. Congrats on the oslo.db release! I see a few things in https://launchpad.net/oslo.db/+milestone/1.5.0 that aren't "done" so I'll move those to next-kilo.16:54
*** ihrachyshka has quit IRC17:00
*** amotoki has quit IRC17:02
*** dulek has quit IRC17:10
*** dulek_ has quit IRC17:10
*** i159 has quit IRC17:11
*** dtantsur is now known as dtantsur|afk17:13
*** noelbk has joined #openstack-oslo17:17
*** ViswaV has joined #openstack-oslo17:20
openstackgerritMerged openstack/cliff: Allow to call initialize_app when running --help  https://review.openstack.org/15834317:21
*** ZZelle has joined #openstack-oslo17:22
ZZelleHi everyone!17:22
ZZelleWould it make sense to move https://github.com/openstack/heat/blob/master/heat/api/middleware/ssl.py in oslo.middleware?17:22
ZZelle<sigmavirus24> ZZelle: that would be a better question for #openstack-oslo17:22
openstackgerritIhar Hrachyshka proposed openstack/oslo.policy: Expose stuff used in Neutron as part of public API  https://review.openstack.org/15952517:23
*** ihrachyshka has joined #openstack-oslo17:24
ihrachyshkamorganfainberg, so I've updated the patch with all we need in neutron: https://review.openstack.org/#/c/159525/17:24
ihrachyshkamorganfainberg, but I suspect someone should really go thru the list of other stuff and decide whether it also belongs to public17:25
sigmavirus24ZZelle: I also qualified that with "If it's being used outside of heat"17:25
sigmavirus24I also think we should avoid providing ssl middleware when far better options exist for deployments (and we should be pointing deployers towards them)17:26
ZZellesigmavirus24, it's being used outside of heat :), even outside of OpenStack17:26
sigmavirus24ihrachyshka: I would argue that those specific checks shouldn't be used by people using oslo.policy17:27
ZZellethe ssl middleware is wrongly named as it does not provide ssl termination but add support for  X-Forwarded defacto standard header17:27
sigmavirus24Just because they're using them now does not mean they should have been using them in the first place, but I haven't seen the examples of people using these checks directly17:27
sigmavirus24ZZelle: which one? there are several (since there is a de facto set of 2 or 3, there is no single de facto header)17:28
*** ViswaV_ has joined #openstack-oslo17:28
sigmavirus24I've seen Proto and Protocol at least17:28
sigmavirus24I think I've seen a third17:28
*** ViswaV has quit IRC17:28
*** yamahata has joined #openstack-oslo17:29
ihrachyshkasigmavirus24, http://git.openstack.org/cgit/openstack/neutron/tree/neutron/policy.py#n15817:29
sigmavirus24ihrachyshka: was that rejected while oslo.policy was in incubation?17:31
ZZellesigmavirus24, an internal project :)17:32
ihrachyshkasigmavirus24, define that17:32
ZZellesigmavirus24, and neutron is about to add a public endpoint url when a correct middleware would better feet17:32
sigmavirus24ihrachyshka: so I don't understand the /need/ for subattributes but was optional typing as a subattr ever proposed to be included in oslo.policy while it was in incubation?17:32
ihrachyshkasigmavirus24, I don't think so. haven't tracked that.17:33
dhellmannsileht: https://bugs.launchpad.net/oslo.messaging/+bug/142604617:34
openstackLaunchpad bug 1426046 in oslo.messaging "there is no public base class for notifier drivers" [Undecided,New]17:34
*** mriedem is now known as mriedem_away17:34
sigmavirus24ihrachyshka: it seems like something that should be proposed for inclusion in oslo.policy. I want to see if any other project needs those symbols your making public though17:34
ihrachyshkasigmavirus24, some of them should obviously be public (Check, register). are we speaking about specific check types?17:35
sigmavirus24ihrachyshka: those two I agree make sense17:36
sigmavirus24the specific check types seem wrong though17:36
sigmavirus24I'm checking other projects now to see what they use17:36
ihrachyshkasigmavirus24, so full disclosure, I don't know much about neutron case, so I will be able to discuss it tomorrow only17:37
sigmavirus24ihrachyshka: so nova would agree that register and Check should be public symobls17:37
sigmavirus24(which I was already +1 for)17:37
ihrachyshkasigmavirus24, let's discuss the matter tomorrow or the next week. will there be a release before that time?17:40
sigmavirus24ihrachyshka: probably17:40
sigmavirus24keystone needs it for the changes stevemar is making in keystone17:41
* stevemar scrolls up17:44
stevemarihrachyshka, sigmavirus24 i'd be cool with the decorators being public... we could postpone releasing a new version until this is in, they keystone stuff is not *that* necessary to get in17:46
sigmavirus24stevemar: right but this patch isn't totally in the clear yet17:48
sigmavirus24mostly because I've yet to find that neutron is not alone17:48
ihrachyshkastevemar, I just need one day to participate in proper discussion on why the neutron usage17:49
*** salv-orlando has joined #openstack-oslo17:49
stevemarah, consider why it's being used?17:49
ihrachyshkaright, I don't know it yet for sure17:54
*** tedross_ has quit IRC18:03
*** kbyrne has quit IRC18:03
*** SridharG has joined #openstack-oslo18:03
*** kbyrne has joined #openstack-oslo18:05
sigmavirus24ihrachyshka: they're adding/allowing for additional pieces to be added to policy rules, extensions of sorts18:06
sigmavirus24There's no built-in way for that so they're using those classes directly, which is probably a bad idea18:06
sigmavirus24stevemar: ^18:06
stevemarsigmavirus24, eek18:07
sigmavirus24stevemar: yep18:07
sigmavirus24that's how I read the code at least18:07
sigmavirus24stevemar: mostly type annotations it seems18:07
openstackgerritBen Nemec proposed openstack/oslo.policy: Add missing space to help message  https://review.openstack.org/15955818:09
*** ChuckC has quit IRC18:17
openstackgerritBen Nemec proposed openstack/oslo-incubator: Do not log on missing or empty policy_dirs  https://review.openstack.org/15956218:18
*** ajo has quit IRC18:18
*** ajo has joined #openstack-oslo18:19
*** tedross_ has joined #openstack-oslo18:19
*** inc0 has joined #openstack-oslo18:19
bnemecsdague: ^18:21
*** ajo has quit IRC18:29
*** saikrishna has joined #openstack-oslo18:33
*** cdent has quit IRC18:34
*** ihrachyshka has quit IRC18:37
*** mtanino has joined #openstack-oslo18:40
*** ChuckC has joined #openstack-oslo18:40
*** ChuckC has quit IRC18:47
*** ChuckC has joined #openstack-oslo18:49
*** ihrachyshka has joined #openstack-oslo18:50
*** dims_ has joined #openstack-oslo18:51
*** dims_ has quit IRC18:53
*** dims_ has joined #openstack-oslo18:54
*** exploreshaifali has quit IRC18:55
*** dims has quit IRC18:55
*** e0ne is now known as e0ne_19:00
*** prad has quit IRC19:01
ihrachyshkasigmavirus24, stevemar, ok, I discussed the matter with guys. so the plan is to move the sub-attr matching feature under oslo.policy hood, and maybe some more custom checks we maintain (I'll look closer tomorrow). and it means that we won't be able to consume the initial releases anyway.19:02
sigmavirus24ihrachyshka: yeah, y'all will probably want to create some blueprints/specs for that19:05
sigmavirus24stevemar: dhellmann those would go to oslo-specs, right?19:06
ihrachyshkasigmavirus24, right. I've reported a neutron bug for now, but yes, seems like a valid case for specs19:07
ihrachyshkasigh19:07
*** SridharG has quit IRC19:07
ihrachyshkaI thought it will be as trivial as usual.19:07
ihrachyshka:)19:07
*** jungleboyj has quit IRC19:07
sigmavirus24ihrachyshka: sorry19:07
ihrachyshka:)19:07
sigmavirus24the folks at neutron seem to have had other plans for your time19:07
sigmavirus24No good deed and what not ;)19:07
*** jungleboyj has joined #openstack-oslo19:08
sigmavirus24ihrachyshka: would it be okay if we reverted your change back to PS1 to get those symbols released so projects like nova can start using oslo.policy when it wants?19:10
sigmavirus24We'll then discuss adding those symbols or allowing policy syntax extensions on the blueprint(s)/spec(s)19:10
sigmavirus24Is that okay?19:10
ihrachyshkayeah, I was going to leave home though. if you can, please do, otherwise I'll do it tomorrow19:10
ihrachyshkaok, now leaving19:11
*** inc0 has quit IRC19:11
sigmavirus24bye ihrachyshka19:15
dansmithdhellmann: https://review.openstack.org/15957719:16
*** ihrachyshka has quit IRC19:16
dansmithdhellmann: passes our unit tests, putting it up while I build devstack to see what else needs to change19:16
dansmithdhellmann: there are major hacks in there to save some typing and avoid having to refactor some things the right way19:16
dansmithdhellmann: and I found a couple of gotchas that I need to fix in the library19:16
dansmithdhellmann: so far, nothing fundamentally unusable yet19:17
dansmithdhellmann: it also points out a couple places where we are (a) breaking (cheating really) our own model or (b) still need to do some cleanup we thought was done19:18
dansmithoh, dangit I forgot the depends-on19:19
*** ajo has joined #openstack-oslo19:22
*** tedross_ has quit IRC19:22
*** himangi has quit IRC19:26
*** exploreshaifali has joined #openstack-oslo19:30
*** saikrishna has quit IRC19:38
*** tedross_ has joined #openstack-oslo19:39
*** jecarey has quit IRC19:43
*** achanda has joined #openstack-oslo19:45
*** e0ne_ is now known as e0ne19:52
*** exploreshaifali has quit IRC19:56
*** jungleboyj_ has joined #openstack-oslo20:01
*** jungleboyj has quit IRC20:03
*** jecarey has joined #openstack-oslo20:03
*** himangi has joined #openstack-oslo20:03
*** ajo has quit IRC20:03
*** ajo has joined #openstack-oslo20:07
*** himangi has quit IRC20:15
dhellmanndansmith: ok, so do you anticipate breaking API changes to fix those issues?20:18
dhellmannthat's ultimately what we're looking for20:18
dansmithdhellmann: I was trying to say: nothing so far needs a breaking change that I foresee20:19
dansmithdhellmann: I'm not done yet of course, but just trying to give some incremental progress feedback20:19
openstackgerritSabari proposed openstack/oslo.vmware: Add get_datastore_by_ref method to oslo.vmware  https://review.openstack.org/15935720:19
dhellmanndansmith: ok, I wasn't sure how bit a "gotcha" was :-)20:19
openstackgerritSabari proposed openstack/oslo.vmware: Add get_datastore_by_ref method to oslo.vmware  https://review.openstack.org/15935720:19
dansmithdhellmann: on the level of forgetting to call super() a couple times :)20:19
dhellmanndansmith: I'm a bit more comfortable moving ahead with a formal release now, then20:19
dhellmannheh, sure20:19
dhellmannso bugs but not design issues20:20
dansmithdhellmann: yeah, there is one thing that doesn't work exactly like I intended, but it's only a problem because nova needs to override something for compatibility,20:20
dansmithdhellmann: shouldn't impact anyone else, and even if I couldn't do another release I could work around it in a not horrible way20:21
openstackgerritDavanum Srinivas (dims) proposed openstack/oslo-incubator: Handle non-json http exceptions better  https://review.openstack.org/14483920:21
dansmithanyway, let me continue down the devstack and tempest path before "a bit more comfortable" becomes "comfortable enough"20:21
*** tedross_ has left #openstack-oslo20:23
dhellmanndansmith: sounds good20:24
*** himangi has joined #openstack-oslo20:27
*** sigmavirus24 is now known as sigmavirus24_awa20:32
*** himangi has quit IRC20:33
*** ajo has quit IRC20:34
jogodhellmann: https://launchpad.net/openstack20:36
jogois missing all of the oslo libs20:37
jogosuch as oslo.db20:37
jogothe admin for the oslo.db group etc can add it to openstack20:37
dhellmannjogo: https://launchpad.net/oslo20:37
dhellmannttx and I moved them to a different project group so we could see unified view of the next-kilo milestones20:37
dhellmannit also lets us do some other things in LP that I can't think of off the top of my head20:38
dhellmannnot ideal, but necessary20:38
openstackgerritMerged openstack/oslo-incubator: Do not log on missing or empty policy_dirs  https://review.openstack.org/15956220:38
jogodhellmann: any way  to add that group to openstack?20:38
dhellmannjogo: this is also why blueprint links to oslo blueprints from gerrit are broken20:38
dhellmannjogo: no, you can't nest project groups in lp20:38
dhellmannadd this to the list of things that gets better with storyboard20:39
* jogo blames lifeless for funky launchpad issues20:39
*** himangi has joined #openstack-oslo20:40
jogodhellmann: one big downside is you can't just go to launchpad openstack and click the low hanging fruit bug tag20:47
jogoand see oslo stuff20:47
*** mriedem_away is now known as mriedem20:47
dhellmannjogo: yep, that is another downside20:47
mtreinishjogo: why not just have the e-r test look for membership in both groups20:47
mtreinishnot the best, but at least it'll get you around the issue20:48
jogomtreinish: doing that20:48
jogonext up is https://launchpad.net/openstack-api-site20:48
openstackgerritJohn Stanford proposed openstack/oslo.log: Make use_syslog=True log to syslog via /dev/log  https://review.openstack.org/15960620:49
openstackgerritErno Kuvaja proposed openstack-dev/hacking: Add own block in imports for six overwrites  https://review.openstack.org/15919620:49
mtreinishjogo: we have e-r queries for bugs in that group?20:49
jogomtreinish: yup https://bugs.launchpad.net/openstack-api-site/+bug/133573120:49
openstackLaunchpad bug 1335731 in openstack-api-site "dox-publish build fails to build for identity-api" [Critical,Fix released] - Assigned to Anne Gentle (annegentle)20:49
mtreinishmorganfainberg: ^^^ fix it...20:50
mtreinishjogo: heh, that's weird. but ok20:50
morganfainberguh.20:51
morganfainbergwhat?20:51
mtreinishjogo: wait it's marked as fixed :)20:51
jogomtreinish: still has hits20:51
jogofixed recently20:51
morganfainbergidentity-api shouldn't be built!20:51
morganfainbergattic ;)20:51
mtreinishmorganfainberg: heh, sorry I didn't realize it was fixed released either :)20:51
mtreinishjogo: yeah that is weird, where was it hitting, because that was moved to attic more than 10 days ago20:52
jogomtreinish: didn't dig in too much20:52
morganfainberghehe20:53
jogomtreinish: good news is the docs thing is the last one20:57
*** morganfainberg is now known as needscoffee20:57
*** kgiusti has left #openstack-oslo21:06
*** rushiagr is now known as rushiagr_away21:06
*** jecarey_ has joined #openstack-oslo21:14
*** jecarey has quit IRC21:17
openstackgerritIhar Hrachyshka proposed openstack/oslo.policy: Expose stuff used in Neutron as part of public API  https://review.openstack.org/15952521:20
openstackgerritIhar Hrachyshka proposed openstack/oslo.policy: Expose register and Check as part of public API  https://review.openstack.org/15952521:21
*** ihrachyshka has joined #openstack-oslo21:21
mriedemdhellmann: is there a special wiki for how to release oslo libaries and/or clients to get launchpad updated with a milestone?21:23
*** tsekiyama has quit IRC21:26
*** tsekiyama has joined #openstack-oslo21:26
openstackgerritMerged openstack/oslo.policy: Add missing space to help message  https://review.openstack.org/15955821:26
*** jungleboyj_ has quit IRC21:27
*** achanda has quit IRC21:34
dhellmannmriedem: yes, there is! let me find that link...21:34
dhellmannmriedem: https://wiki.openstack.org/wiki/Oslo/ReleaseProcess21:34
mriedemdhellmann: ah, thanks21:34
*** achanda has joined #openstack-oslo21:35
mriedemdhellmann: also, btw, just sanity check on version - we have python-novaclient 2.21 today, we have like 1 or 2 changes on master, no requirements updates, just bug fixes for what busted 2.21, so i'm assuming the version is then 2.21.1?21:35
dhellmannmriedem: let me look at the git logs, but that sounds right21:35
mriedemhttp://paste.openstack.org/show/182694/21:36
mriedemnothing for: edem@ubuntu:~/git/python-novaclient$ git log --oneline --no-merges 2.21.0.. -- requirements.txt21:37
dhellmannthat revert looks like it might require a minor update, what's going on there?21:37
dhellmannI guess that's a bug fix21:38
mriedemthat bash completion change busted volume-attach and was in 2.2121:38
mriedemyeah21:38
mriedemwe didn't release since last sept21:38
mriedemso it lurked forever21:38
dhellmanne6883d2 looks like a new feature21:38
mriedemsays partial bug21:38
openstackgerritSteve Martinelli proposed openstack/oslo-incubator: Remove policy from oslo-incubator  https://review.openstack.org/15281221:39
mriedemdhellmann: that just makes novaclient more consistent with other clients21:39
openstackgerritSteve Martinelli proposed openstack/oslo-incubator: Prevent update.py from updating policy  https://review.openstack.org/15281321:39
dhellmannmriedem: when in doubt you want to bump the minor version. The exceptional cases will lead you to bumping the patch or major version.21:39
dhellmannThe "bug" here was that nova wasn't being consistent with the other projects.21:40
dhellmannTo make it consistent, it looks like a new feature was added.21:40
mriedemok, sure, i could see that as a wishlist bug21:41
mriedemi.e. feature21:41
dhellmanna new behavior was added that modifies the input provided by the user so they can use an abbreviation instead of the full value21:41
dhellmannyeah, just because it's a bug in launchpad doesn't mean it's a semver bug :-)21:41
dhellmannthose other things do look patch-level worthy, but this one makes me think it'd be better to call it 2.22.021:42
mriedemdhellmann: ok, will do, thanks for looking21:44
mriedemwill do monday anyway :)21:44
dhellmannmriedem: glad to help, any time!21:45
*** takedakn has quit IRC21:45
dansmithdhellmann: ohai21:51
dhellmanndansmith: greetings21:51
dansmithdhellmann: https://review.openstack.org/#/c/159577/21:51
dansmithpep8 failed because I didn't care, requirements because, well, you know, and grenade for some glance reason21:51
dansmithdhellmann: please feel free to be amazed :)21:51
dansmithdhellmann: but, the interesting bit is that the partial-ncpu job worked, which is juno nova using in-tree objects, talking over the wire to this change using o.vo objects21:52
dansmithdhellmann: which means they're interoperable over the wire as well, hence we should be good rolling to these with nova in a live upgrade situation21:53
*** e0ne has quit IRC21:54
*** jecarey_ is now known as jecarey21:56
dhellmanndansmith: you've boosted my confidence over the threshold.21:58
dansmith\o/21:58
dhellmanndansmith: does that mean we're ready to add 0.1.0 to the global requirements list, or do we need another release first21:58
dansmithdhellmann: I didn't have to change anything in o.vo, this is running against the pypi version21:59
dansmithdhellmann: now, I could clean up the few things I found if it would make you feel better21:59
dansmithand/or we can wait for inc0 tomorrow and I can discuss some of the things I'm working around22:00
dhellmannit's up to you, you're closer to the details than me22:00
dansmithlet's wait for tomorrow morning22:00
dansmithI'll send him an email tonight and start working on some patches to what I need22:00
dhellmanndansmith: sounds good, and thanks for pushing so hard on that today22:01
dansmithdhellmann: one question I had was, are stackforge projects limited by g-r?22:01
dhellmannthey can do a "soft sync" to keep up to date while still using new things of their own22:01
dhellmannwe don't let them add new requirements to the global list, though22:02
dansmithso it's not like g-r is blocking them from using this, and thus it's not like we can magically break our api between 0.1.0 and 0.1.1 because it never made it into g-r22:02
*** takedakn has joined #openstack-oslo22:02
*** gordc has quit IRC22:04
dhellmanndansmith: true. This is all about managing expectations. If it's in g-r, then the expectation is we have deemed it safe to use. If not, they're aware they are on their own.22:04
dansmithdhellmann: okay22:04
dhellmannthe integrated projects would be blocked from adopting it, and keeping them from breaking is more important as far as the gate22:05
dansmithI didn't realize g-r had any such implication I guess22:05
dansmithyeah22:05
*** e0ne has joined #openstack-oslo22:05
dhellmannI'm probably excessively conservative about first releases, but that seems better than any of the alternatives I've seen so far. :-)22:06
*** takedakn has quit IRC22:11
*** needscoffee is now known as needsmostcoffee22:12
*** needsmostcoffee is now known as morganfainberg22:13
*** stevemar is now known as thinksmorganneed22:13
*** thinksmorganneed is now known as stevemar22:13
*** jungleboyj_ has joined #openstack-oslo22:16
*** takedakn has joined #openstack-oslo22:19
*** jgrimm is now known as zz_jgrimm22:20
*** takedakn has quit IRC22:36
*** takedakn has joined #openstack-oslo22:36
*** jaosorior has quit IRC22:42
*** rodrigods is now known as rodrigod`22:42
*** rodrigod` is now known as rodrigods22:43
*** takedakn has quit IRC22:43
*** rodrigods is now known as rodrigod`22:51
*** rodrigod` is now known as rodrigods22:51
*** achanda has quit IRC22:51
*** andreykurilin_ has joined #openstack-oslo22:53
openstackgerritDavanum Srinivas (dims) proposed openstack/oslo-incubator: Expose opts entry point for version_utils  https://review.openstack.org/15964622:53
openstackgerritDavanum Srinivas (dims) proposed openstack/oslo-incubator: Expose opts entry point for version_utils  https://review.openstack.org/15964622:54
stevemardhellmann, fwiw, i think most keystoners are in favor of https://review.openstack.org/#/c/148624/ in it's current state, esp. since there is a follow up patch to clean up tests.22:59
stevemarThere was a few patch proposed in oslo.policy too, to surface a few other functions22:59
*** achanda has joined #openstack-oslo23:02
openstackgerritDan Smith proposed openstack/oslo.versionedobjects: Make serializer use the provided base class for the indirection api  https://review.openstack.org/15965623:08
openstackgerritDan Smith proposed openstack/oslo.versionedobjects: Allow passing serializer and indirection API objects to Fixture  https://review.openstack.org/15965723:08
openstackgerritDan Smith proposed openstack/oslo.versionedobjects: Properly serialize/deserialize arguments in fake indirection api  https://review.openstack.org/15965823:08
*** bknudson has quit IRC23:09
*** takedakn has joined #openstack-oslo23:10
*** andreykurilin_ has quit IRC23:15
*** andreykurilin_ has joined #openstack-oslo23:15
*** stevemar has quit IRC23:19
*** ihrachyshka has quit IRC23:19
openstackgerritDan Smith proposed openstack/oslo.versionedobjects: Properly serialize/deserialize arguments in fake indirection api  https://review.openstack.org/15965823:21
*** jecarey has quit IRC23:25
*** andreykurilin_ has quit IRC23:26
*** andreykurilin__ has joined #openstack-oslo23:26
*** trown is now known as trown|outttypeww23:27
*** mriedem has quit IRC23:36
*** noelbk has quit IRC23:37
dhellmannstevemar: ack, I'll take a look in the morning23:41
*** amotoki has joined #openstack-oslo23:43
*** amotoki has quit IRC23:44
*** jungleboyj_ has quit IRC23:47
*** daniel3_ has quit IRC23:48
*** jungleboyj_ has joined #openstack-oslo23:53
*** himangi has quit IRC23:54
*** dims_ has quit IRC23:55
*** salv-orlando has quit IRC23:57
*** andreykurilin__ has quit IRC23:59

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