Wednesday, 2016-01-13

*** dims has joined #openstack-release00:09
*** sigmavirus24 is now known as sigmavirus24_awa00:21
openstackgerritMerged openstack/releases: Fix pep8 errors  https://review.openstack.org/26659400:25
openstackgerritMerged openstack/releases: copy send-announcements-to from mitaka to kilo and liberty  https://review.openstack.org/26644800:42
*** mriedem has joined #openstack-release01:16
*** doug-fish has quit IRC01:18
*** doug-fish has joined #openstack-release01:19
*** doug-fish has quit IRC01:33
openstackgerritSteve Martinelli proposed openstack/releases: release keystone libraries for mitaka  https://review.openstack.org/26662801:37
*** dims has quit IRC01:38
*** LouisF has quit IRC01:55
*** sigmavirus24_awa is now known as sigmavirus2403:02
*** dims has joined #openstack-release03:17
*** mriedem has quit IRC03:20
*** sigmavirus24 is now known as sigmavirus24_awa03:32
*** dims has quit IRC03:33
*** ifat_afek has joined #openstack-release08:36
*** amotoki has joined #openstack-release09:10
*** dtantsur|afk is now known as dtantsur10:02
*** ifat_afek has quit IRC10:10
openstackgerritMerged openstack-infra/release-tools: stop sending folks to launchpad milestones for release details  https://review.openstack.org/26606410:31
ttxdhellmann: I'd like to get https://review.openstack.org/#/c/264754 in before it gets mergeconflicted again, so I could use your review there10:40
*** ifat_afek has joined #openstack-release11:06
*** ifat_afek has quit IRC11:08
*** flwang1 has quit IRC11:48
*** flwang1 has joined #openstack-release11:49
*** skraynev has quit IRC11:57
sdaguelifeless: tox version is 1.9.2. tox.ini specifies min version of 1.811:59
*** skraynev has joined #openstack-release12:01
*** doug-fish has joined #openstack-release12:01
*** devananda has quit IRC12:08
*** devananda has joined #openstack-release12:13
*** bswartz has quit IRC12:19
*** dims has joined #openstack-release12:28
*** gordc has joined #openstack-release12:30
ttxdims: I'd like to get https://review.openstack.org/#/c/264754 in before it gets mergeconflicted again, so I could use your rereview there12:33
*** dims has quit IRC13:25
*** dims has joined #openstack-release13:26
*** bswartz has joined #openstack-release13:31
ttxdhellmann: added Daviey to the release managers groups since he will handle the last two kilo coordinated stable releases13:56
ttx(in LP and Gerrit)13:56
dimsttx : on my way13:57
ttxwe have been checking that the tooling will still work as far as stable/kilo is concerned13:57
dimsttx : +2A13:57
ttxprocess was only using process_bugs and upload_release anyway13:58
dhellmannttx: good morning13:58
dhellmannttx: ack on adding Daviey13:59
dhellmannDaviey : thanks for volunteering to handle those kilo releases!13:59
Davieydhellmann: Thanks for having me :)14:00
dhellmannttx: it looks like https://review.openstack.org/#/c/264754 is failing grenade?14:02
dimsdhellmann : that's a known flaky test14:03
dimsdhellmann : that one means the vm when booted did not get an ip from dhcp14:03
dhellmanndims : is someone working on it? I've rechecked the patch14:03
dimsdhellmann : i just figured out the logstash query a few days ago. apparently it's a well known problem with no known fixes14:04
dimsdhellmann : typically happens when a vm was booted on a specific ip and then dhcp_release is called and then a new vm is booted. the dhcp_release did not clear the dhcp lease for some reason and no one knows why this happens14:05
* dhellmann reconsiders his chosen profession14:06
dhellmanndims : I just noticed the note about pep8 errors, I wonder if it's a new version of pep8?14:07
dhellmanndims : yeah, our tox.ini doesn't pin flake814:09
dhellmannttx: do you want to finish our conversation about whether to proceed with the automation?14:10
openstackgerritDoug Hellmann proposed openstack/releases: constrain flake8 using current global-requirements settings  https://review.openstack.org/26693214:12
dhellmanndims : ^^14:13
ttxdhellmann: I was doing a consistency check on release tags and I now have a question for you14:18
dims+2 dhellmann14:18
dhellmanndims : thanks14:18
dhellmannttx: fire when ready14:18
ttxdhellmann: we have 4 deliverables (out of 79) that are release:managed but not release:cycle*14:19
ttxshould those be considered exceptions ? Should we not have any rule there ? Should we deprecate the :managed concept anyway ?14:19
ttx(that would be openstack-docs-theme, openstack-doc-tools, pbr and pylockfile)14:20
ttxI think we'll soon deprecate the whole concept and handle all official projects14:21
ttxso maybe we should not restrict :managed to :cycle*14:22
dhellmannthe managed tag sort of flipped between "ttx or dhellmann does the work" and "project follows all of the rules"14:22
ttxyeah, a bit of overloading there14:23
dhellmannI'd be more comfortable taking on all managed projects if we can finish the automation work. But it's not actually that much work to do one now, so maybe we can push ahead with that even if we keep doing the tagging by hand14:23
* dhellmann fidgets on the fence14:23
ttxthe tag definition is mostly about quality14:24
ttxnot really "who will do the work"14:24
dhellmannthe other thing to consider is that right now being managed is opt-in, so we need a process for changing that to apply to all official projects14:24
dhellmannthat's what it was meant to be, but I think (at least in my head) it has several meanings14:25
ttxok, so I think... once we are ready to take more we'll reach out to unmanaged projects and check that they are all fine with being managed14:25
dhellmannyeah, I'm ok with those 4 exceptions remaining independent while we continue figuring out the automation issues and communicate with the other projects14:26
*** mriedem has joined #openstack-release14:26
ttxif a significant proportion refuses, we'll likely keep the tag to be able to tell which14:26
dhellmannright14:26
ttxif only one or two refuses, we might pressure them through the tc14:26
ttxif we have them all, we can remove the tag14:27
ttxand/or introduce new ones to communicate release process quality if we think that matters14:27
dhellmannyes, though we may want to do something to make clear that becoming an official project also implies having releases managed by this team14:27
ttxsure. We would add that to the new team process14:28
dhellmannwe could do that at the same time as removing the tag14:28
ttxonce we have all the existing ones signed up14:28
dhellmannright14:28
dhellmannin the time since yesterday's infra meeting, I think I've come to terms with the idea of just continuing to run the release scripts by hand14:28
dhellmannwith the new email automation, it's just one command, so the only "hard" part is hanging around and waiting for the release requests to merge14:29
dhellmannwhich just means I'll stop doing them late in the afternoon when zuul is really busy14:29
dhellmannttx, dims: what do you think?14:29
ttxLets think a bit more about it14:29
ttxdhellmann: what is the part that is painful to automate exactly ?14:30
dimsdhellmann : ack one command does make it easy14:30
ttxsigned tagging ?14:30
dhellmannthe hard part right now is actually getting the tools we've built into the images14:30
dhellmannthe CI images14:30
dhellmannwe can't install things from pip, so we need system packages for all our deps14:31
dimsdhellmann : so yes, i'll help with the day to day running commands / waiting etc :)14:31
dhellmannI haven't checked the others, but I'd be surprised if there was a .deb for reno yet14:31
ttxdhellmann: sure, but which tools14:31
dhellmannand reno is now a dep for the announce script14:31
ttxlet's take the process in steps14:31
dhellmannttx: well, all of them, right? we wanted the whole process handled by the CI servers14:31
ttxwe start with the releases post-merge process14:32
ttxwhich is supposed to generate a tag14:32
dhellmannrelease_from_yaml.sh runs some python code to run release.sh to generate the tag14:32
dimsdhellmann : i can ask Thomas Goirand (zigo) for help with .deb14:32
dhellmannI think release_from_yaml.sh just needs pyyaml, so we should be ok there14:32
dhellmanndims : ack, we'd need to get it into the canonical repos somehow, too14:33
ttxIIUC the painful part is that some of the jobs need access to secrets14:33
dimsdhellmann : ah i see14:33
ttxsecrets are used for signing14:33
ttxwe sign two things: the tags and the tarballs14:33
dhellmannthere are also launchpad credentials to manage, but yeah14:34
ttxwe already established that tarball signing could still be automated14:34
ttxsince it's not really our scripts14:34
ttxthat leaves two parts: tagging and announcing14:34
dhellmannright, that's happening as part of a related blueprint that infra is doing anyway14:34
ttxtagging happens before, announcing after the tarball signing part14:34
ttxat least that would be best that way14:35
dhellmannyes14:35
ttxwe could trigger the announce job from the tag post-job14:36
dhellmannthat's not the order it happens now, but we wanted to fix that14:36
ttxthat's a bit out of sequence since there is a race with tarball publication14:36
* dhellmann looks at what args the announce needs14:36
dhellmannannounce.sh takes the repository directory and the version number14:37
ttxwe could also have a specific jenkins job that reacts to the tarball publication but would still run on an unprividleged node14:37
ttxso options for announcements are:14:37
ttx1/ manual announce, watching manually for tarball to be published by automation14:38
ttx2/ automatic announce even before the tarball is published14:38
ttx3/ automatic announce from the tarball publication job, on the privileged node (with our tooling in project-config)14:39
ttx4/ automatic announce from some separate unprivileged job that watches tarball creation14:39
ttxwe ruled 3 out as not agile enough14:39
ttx2 introduces a race and we can't post the characteristics of the tarball in the announcement14:39
dhellmannI'm not sure 2 would work, based on the way that script works today -- it needs the tag in place to compute the differences14:40
ttxthat leaves 1 and 414:40
ttx(-for the announce part)14:40
ttxNow let's take the tagging problem14:40
ttxwe want tagging to happen automatically when the openstack/releases change merges14:40
ttxbut we want signed tags too14:41
dhellmannright14:41
ttxsigned tags mean priviledged nodes, or precomputed signatures14:41
ttxi.e. include the signature in the request and somehow just apply it within the tag14:42
dhellmannassuming infra works out key management, the tagging part isn't a problem from the perspective of moving the tools into the project-config repo14:42
ttxwe'd basically work around gerrit not supporting tag reviews14:42
dhellmannwe might need some changes, but they shouldn't be major14:42
ttxdhellmann: why?14:42
ttxbecause you don't expect that many changes there ?14:42
dhellmannright: we need to move the things that are console scripts to regular python scripts that can be run without an installation step, and we need the bash scripts to not build virtualenvs but assume all the needed packages are installed system-wide14:43
ttxdhellmann: hmm, ok.14:43
ttxso for the tagging, solutions are:14:44
ttx1/ manual tagging once the releases change merges14:44
ttx3/ automatic tagging from a privileged node14:44
ttx5/ some precomputation of the tag being present in the change and applied on a unprivileged node14:45
ttxthis 3 being less painful that the other 314:45
ttxthan*14:45
dhellmannat the summit we rejected 5 as unnecessarily complex, given that we need secrets for signing tarballs anyway14:45
ttxlets call the first set of solutions A (like announce) and the second set T (like tagging)14:46
dhellmannand right, the tools for introducing the tags are less complex so I think moving those won't be as bad as moving the announce scripts14:46
ttxWa are at T1 A1 right now14:46
ttxWe should shoot for T3 first14:46
ttx(and still do A1)14:47
ttxwait for tarball signature/upload to be completed on infra side14:47
ttxthen consider moving from A1 to either A3 or A314:47
openstackgerritGraham Hayes proposed openstack/releases: Release designate 1.0.1  https://review.openstack.org/26695214:47
ttxA4 or A3 I mean14:47
dhellmannok, that gives us an incremental improvement, I suppose14:48
ttxso... T1A1 -> T3A1 -> maybe T3A3 or T3A514:48
dhellmannI wonder if we could have A4 using a job on the releases repo, so we would know what version info we're working with14:48
ttxit's also easier to parallelize with the work on tarball signature14:48
ttxerr T3A4 you are right14:49
ttxA4 would need to be triggered by either the tarball upload job completion, or detecting the presence of the file14:50
dhellmannright, I was thinking it would be triggered when the release change merged and then it would wait for the tarball to be present before continuing14:50
ttxoh.14:50
dhellmannthat way it has the patch from the releases repo to tell it what was released14:50
ttxsounds a bit brittle, we would have to check that all steps completed.14:51
dhellmannit might need to watch for a bunch of releases, like when dims does the oslo weeklys14:51
ttxBut then we need to keep an eye on release job failures anyway14:51
dhellmannyeah, that's a good point, we need some good way to track the job outcomes to make sure none fail14:51
dhellmannotoh, we could write a job like I describe for A4 today14:52
ttxanyway, i would keep on doing A1 until T is automated14:52
dhellmannit can just run in a tox environment, so we wouldn't need much special tooling in infra at all14:52
ttxright14:53
ttxthe trick is to separate what needs to run on the privileged node (not that much) and what doesn't14:53
dhellmannok, I'll go back and look at the infra spec and see if it needs to be changed to reflect this change in plan14:53
ttxok14:54
dhellmannI'll also see if I can build a release_from_yaml.sh with fewer dependencies14:54
ttxand I enter a meeting tunnel14:54
ttxbe back tomorrow :)14:54
dhellmannhave fun? :-)14:54
openstackgerritGraham Hayes proposed openstack/releases: Release designate 2.0.0.0b2  https://review.openstack.org/26696315:05
openstackgerritDavanum Srinivas (dims) proposed openstack/releases: Oslo Releases for week of Jan 11, 2016  https://review.openstack.org/26567315:06
*** devananda has quit IRC15:59
*** devananda has joined #openstack-release16:02
*** sigmavirus24_awa is now known as sigmavirus2416:07
mugsiettx: you around? - getting an error for my stable/liberty release patch, and I can't see what I am missing16:09
mugsiehttp://logs.openstack.org/52/266952/1/check/gate-releases-tox-validate/b35f77d/console.html are the logs16:09
mugsiereview: https://review.openstack.org/26695216:09
ttxmugsie: looking16:10
mugsiety16:10
ttxmugsie: it's missing a send-announcements-to field. see http://lists.openstack.org/pipermail/openstack-dev/2016-January/083749.html16:12
ttxsee for example http://git.openstack.org/cgit/openstack/releases/tree/deliverables/mitaka/designate.yaml16:13
mugsieyeah, saw the field, missed the email, and assumed it was an optional field16:13
mugsiethanks, will update it16:13
ttxI'm surprised that it's not optional, since we have a default value16:14
ttxbut yeah, that is probably what the error is about16:14
openstackgerritSteve Martinelli proposed openstack/releases: release keystone libraries for mitaka  https://review.openstack.org/26662816:14
stevemardhellmann: dims ^ requirements patch is up as well, and it should be passing jenkins16:15
openstackgerritGraham Hayes proposed openstack/releases: Release designate 1.0.1  https://review.openstack.org/26695216:16
SergeyLukjanovttx, dhellmann, hi, we've found out that we created a new repo (sahara-scenario) incorrectly and we need to have actually sahara-tests repo with git history, do you think it'll be okay to request new repo and move old one to attic enventually?16:17
SergeyLukjanov(shame me, was travelling too much last month and missed it)16:17
*** dims_ has joined #openstack-release16:18
ttxSergeyLukjanov: you should first check with infra on the feasibility... it doesn't trigger that many alarms from where I stand16:20
SergeyLukjanovyeah, probably, it'll be easier to rename repo and re-push with --force16:21
SergeyLukjanovttx, thx16:21
*** dims has quit IRC16:21
dims_stevemar : will look in a little bit, gotta run an errand16:24
stevemardims_: cool cool16:28
*** dtantsur is now known as dtantsur|afk16:54
dims_stevemar : +2 hoping dhellmann will have time to cut it else i can do it later this evening/night16:56
stevemardims_: cool cool16:57
stevemardims_: thanks for looking at it :)16:57
dhellmannstevemar, dims_ : I'm in a meeting, but will look at it right afterwards16:57
stevemardhellmann: dims_ y'all are the best :)16:57
dims_:)16:58
*** amotoki has quit IRC17:11
dhellmanndims_ , stevemar : starting those releases now17:12
*** fesp has joined #openstack-release17:32
*** fesp has quit IRC17:34
openstackgerritMerged openstack/releases: constrain flake8 using current global-requirements settings  https://review.openstack.org/26693217:43
openstackgerritMerged openstack/releases: Release designate 1.0.1  https://review.openstack.org/26695217:52
*** dougwig has quit IRC18:08
*** lane_kong has quit IRC18:08
dhellmannmugsie: hey, the release announcement for designate failed because there's no README.rst file: http://paste.openstack.org/show/483803/18:21
mugsiedhellmann: I thought we had a readme ...18:22
dhellmannyou have a README.md18:22
mugsieoh. its in markdown18:22
mugsieOK, so we should move that to rst then?18:22
dhellmannyes, please18:23
dhellmannthe announce script looks for some links in a specific format, too, so check some of the other projects to see how they do things like link to the bug tracker18:23
*** LouisF has joined #openstack-release18:24
mugsieack18:24
*** dougwig has joined #openstack-release18:25
sdaguedoes anyone know the minimum tox required for constraints to work?18:25
mugsiedhellmann: I just checked nova and cinder and they are both completely different18:26
dhellmannmugsie: have a look at one of the oslo libs, I made sure those were all right18:26
*** lane_kong has joined #openstack-release18:26
dhellmannmugsie : you want a block like this somewhere: http://paste.openstack.org/show/483805/18:27
dhellmannsdague : tox shouldn't matter, but pip will18:27
mugsieah, ok. will add that now18:27
sdaguedhellmann: well I have pip 7.1.218:28
sdaguebut tox -e py27-constraints doesn't work18:28
dhellmannsdague : what's not working, I can try to reproduce18:28
sdaguegit clone nova18:28
sdaguetox -e py27-constraints18:28
sdagueexplode18:28
dhellmannok, running that now18:29
sdaguehttp://paste.openstack.org/show/483806/18:29
lifelesssdague: I suspect you've found a limitation in older tox that we didn't test far enough back to find18:29
lifelesssdague: sdague did you try a current tox?18:29
sdagueright, so that was the question. I have 1.9.1, the tox.ini says min tox is 1.818:29
sdagueI have not yet, I was asking the question what the minimum is18:30
lifelesssdague: given when we developed it, perhaps try a 2.x ?18:30
lifelesssdague: I don't know the actual minimum, except via trial and error18:30
*** dims_ has quit IRC18:30
sdagueok, I guess I assumed that would have been done as part of the effort, because local run is basically the blocker for nova now18:31
lifelesssdague: I don't think we actually had 'test with tox older than default' as an identified work item18:31
lifelesssdague: sorry18:31
*** dims has joined #openstack-release18:32
sdaguelifeless: it seems ironic that the effort working on constraints wouldn't consider the [tox]18:32
sdagueminversion = 1.818:32
sdague bit :)18:32
lifelesssdague: a little18:34
lifelesssdague: OTOH it is one of the things the jenkins slaves standardise on updating upfront18:34
sdagueright, but this is a user callable target18:35
sdaguethis isn't just about the gate, it's about local dev env acting like the gate18:35
lifelesssdague: I've already admitted error, I feel like you're flogging the point18:35
sdague2.0 seems to have gotten past the old error18:35
lifelessgreat18:35
LouisFi want to get networking-sfc released to mitaka, do i need to add networking-sfc.yaml to deliverables/mitaka?18:38
lifelessLouisF: yes18:38
dhellmannLouisF : there are some instructions here: http://docs.openstack.org/releases/instructions.html#requesting-a-release have you had a chance to look at those?18:39
LouisFyes looked at those, just verifying that is correct procedure18:39
dhellmannok, yes, assuming networking-sfc is a new deliverable and not related to something that already exists, you would create a new file18:40
LouisFthe git commit hash used in the yaml is obtained from a final commit to networking-sfc?18:41
dhellmannLouisF : yes18:42
dhellmannLouisF : make sure to use the merge commit sha, if there is a merge commit18:42
LouisFok thanks, when should this completed to be in M2?18:43
*** ig0r_ has joined #openstack-release18:43
dhellmannLouisF : the schedule is at http://docs.openstack.org/releases/schedules/mitaka.html -- the M2 deadline is Jan 2218:43
LouisFdhellmann: thanks18:44
dhellmannmugsie : looking at the beta release for designate, I'm a little confused. According to http://governance.openstack.org/reference/projects/designate.html the dashboard is a separate deliverable from designate itself, and has different release tags. Is that right?18:46
dhellmannLouisF : np, let me know if you run into any other questions18:46
mugsiedhellmann: it is separate now?18:46
dhellmannmugsie : yet the release request includes both items together18:46
dhellmannmugsie : do designate and designate-dashboard share a launchpad page?18:47
dhellmannand more importantly, bug tracker18:47
mugsieyes18:47
dhellmannok18:47
mugsiethey were combined before18:47
mugsie(we did m1 as a combined deliverable)18:48
dhellmannso that's ok for the release repo then18:48
dhellmannI'm not sure about the tags, though. it would be better if they reflected the fact that they use the same release model18:48
mugsieyeah18:48
dhellmannyeah, I'm just confused because the 2 sets of instructions don't say the same thing -- governance thinks they are different, release thinks they are together18:48
mugsieAs far as I was concered -  they were the same thing18:49
dhellmannso all of the release tags apply the same? cycle-with-milestones and has-stable-branches?18:49
dhellmannmugsie : maybe you can submit the governance repo patch to straighten that out?18:50
mugsieyeah. thats how we have been operating. I will make a change to the projects.yaml file later on today18:50
dhellmannmugsie : ok, great, thanks18:51
mugsienp - thanks for letting me know18:51
dhellmannmugsie : ok, I commented on the release request for the rest of the release team to know we're waiting18:52
LouisFdhellmann: this is a new deliverable - subproject of neutron18:53
lifelesssdague: did it finish successfully, or bail ?18:53
dhellmannLouisF : ok, that's what I thought based on the name, I just wasn't sure if it had ever been released before18:53
sdagueit looks successful18:53
LouisFdhellmann: ok so this is correct procedure?18:53
lifelesssdague: ok, so do we care about bisecting for the min tox, or just say 2.0 is the min everywhere?18:54
dhellmannLouisF : yes, please create a new file following those instructions18:54
sdagueI had to pull a second tree, my primary tree is in the middle of a chunk of work, so tests aren't passing there for other reasons18:54
LouisFdhellmann: thanks again18:54
sdague2.0 seems fine, I was on a 1.9.2 already, I don't even know how many bumps there are in between18:54
lifelesssdague: ok, i'll submit a change to cookie-cutter18:55
lifelesssdague: I presume you'll put up a nova patch? Or would you like me to?18:56
sdagueyeh, I've got the nova patch up already18:57
sdaguethe nova team is also leaning heavily on just using this for everything instead of making it a dev option to get wrong18:57
lifelesscool18:58
sdagueI just proposed https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:tox_constraints to get us over there19:00
*** mriedem is now known as mriedem_meeting19:02
lifelesssdague: yeah, so I'm concerned about that without zuul/jjb glue being done19:03
lifelesssdague: I don't know if you saw my replies to your question about doing htat19:03
sdaguelifeless: right, I'm not sure I understand why that would be different there19:03
sdagueI guess there is a set of details that I am missing19:03
lifelesssdague: have a look at jenkins/scripts/run-tox.sh19:05
lifelesssdague: and, let me find the othe rbit19:05
lifelesssdague: ah yes - zuul-git-prep-upper-constraints19:05
lifelesssdague: the constraints file is from a different repo19:06
sdaguerun-tox.sh always exports the upper constraints file19:06
lifelesssdague: yup, which won't exist unless you've run zuul-git-prep-upper-constraints in the job definition19:06
lifelesssdague: so ignoring the potential dev confusion - which honestly I don't care either way on19:07
sdagueok, so where do I get agreement for adding this to the other jobs?19:07
lifelesssdague: making sure it actually works is the bit that concerns me19:07
sdagueright, sure, that's fair19:08
sdaguesome set of testing will happen with these patches19:08
lifelesssdague: infra I suspect are the best human proxies for figuring it out19:08
mugsiedhellmann: proposed https://review.openstack.org/26710519:09
sdaguefungi: is pinging there, I'll context switch to it19:09
lifelesssdague: yah19:09
dhellmannmugsie : thanks19:14
fungisdague: yeah, sorry didn't realize it was being discussed here too19:17
fungiunfortunately i don't have bandwidth to discuss it at the moment19:18
*** mriedem_meeting is now known as mriedem19:52
*** dims has quit IRC20:18
*** dims has joined #openstack-release20:18
openstackgerritDoug Hellmann proposed openstack-infra/release-tools: refactor list_deliverable_changes.py prior to move to project-config  https://review.openstack.org/26716120:49
openstackgerritDoug Hellmann proposed openstack-infra/release-tools: refactor script for commenting on launchpad bugs prior to move to project-config  https://review.openstack.org/26716220:49
openstackgerritDoug Hellmann proposed openstack-infra/release-tools: default to sending mail directly via lists.openstack.org  https://review.openstack.org/26716620:55
dhellmanndims : it would be good to test a release using these changes ^^ (though maybe not the oslo megapack release)20:57
openstackgerritgordon chung proposed openstack/releases: ceilometerclient 2.2.1  https://review.openstack.org/26716820:57
dimsdhellmann : right, will review those today20:57
dhellmanndims : great, I'd rather not merge them until we've done a practical test20:58
dimsdhellmann : good point20:58
*** ig0r_ has quit IRC21:14
*** ig0r_ has joined #openstack-release21:23
*** ig0r_ has quit IRC21:31
*** ig0r_ has joined #openstack-release21:45
*** ig0r_ has quit IRC21:45
openstackgerritMonty Taylor proposed openstack/releases: Release os-client-config 0.14.1  https://review.openstack.org/26719622:09
*** sigmavirus24 is now known as sigmavirus24_awa22:55
*** mriedem is now known as mriedem_away23:00
*** amotoki has joined #openstack-release23:28
*** gordc has quit IRC23:29
*** topol has quit IRC23:34
*** LouisF has quit IRC23:36
*** topol_ has joined #openstack-release23:37
*** topol_ is now known as Guest5713523:37
*** amotoki has quit IRC23:52
*** amotoki has joined #openstack-release23:52
*** amotoki has quit IRC23:53

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