rjones (Sun, 17 Jun 2018 16:27:07 GMT):
amundson

rjones (Sun, 17 Jun 2018 16:27:18 GMT):
Has left the channel.

honeyjills (Tue, 19 Jun 2018 09:10:54 GMT):
Has joined the channel.

tungdt_socoboy (Tue, 19 Jun 2018 09:34:46 GMT):
Has joined the channel.

rootDistress (Wed, 27 Jun 2018 07:24:19 GMT):
Has joined the channel.

formax (Mon, 09 Jul 2018 19:08:44 GMT):
Has joined the channel.

LeonardoCarvalho (Fri, 17 Aug 2018 00:22:02 GMT):
Has joined the channel.

benoit.razet (Fri, 17 Aug 2018 01:12:05 GMT):
Has joined the channel.

RealDeanZhao (Fri, 17 Aug 2018 02:05:09 GMT):
Has joined the channel.

rkrish82 (Fri, 17 Aug 2018 03:03:09 GMT):
Has joined the channel.

jsmitchell (Fri, 17 Aug 2018 03:24:26 GMT):
Has joined the channel.

zac (Fri, 17 Aug 2018 03:50:47 GMT):
Has joined the channel.

kelly_ (Fri, 17 Aug 2018 15:10:27 GMT):
Has joined the channel.

danintel (Fri, 17 Aug 2018 16:13:18 GMT):
Has joined the channel.

rberg2 (Fri, 17 Aug 2018 16:13:55 GMT):
Has joined the channel.

Dan (Fri, 17 Aug 2018 16:14:23 GMT):
Has joined the channel.

Dan (Fri, 17 Aug 2018 16:14:33 GMT):
Is this where we want to talk about 1.1 release?

TomBarnes (Fri, 17 Aug 2018 16:14:48 GMT):
Has joined the channel.

TomBarnes (Fri, 17 Aug 2018 16:15:06 GMT):
looks like a good place to me

mfford (Fri, 17 Aug 2018 18:30:25 GMT):
Has joined the channel.

agunde (Fri, 17 Aug 2018 19:00:07 GMT):
Has joined the channel.

Gabe (Fri, 17 Aug 2018 20:26:13 GMT):
Has joined the channel.

Gabe (Fri, 17 Aug 2018 20:26:59 GMT):
Hey everyone, release 1.1 any updates, timelines, features?

Gabe (Fri, 17 Aug 2018 20:27:28 GMT):
Also is this where we talk about SDKs? Interested in maturity of Java SDK

mfford (Fri, 17 Aug 2018 20:29:11 GMT):
#sawtooth-sdk-dev

pschwarz (Fri, 17 Aug 2018 22:05:23 GMT):
Has joined the channel.

Gabe (Fri, 17 Aug 2018 23:10:28 GMT):
Thank you

amundson (Mon, 20 Aug 2018 18:39:29 GMT):
we probably want a branch point for 1.1 branch somewhere around 0edde5778c647ffc9f424297e59d6ad14cb2e98d

amundson (Mon, 20 Aug 2018 18:39:29 GMT):
we probably want a branch point for sawtooht-core 1.1 branch somewhere around 0edde5778c647ffc9f424297e59d6ad14cb2e98d

amundson (Mon, 20 Aug 2018 18:39:29 GMT):
we probably want a branch point for sawtooth-core 1.1 branch somewhere around 0edde5778c647ffc9f424297e59d6ad14cb2e98d

amundson (Mon, 20 Aug 2018 18:41:44 GMT):
maybe a little ahead of that, 4814be165df4973c65589deab75f41602202b4fa, to pick up some doc commits. then everything else we want as backports (poet removal for example)

amundson (Mon, 20 Aug 2018 18:43:08 GMT):
@Gabe yes, this is a good place to talk about any release stuff

amundson (Mon, 20 Aug 2018 18:43:57 GMT):
@boydjohnson ^ does that make sense to you?

boydjohnson (Mon, 20 Aug 2018 18:43:58 GMT):
Has joined the channel.

kirkwood (Tue, 21 Aug 2018 04:39:01 GMT):
Has joined the channel.

Dan (Wed, 22 Aug 2018 13:27:24 GMT):
even one further looks safe c79b34318396ac2ab0023009472ba50978530752 But only @boydjohnson can say for sure.

achenette (Wed, 22 Aug 2018 19:26:52 GMT):
Has joined the channel.

boydjohnson (Thu, 23 Aug 2018 12:40:37 GMT):
`4814be` seems conservative, but conservative is probably good, since we can always backport later fixes. Commits that would be nice to backport are the commits added in `d864b2f59` and `4c80898d7`.

alchmeina (Thu, 23 Aug 2018 14:18:03 GMT):
Has joined the channel.

Dan (Thu, 23 Aug 2018 14:56:14 GMT):
I'd rather be aggressive .. backports seem like they take 10x longer than getting them in initially.

boydjohnson (Thu, 23 Aug 2018 15:35:30 GMT):
I'll look later today for an aggressive option.

Dan (Fri, 24 Aug 2018 18:17:03 GMT):
Don't look too hard though ;) I'll channel Tom and say conservative is good. I just meant if you were on the fence for the two you listed I'd nudge you over there. :) If we branch before Monday it's good timing to start an LR7 on the first candidate build.

TomBarnes (Sat, 25 Aug 2018 01:14:46 GMT):
Can I get some help in confirming that the f0llowing list contains all of the current Rust run-time dependencies for Sawtooth-core, sawtooth-poet, and sawtooth-raft?

TomBarnes (Sat, 25 Aug 2018 01:17:08 GMT):

Clipboard - August 24, 2018 6:17 PM

TomBarnes (Sat, 25 Aug 2018 01:17:38 GMT):
Can I get some help in confirming that the following list contains all of the current Python run-time dependencies for sawtooth-core, sawtooth-poet, and sawtooth-raft?

TomBarnes (Sat, 25 Aug 2018 01:17:55 GMT):

Clipboard - August 24, 2018 6:17 PM

TomBarnes (Sat, 25 Aug 2018 01:18:19 GMT):
Are we still using lmdb (py-lmdb) now that we've moved to Rust? Are there other Python packages still called out in setup.py files that are no longer being used? thew py-lmdb project no longer has a maintainer, so its probably not a good component to be using in the long term.

TomBarnes (Sat, 25 Aug 2018 01:18:19 GMT):
Are we still using lmdb (py-lmdb) now that we've moved to Rust? The py-lmdb project no longer has a maintainer, so its probably not a good component to be using in the long term.

TomBarnes (Sat, 25 Aug 2018 01:18:57 GMT):
Are there other Python packages still called out in setup.py files that are no longer being used?

boydjohnson (Mon, 27 Aug 2018 15:15:10 GMT):
`4f5bd10a4` would be a good aggressive option. The block manager commits before it don't use the block manager in the actual validator.

amundson (Mon, 27 Aug 2018 16:14:17 GMT):
We don't really want an aggressive option - I believe Adam selected that initial commit based on a bunch of testing that we have already done at that specific point. That's attractive if we want a release in September.

amundson (Mon, 27 Aug 2018 16:16:32 GMT):
@Dan ^

Dan (Mon, 27 Aug 2018 16:17:32 GMT):
That commit comes up as July 31 and I know we've had LR7 success all month.

amundson (Mon, 27 Aug 2018 16:17:35 GMT):
My preference is to go with Adam's suggestion and then do backports that we feel are super important and/or won't cause stability issues that cause a longer testing cycle.

Dan (Mon, 27 Aug 2018 16:18:09 GMT):
If there's some specific risk like there was cache debugging subsequent to that then I'm easily persuaded to the more conservative path.

amundson (Mon, 27 Aug 2018 16:20:00 GMT):
Unfortunately, Adam is on vacation and he made that initial recommendation and is probably in the best position to describe why he picked it.

Dan (Mon, 27 Aug 2018 19:24:49 GMT):
Well I guess we can pick the conservative option and play backport or we can roll the dice on the aggressive commit and fall back to the conservative if we have instability. I'm in favor of including block manager as it alleviated race conditions. So I feel like conservative isn't necessarily more stable.

amundson (Mon, 27 Aug 2018 19:30:20 GMT):
@Dan Are you just advocating for taking current master then?

Dan (Mon, 27 Aug 2018 19:32:04 GMT):
I was leaning towards commit 4f5bd10a4 as the aggressive commit. I think that's still about 3 weeks back in the history.

Dan (Mon, 27 Aug 2018 19:32:19 GMT):
I know we've had stable LR7 runs since that went in.

TomBarnes (Tue, 28 Aug 2018 16:15:43 GMT):
When we choose the sawtooth-core 1.1 branch, I think we will also want to choose the sawtooth-poet and sawtooth-raft branch so that all can be tested together.

Dan (Tue, 28 Aug 2018 16:16:26 GMT):
@pschwarz how stable is BlockManager at that point? I believe there were some fixes in the last couple weeks. Would we want to grab that commit `4f5bd10a4` and then backport other BlockManager commits. Or is it so not stable at 4f5bd10a4 that we are better taking one of the earlier suggested commits and not including BlockManager at all?

pschwarz (Tue, 28 Aug 2018 17:18:40 GMT):
Could you link to those commits? I couldn't tell you what's in them by hash. I'm not _that_ good

amundson (Tue, 28 Aug 2018 18:10:56 GMT):
@TomBarnes probably no need to branch poet or raft yet. the reason for branching core is that master will become 1.2

amundson (Tue, 28 Aug 2018 18:12:03 GMT):
we probably a stable pre-psefree poet branch at some point, but probably not necessary yet

amundson (Tue, 28 Aug 2018 18:12:27 GMT):
no plans to do multiple lines of development on raft, AFAIK, so no branching required there

TomBarnes (Wed, 29 Aug 2018 15:24:45 GMT):
@amundson so then we run LR tests with the 1.1 branch of sawtooth_core and the head of sawtooth-poet and sawtooth-raft?

Dan (Wed, 29 Aug 2018 17:19:35 GMT):
@pschwarz that commit is actually removing the java sdk, but I gather from @boydjohnson that it is the commit after blockstore is enabled https://github.com/hyperledger/sawtooth-core/pull/1734 Probably best to just look at git log. Besides 4f5bd10a4 as the aggressive commit, other more conservative commits were listed here:https://chat.hyperledger.org/channel/sawtooth-release?msg=Ra7Pu6cFamcKqhJxR

amundson (Wed, 29 Aug 2018 20:11:14 GMT):
@TomBarnes yes, and in the short term we could start LR tests against main of all three and then switch over the core pieces to the branch when we get everyone on the same page for the branch point. those LR tests would be useful to inform the branch point decision too, though I don't want to wait too long before branching since we have a lot tasks to do after we branch.

TomBarnes (Wed, 29 Aug 2018 20:12:17 GMT):
@amundson i think we are already running LR tests on main - will provide updates this week.

amundson (Wed, 29 Aug 2018 20:13:15 GMT):
@TomBarnes ok, I would be interested to know what commit ids from core and the associated results

nubirstein (Thu, 30 Aug 2018 10:18:58 GMT):
Has joined the channel.

nubirstein (Thu, 30 Aug 2018 10:25:21 GMT):
Hi there. Do you know the reason why the HL Sawtooth has by default lmdb setting WRITEMAP set to True? It doesn't help much on OSX, when linking volume with blockchain content (no sufficient disk space error). On Ubuntu and WIndows works fine. If there is a good reason behind it, i'll understand, but if not, then i'm curious if it can be changed in next releases.

Dan (Thu, 30 Aug 2018 14:45:31 GMT):
@nubirstein that's a good question for #sawtooth this channel we are trying to focus on release process. In general though settings are designed for deployment on ubuntu. Many of us develop on other platforms but the deployment target is ubuntu.

pschwarz (Thu, 30 Aug 2018 21:26:02 GMT):
As far as what commits to test on, current master is pretty stable: https://github.com/hyperledger/sawtooth-core/commit/795699545bf285d817700d03e352d0ba72ef5679

Dan (Fri, 31 Aug 2018 01:18:28 GMT):
great so let's just branch there then

Dan (Fri, 31 Aug 2018 01:20:38 GMT):
@amundson @jsmitchell @adamludvik @agunde do you have any counter proposal? If not I'd say let's branch at that commit and start LR7 on Monday.

adamludvik (Fri, 31 Aug 2018 01:20:38 GMT):
Has joined the channel.

amundson (Fri, 31 Aug 2018 01:29:23 GMT):
@Dan I'd like to hear from a few others, specifically @adamludvik (who is on vacation until Tuesday). Once we have consensus, I'll create the branch and we will start churning through the tasks (creating repos, etc.). Monday is a holiday, so maybe better to target mid-week for having the first artifacts available in the new repos.

Dan (Fri, 31 Aug 2018 01:31:27 GMT):
Yeah he's in the @ list :). @pankajgoyal Please treat this coming Monday's nightly master as a 1.1 candidate. I think you'd be using that for LR7 anyway.

pankajgoyal (Fri, 31 Aug 2018 01:31:27 GMT):
Has joined the channel.

Dan (Fri, 31 Aug 2018 01:33:38 GMT):
@pankajgoyal

TomBarnes (Fri, 31 Aug 2018 01:36:22 GMT):
@amundson I'm still not sure I understand why we wont need a branch for raft and poet - will we simply test with poet/master and raft/master and continue to make changes to them?

Dan (Fri, 31 Aug 2018 01:37:37 GMT):
it seems we'd want to tag them or something

amundson (Fri, 31 Aug 2018 01:39:07 GMT):
we will tag them as necessary to stamp a version number on them when the time comes

amundson (Fri, 31 Aug 2018 01:41:34 GMT):
@TomBarnes the reason for branching is so we can maintain an additional version of the code. we can have multiple releases on master, and only need to branch when we are considering two separate releases being managed in parallel. so for example, in sawtooth-core's master, we have been working toward 1.1.x - thus, we have needed the 1-0 branch because in parallel we have been doing 1.0.x releases.

amundson (Fri, 31 Aug 2018 01:43:44 GMT):
when we consider raft, the same version/release will work against both sawtooth-core 1.1.x and 1.2.x; so no need to branch raft. if at some point we need to manage multiple releases of raft at the same time, we can create a branch.

amundson (Fri, 31 Aug 2018 01:48:49 GMT):
same for applications; almost all can support running on sawtooth core 1.0 or sawtooth core 1.1, so no reason to branch them even if we cut releases for them

amundson (Fri, 31 Aug 2018 01:53:45 GMT):
it seems likely we will want to branch poet once pse-free is active in master, simply because we might want to do releases of the "older" poet as it currently exists. I don't perceive that as important this week.

amundson (Fri, 31 Aug 2018 01:55:08 GMT):
this also presumes we can keep our PRs under control and don't wildly go merging in things that would interfere with our release timeline

TomBarnes (Fri, 31 Aug 2018 15:00:38 GMT):
@amundson Perhaps I'm asking for the wrong thing. What I want is to have a well defined instance of Raft to test against, and when the release goes out be able to identify which instances were tested together. So maybe that's not a branch - is it a version number? How will we identify which versions of the various component of a 1.1 release were tested and verified to work together?

rbuysse (Fri, 31 Aug 2018 15:48:50 GMT):
Has joined the channel.

amundson (Fri, 31 Aug 2018 16:06:28 GMT):
@TomBarnes early next week, we plan to dump builds of all the various pieces into an apt repository - will that work for your purposes? we can update that on whatever schedule works best for our testing.

TomBarnes (Fri, 31 Aug 2018 16:10:53 GMT):
yes - that works perfectly

TomBarnes (Fri, 31 Aug 2018 16:10:53 GMT):
@amundson yes - that works perfectly

TomBarnes (Fri, 31 Aug 2018 16:10:53 GMT):
@amundson yes - that works perfectly - thanks

sureshtedla (Fri, 31 Aug 2018 17:32:56 GMT):
Has joined the channel.

Dan (Fri, 31 Aug 2018 20:00:46 GMT):
iirc we tag the commit and the build grabs the tag from git and sets the version string in the build artifact using that tag string.

zZz (Mon, 03 Sep 2018 08:14:46 GMT):
Has joined the channel.

adamludvik (Tue, 04 Sep 2018 16:36:46 GMT):
I am up to speed on this discussion, will give my two cents shortly.

adamludvik (Tue, 04 Sep 2018 17:01:21 GMT):
@Dan @amundson @jsmitchell @agunde: I suggested using 0edde5778c647ffc9f424297e59d6ad14cb2e98d because it includes the new consensus api changes and is the commit that @pschwarz , @boydjohnson, and myself have done the most long-running testing with. I am fine with jumping ahead to include doc changes and the separation of the PoET repo. I am less comfortable recommending the release of the subsequent changes to integrate the block manager and rewrite the block validator in Rust. There is a known performance issue with these changes that we have been investigating and that should be resolved before including these changes in a release. I would like to include these changes in a 1.1.2 or 1.2 release once the issue has been resolved.

adamludvik (Tue, 04 Sep 2018 17:01:21 GMT):
@Dan @amundson @jsmitchell @agunde: I suggested using 0edde5778c647ffc9f424297e59d6ad14cb2e98d because it includes the new consensus api changes and is the commit that @peterschwarz, @boydjohnson, and myself have done the most long-running testing with. I am fine with jumping ahead to include doc changes and the separation of the PoET repo. I am less comfortable recommending the release of the subsequent changes to integrate the block manager and rewrite the block validator in Rust. There is a known performance issue with these changes that we have been investigating and that should be resolved before including these changes in a release. I would like to include these changes in a 1.1.2 or 1.2 release once the issue has been resolved.

adamludvik (Tue, 04 Sep 2018 17:02:23 GMT):
Has anyone gotten back to @TomBarnes wrt current python and rust dependencies?

amundson (Tue, 04 Sep 2018 18:07:13 GMT):
fwiw, 1.2 is likely in the december timeframe. we can do 1.1.x point releases would be driven by our testing turnaround time

amundson (Tue, 04 Sep 2018 19:22:42 GMT):
I am (and have been) fine with Adam’s proposed branch point. @Dan and others, can we agree on that as an initial branch and have further discussion as backport proposals? I can prepare some backport branches (docs, poet, etc.).

amundson (Tue, 04 Sep 2018 19:24:52 GMT):
We have a lot of things held up on this from a build perspective so it would be good if I can create the branch today so tomorrow we can start on the next todo.

amundson (Tue, 04 Sep 2018 19:26:35 GMT):
We could even pull in block manager, etc. later if we want to continue that as a backport discussion

TomBarnes (Tue, 04 Sep 2018 19:58:01 GMT):
@adamludvik I havent heard back since posting my original request. Let me refresh that request here - I'l do it today.

Dan (Tue, 04 Sep 2018 22:04:49 GMT):
@adamludvik I see several consensus engine updates after `0edde5778c` @pschwarz could thumbs up/down `0aa154c7e23bd887c7496d54806e78b929feb4d9` and `4c80898d7ab045d18c414dd28e40067fdc710ad6` which seem to impact back pressure. There's a couple block store commits @boydjohnson could thumbs up/down (`c2c2f8f544ac50fb38edc7c78bce02e69472fbf2`, `a7a1bf55cd7a2b0995d2ed7fc36fe081c5e23145`). If those are in the clear there's lots more commits (build system, docs, etc.) we could fast forward through.. then I start seeing blockmanager commits around here `3f3c469c550c65841fbd80b966ca33eaebd66452`

adamludvik (Tue, 04 Sep 2018 22:43:13 GMT):
@Dan `0edde5778c` is the commit I am most confident in from a performance and stability perspective. If the goal is to get as far forward as possible without getting ensnared in the issue I mentioned above, I think we could safely go as far as `8440e8702afdec4d538d928d14674b392d17994a`, though I don't know whether that commit has been run in a long running environment before. This would include a number of nice things such as: - doc updates - removal of poet - workload debs - a couple consensus api fixes not used by poet

adamludvik (Tue, 04 Sep 2018 22:45:27 GMT):
Looking through the commit messages between those two though, I don't see anything that should cause any big problems.

adamludvik (Tue, 04 Sep 2018 22:45:27 GMT):
Looking through the commit messages between those two though, I don't see anything that could cause any big problems.

adamludvik (Tue, 04 Sep 2018 22:45:59 GMT):
Is that a more agreeable commit to branch from?

Dan (Tue, 04 Sep 2018 22:55:28 GMT):
yeah that would include way more goodness :)

amundson (Tue, 04 Sep 2018 23:59:33 GMT):
are we agreeing on 844 then?

TomBarnes (Wed, 05 Sep 2018 00:24:31 GMT):
@adamludvik here is the 3rd-party run-time dependency list for all modules installed by the sawtoooth debian package:

TomBarnes (Wed, 05 Sep 2018 00:24:49 GMT):

Clipboard - September 4, 2018 5:24 PM

TomBarnes (Wed, 05 Sep 2018 00:25:16 GMT):
Here is the rust dependency list:

TomBarnes (Wed, 05 Sep 2018 00:35:46 GMT):

Clipboard - September 4, 2018 5:35 PM

TomBarnes (Wed, 05 Sep 2018 00:36:12 GMT):
These are for sawtooth-core, sawtooth-poet, and sawtooth-raft

Dan (Wed, 05 Sep 2018 13:49:15 GMT):
@amundson yes let's go with `8440e8702afdec4d538d928d14674b392d17994a` @agunde @jsmitchell @pschwarz plz chime in quick if you disagree.

adamludvik (Wed, 05 Sep 2018 15:22:29 GMT):
@TomBarnes Your python list looks correct. Your Rust list is missing clap and libc, and "sawtooth_sdk" is not a 3rd-party library.

TomBarnes (Wed, 05 Sep 2018 16:51:12 GMT):
@adamludvik thanks for reviewing Adam. I've got clap and libc - that was a cut a paste error on my part. and agreed Sawtooth-sdk should not be on that list.

TomBarnes (Wed, 05 Sep 2018 17:16:17 GMT):
@adamludvik are we still using python3-lmdb? I thought all of the LMDB interfaces moved to Rust. I ask because the Python LMDB adapter project is no longer being maintained, and it represents a security concern since without a maintainer, there is no way to get anything fixed if a vulnerability in that component is identified.

adamludvik (Wed, 05 Sep 2018 17:20:07 GMT):
Yes, we are still using python3-lmdb.

TomBarnes (Wed, 05 Sep 2018 17:24:22 GMT):
Pyhton LMDB adapter is not currently being maintained: https://github.com/dw/py-lmdb

TomBarnes (Wed, 05 Sep 2018 17:24:22 GMT):
@adamludvik Python LMDB adapter is not currently being maintained: https://github.com/dw/py-lmdb

amundson (Wed, 05 Sep 2018 17:42:58 GMT):
ok, we now have a sawtooth-core 1-1 branch

amundson (Wed, 05 Sep 2018 17:43:14 GMT):
master will soon become 1.2.x

Dan (Wed, 05 Sep 2018 18:25:51 GMT):
@amolk @pankajgoyal ^

amolk (Wed, 05 Sep 2018 18:25:52 GMT):
Has joined the channel.

pschwarz (Wed, 05 Sep 2018 19:39:22 GMT):
@TomBarnes there is still a bit of effort needed to remove python-lmdb completely

pschwarz (Wed, 05 Sep 2018 19:40:11 GMT):
And, if I recall correctly, it is used by PoET

TomBarnes (Wed, 05 Sep 2018 19:49:49 GMT):
@pschwarz Thanks. Do you think it will be removed by the time we get to Sawtooth 1.2 release in December? I will check on PoET 2 - I think it has eliminated dependency on Python access to LMDB.

pschwarz (Wed, 05 Sep 2018 19:52:21 GMT):
I don't think it's a big lift to get it out of there - we replaced one usage, but need to replace two more, which require a little bit more FFI work on our part

Dan (Wed, 05 Sep 2018 19:52:37 GMT):
PoET1 uses its own lmdb for managing key state (iirc)

pschwarz (Wed, 05 Sep 2018 19:52:45 GMT):
Yep

pschwarz (Wed, 05 Sep 2018 19:53:10 GMT):
Which might be Overkill, really

Dan (Wed, 05 Sep 2018 19:53:29 GMT):
That is the best kind of kill though.

pschwarz (Wed, 05 Sep 2018 19:53:47 GMT):
Sorry I missed the commit discussion. I'm out on vacation

Dan (Wed, 05 Sep 2018 19:54:10 GMT):
no worries. you can blame it all on ludvik now.

amundson (Wed, 05 Sep 2018 20:25:13 GMT):
master is now future 1.2.x

TomBarnes (Thu, 06 Sep 2018 00:27:35 GMT):
question about unit test coverage: are these unit test coverage reports still meaningful? https://build.sawtooth.me/job/Sawtooth-Hyperledger/job/sawtooth-core/job/master/lastSuccessfulBuild/artifact/coverage/html/index.html

TomBarnes (Thu, 06 Sep 2018 00:29:39 GMT):
...that is, are all of these unit tests still exercising active Sawtooth code (and not legacy Python code that's been replaced by Rust code)?

amundson (Thu, 06 Sep 2018 14:28:07 GMT):
@TomBarnes it is still meaningful for the python code (code gets removed from the repo when its been replaced)

TomBarnes (Thu, 06 Sep 2018 16:17:23 GMT):
@amundson doesn't seem to be limited to Python - i notice that a number of the tests exercise underlying Rust code via ffi. Trying to think about how to characterize that coverage.

TomBarnes (Thu, 06 Sep 2018 16:18:09 GMT):
@amundson ... and good to know that the tests are not executing dead code - thanks

amundson (Thu, 06 Sep 2018 17:15:02 GMT):
sure, the rust code is getting tested. but that tool is definitely not aware enough to report on it.

TomBarnes (Thu, 06 Sep 2018 17:15:13 GMT):
``` agreed ```

TomBarnes (Thu, 06 Sep 2018 17:23:58 GMT):
There are 398 pub rust functions. Only 71 pub unsafe (ffi) functions. So even if there were python tests for every pub unsafe function, the code coverage would not be great.

amundson (Thu, 06 Sep 2018 17:24:51 GMT):
functions call other functions though, so I'm not sure I follow that logic

TomBarnes (Thu, 06 Sep 2018 17:26:08 GMT):
agreed - when i get some time i'll see if I can improve my metric

amundson (Thu, 06 Sep 2018 17:26:22 GMT):
keep in mind the "unit tests" include running a validator with intkey smoke, so almost certainly the code coverage is high

TomBarnes (Thu, 06 Sep 2018 17:26:37 GMT):
good point

TomBarnes (Thu, 06 Sep 2018 18:06:48 GMT):
Here is the unit test coverage for the five Python files that expose Rust functionality.

TomBarnes (Thu, 06 Sep 2018 18:07:00 GMT):

Clipboard - September 6, 2018 11:06 AM

TomBarnes (Thu, 06 Sep 2018 18:07:44 GMT):
overall coverage is fairly good. coverage of chain and publisher interfaces is weak and could bear some improvement

TomBarnes (Thu, 06 Sep 2018 18:07:44 GMT):
overall coverage is fairly good. coverage of chain and publisher interfaces is weak and could bear some improvement. clearly even with integration tests, some of these interfaces are not getting touched.

TomBarnes (Thu, 06 Sep 2018 18:07:44 GMT):
@amundson Per table above, overall coverage of rust functions used by Python is fairly good. Coverage of chain and publisher interfaces is weak and could bear some improvement. Clearly even with integration tests, some of these interfaces are not getting touched.

Dan (Mon, 10 Sep 2018 20:48:39 GMT):
@rberg2 uh trying to put this into a question... uh what's a bumper? :)

rberg2 (Mon, 10 Sep 2018 20:49:19 GMT):
I vital component to any pinball game

rberg2 (Mon, 10 Sep 2018 20:49:27 GMT):
s/I/A/

Dan (Mon, 10 Sep 2018 20:49:28 GMT):
walked into that

Dan (Mon, 10 Sep 2018 20:49:39 GMT):
https://github.com/hyperledger/sawtooth-poet/pull/3/commits/ce3724e7fe0b98acf4d05e610093f7808197699a

rberg2 (Mon, 10 Sep 2018 20:50:21 GMT):
bumper is the code name for the release featuring sawtooth-core 1.1.

Dan (Mon, 10 Sep 2018 20:51:13 GMT):
I think I missed that meeting.

Dan (Mon, 10 Sep 2018 20:51:59 GMT):
I approved that PR.

rberg2 (Mon, 10 Sep 2018 20:54:29 GMT):
:thumbsup: I have this one up too, I had to a bit of work on the poet docker-compose file for 1.1. Its still building though. https://github.com/hyperledger/sawtooth-core/pull/1852

arsulegai (Tue, 11 Sep 2018 18:59:34 GMT):
Has joined the channel.

Dan (Wed, 12 Sep 2018 12:46:50 GMT):
@pankajgoyal @amolk were you able to start LR 7 for the candidate branch?

Dan (Wed, 12 Sep 2018 12:46:50 GMT):
@pankajgoyal @amolk were you able to start LR 7 for the candidate branch

pankajgoyal (Wed, 12 Sep 2018 13:50:52 GMT):
@Dan build.sawtooth.me is down. So we cannot pull the debs from there.

Dan (Wed, 12 Sep 2018 13:53:37 GMT):
yeah network outage problem there You should also be aware of repo.sawtooth.me/ubuntu/bumper/stable

pankajgoyal (Wed, 12 Sep 2018 13:57:50 GMT):
so,instead of pulling the debs from jenkins, the debs for release branch can be pulled from this repo?

Dan (Wed, 12 Sep 2018 13:59:07 GMT):
build.sawtooth.me is back online.

Dan (Wed, 12 Sep 2018 14:00:19 GMT):
And yeah the debs that we 'release' should be on the repo server that you access with the repo keys for apt. Intermediate builds / other artifacts will only be on the build server.

pankajgoyal (Wed, 12 Sep 2018 14:10:37 GMT):
what is the key for this apt repo?

pankajgoyal (Wed, 12 Sep 2018 15:21:10 GMT):
LR7 started with packages from repo.sawtooth.me/ubuntu/bumper/stable on AWS. You can see the grafana at http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&from=now-15m&to=now&var-DATASOURCE=metrics_lr7

pankajgoyal (Wed, 12 Sep 2018 15:22:10 GMT):
with 10TPS input (5 TPS intkey + 5 TPS smallbank)

Dan (Wed, 12 Sep 2018 15:57:38 GMT):
awesome!

rberg2 (Wed, 12 Sep 2018 19:43:24 GMT):
FYI the `bumper/stable` repo won't be populated until we release bumper (1.1) until then use `bumper/nightly` with the usual nightly key `44FC67F19B2466EA`

Dan (Wed, 12 Sep 2018 20:01:17 GMT):
I'm confused .. Looks like @pankajgoyal found bits in there @rberg2 .

Dan (Wed, 12 Sep 2018 20:01:17 GMT):
I'm confused .. Looks like @pankajgoyal found bits in there @rberg2.

rberg2 (Wed, 12 Sep 2018 21:16:23 GMT):
I should have mentioned that I brought that up with @pankajgoyal this morning.

Dan (Wed, 12 Sep 2018 21:23:55 GMT):
ok so is he running LR7 off of nightly then?

rberg2 (Wed, 12 Sep 2018 21:43:21 GMT):
yeah. I just double checked and there is no stable repo yet.

adamgering (Fri, 14 Sep 2018 19:29:13 GMT):
Has joined the channel.

amundson (Mon, 17 Sep 2018 16:39:23 GMT):
@Dan @amolk @pankajgoyal what's the latest word on your LR testing?

Dan (Mon, 17 Sep 2018 16:41:32 GMT):
hitting the url above the graphs look clean to me. I will defer to @pankajgoyal though to say if he's seeing anything in the error logs on those platforms or any other signs of `danger`.

amundson (Mon, 17 Sep 2018 16:45:31 GMT):
I see a lot of "No data points" in that URL. looks like the OS level collector (whatever it is called) isn't setup properly

adamludvik (Mon, 17 Sep 2018 16:51:17 GMT):
telegraf: https://www.influxdata.com/time-series-platform/telegraf/

adamludvik (Tue, 18 Sep 2018 15:57:05 GMT):
@Dan @pschwarz @ltseeley @amundson I would like to get this PR merged, so that the Raft repo is setup to do releases from: https://github.com/hyperledger/sawtooth-raft/pull/26 @rberg2 has pointed out that merging the PR would implicitly create a 0.1.0 "release". I think it makes sense to merge this PR now and have 0.1.0 be a "soft-release", meaning we don't do the normal release tasks like publishing debs to stable, publishing docs, etc., and have 0.1.1 be the first "hard-release". Does anyone have opinions on this or am I thinking about it wrong?

ltseeley (Tue, 18 Sep 2018 15:57:05 GMT):
Has joined the channel.

Dan (Tue, 18 Sep 2018 16:04:15 GMT):
I'm fine w/ merging and 'soft' release. I do think we need debs published from this repo/component associated with sawtooth 1.1.

adamludvik (Tue, 18 Sep 2018 16:14:43 GMT):
Yes to publishing with 1.1, that is the plan

amundson (Tue, 18 Sep 2018 16:15:55 GMT):
@adamludvik @rberg2 you have to tag to do a release. does this actually work without any tags?

amundson (Tue, 18 Sep 2018 16:17:00 GMT):
this is what I suggest: merge the PR, then create a v0.1.0 tag and then bump version to 0.1.1. this will make get_version operate properly and it is consistent with what we have done everywhere else.

rberg2 (Tue, 18 Sep 2018 16:17:43 GMT):
thats what I was getting at when I brought this stuff up with Adam.

rberg2 (Tue, 18 Sep 2018 16:19:07 GMT):
do we do the 0.1.0 tag now and release 0.1.1?

rberg2 (Tue, 18 Sep 2018 16:20:44 GMT):
that sounds like what Amundson is suggesting

adamludvik (Tue, 18 Sep 2018 16:21:46 GMT):
@amundson So we do the merge/0.1.0 tag, and a follow up PR to set the version to 0.1.1 now. That completes the 0.1.0 "soft-release". Later when we are ready to release 0.1.1 we do something similar?

amundson (Tue, 18 Sep 2018 16:27:23 GMT):
@adamludvik I would let @rberg2 or myself do the actual tag and increment commit. we tend to avoid PRs to make sure it's atomic and that requires convincing github temporarily to allow it.

adamludvik (Tue, 18 Sep 2018 16:28:11 GMT):
Gotcha. Is there anything blocking that from being done now, or any reason to wait?

amundson (Tue, 18 Sep 2018 16:28:30 GMT):
you _could_ merge in the commit, but if the history is non-linear then the commit-since-tag math is wack

amundson (Tue, 18 Sep 2018 16:28:51 GMT):
no reason I know of

adamludvik (Tue, 18 Sep 2018 16:30:30 GMT):
Alright, I think we should go ahead as soon as priorities allow.

Dan (Tue, 18 Sep 2018 16:37:30 GMT):
We had some discussion about a sawtooth 1.1 meta-package. What is that artifact (a deb? a repo?) and do we have clarity on what it contains? (sawtooth-core 1.1, sawtooth-raft 0.1.1, sawtooth-poet x.y.z, ...)

amundson (Tue, 18 Sep 2018 16:42:08 GMT):
at a "distribution level", the bumper repo will contain all the individually versioned components compatible with core 1.1.x. if we stick with "Sawtooth 1.1" as the marketing name, then that refers to the bumper repo basically. It will also apply to anything else cross-cutting like docker compose files and website content.

adamludvik (Tue, 18 Sep 2018 16:45:27 GMT):
@amundson Are you suggesting the meta-package and repo are synonymous? I would expect that "meta-package" refers to an "empty" deb package that has as its dependencies a semi-opinionated set of other sawtooth-packages that you can install with one command.

adamludvik (Tue, 18 Sep 2018 16:46:13 GMT):
So maybe `apt-get install sawtooth` gets you everything you need to run a devmode validator with an intkey workload.

amundson (Tue, 18 Sep 2018 16:47:18 GMT):
no, I'm not suggesting they are the same. we also have a 'sawtooth' meta package for convenience but the way it works is too dumb to really care about versions

adamludvik (Tue, 18 Sep 2018 17:06:39 GMT):
I support @amundson's view of what the bumper repo should contain. I think we should discuss what is installed with the meta package in that repo.

amundson (Tue, 18 Sep 2018 17:07:36 GMT):
probably the same as previously minus poet

amundson (Tue, 18 Sep 2018 17:07:48 GMT):
(if poet was even on the list before)

amundson (Tue, 18 Sep 2018 17:08:35 GMT):
if it is essentially "all the stuff from core to run sawtooth" then that makes the versioning make more sense

adamludvik (Tue, 18 Sep 2018 17:08:54 GMT):
Unrelated question, sorry if this was already discussed: why are we publishing the 1.1 repos to `http://repo.sawtooth.me/ubuntu/bumper/*` and not `http://repo.sawtooth.me/ubuntu/1.1/*`?

amundson (Tue, 18 Sep 2018 17:18:31 GMT):
there was a brief thread about it a while ago. basically, it is confusing to talk about version numbers at the distribution level, especially when they match some components and not others. so we adopted the standard convention to use a code name instead (pinball theme, thus bumper). this lets us switch to 'Sawtooth 18.10" or "Sawtooth 2" or another top-level version scheme without changing our repo URL. (separation of concerns). @Dan is still advocating for "Sawtooth 1.1" as the top-level name. I'm not sure it benefits us to stick to that version scheme at that level. But, this way, we can debate it on marketing grounds solely as it won't impact the mechanics.

adamludvik (Tue, 18 Sep 2018 17:25:42 GMT):
So basically the advantage of a named release is decoupling: the release becomes a set of (package, version) pairs instead of a set of packages all with the same version?

amundson (Tue, 18 Sep 2018 17:27:33 GMT):
correct, the release is a distribution of software, not a single piece. the same version of supply chain and such might end up in both the 1.0 and bumper repos because they work with both.

amundson (Tue, 18 Sep 2018 17:28:15 GMT):
most of the SDKs will not get a 1.1.x version bump as they are still 1.0-compatible because of our stable APIs

adamludvik (Tue, 18 Sep 2018 17:29:45 GMT):
Makes sense to me.

adamludvik (Tue, 18 Sep 2018 17:29:58 GMT):
Will `http://repo.sawtooth.me/ubuntu/nightly` continue to track master?

amundson (Tue, 18 Sep 2018 17:33:59 GMT):
sounds correct

adamludvik (Tue, 18 Sep 2018 17:37:25 GMT):
Back to the bumper discussion, how will people know which versions of which packages are compatible with each other? Will this be a requirement for membership in the apt repo? Do we need to differentiate between named releases (cross-package distros?) and version releases (single package changes) to avoid community confusion?

Dan (Tue, 18 Sep 2018 17:41:51 GMT):
``` bumper repo { sawtooth 1.1 meta-package { } sawtooth-poet { poet-simulator //CFT // Not poet-sgx //BFT } sawtooth-raft {} } ```

amundson (Tue, 18 Sep 2018 17:56:31 GMT):
@adamludvik well, everything in the bumper repo will work together. or do you mean when it's not in the repo?

amundson (Tue, 18 Sep 2018 17:58:07 GMT):
currently for bumper it's really a sawtooth-core centric release, so it's stuff compatible with sawtooth-core 1.1. I could see a future release where core stays the same but we have other components like sabre or not-yet-written driving the distribution release compatibility

adamludvik (Tue, 18 Sep 2018 18:03:32 GMT):
It sounds like it is important clarify what is meant by "Sawtooth Release". For the sake of argument, I will take the position that it should mean a versioned core release: 1.0, 1.1, 2.0, etc. In that case, I don't think it makes sense to do another "big release" in order to add new components, you would just release that component with whatever version you want and then add it to the apt repo. Maybe you call this a sawtooth "distro" or something.

adamludvik (Tue, 18 Sep 2018 18:12:06 GMT):
Let me know if I am retreading old ground and need to go read an earlier conversation

adamludvik (Tue, 18 Sep 2018 18:17:07 GMT):
So we could say something like "Every versioned release of sawtooth has an accompanying distro which encompasses a set of packages compatible with that release, and this is what the code name refers to."

Dan (Tue, 18 Sep 2018 18:30:01 GMT):
you are retreading unwritten ground

adamludvik (Tue, 18 Sep 2018 18:33:13 GMT):
Okay, so does everyone already have the above in mind then?

Dan (Tue, 18 Sep 2018 20:13:03 GMT):
Almost certainly not.

achenette (Tue, 18 Sep 2018 21:00:53 GMT):
Minus poet???

achenette (Tue, 18 Sep 2018 21:03:13 GMT):
The Sys Admin guide has steps to install Sawtooth software. I'm changing the `add-apt-repository` step to include "`bumper`". Do they need to get the poet software elsewhere?

achenette (Tue, 18 Sep 2018 21:03:13 GMT):
The Sys Admin guide has steps to install Sawtooth software. I'm changing the `add-apt-repository` step to include `bumper`. Will the sys admin need to get the poet software elsewhere? (That is, in a separate step that references a different repo, package, or metapackage?)

achenette (Tue, 18 Sep 2018 21:04:18 GMT):
Similar question for actually installing the software. Will `sudo apt-get install -y sawtooth` include the necessary stuff for a PoET consensus engine?

Dan (Wed, 19 Sep 2018 12:57:12 GMT):
I think minus poet meant that the deb meta-package for sawtooth wouldn't include any consensus except devmode. Separately you would install poet with something like `apt-get install sawtooth-poet`.

Dan (Wed, 19 Sep 2018 12:57:39 GMT):
Or similiarly `apt-get install sawtooth-raft`

rberg2 (Wed, 19 Sep 2018 14:32:33 GMT):
Greetings! I am pleased to announce sawtooth-raft has been tagged for release of version 0.1.0!

amundson (Wed, 19 Sep 2018 16:13:52 GMT):
@Dan yes, that is what I meant

Dan (Wed, 19 Sep 2018 16:36:08 GMT):
@rberg2 do you know what the sawtooth deb meta-package includes? (either current state or 'bumper' state)

kelly_ (Wed, 19 Sep 2018 16:57:40 GMT):
hey all, I was gonna write one of (hopefully) a number of community blog posts for 1.1

kelly_ (Wed, 19 Sep 2018 16:58:00 GMT):
I wanted to maybe talk about new features and also some forward looking roadmap

kelly_ (Wed, 19 Sep 2018 16:59:10 GMT):
I was discussing with @Dan and we thought good new features to call out 1) start of conversion to rust 2) highlight sabre 3) consensus engine redesign

kelly_ (Wed, 19 Sep 2018 16:59:50 GMT):
any thoughts on other things that would be worth calling out?

kelly_ (Wed, 19 Sep 2018 17:00:26 GMT):
and then i was thinking about maybe alluding to some potential updates in 1.2 which could include further rust, and consensus engines like raft/pbft/poet2-sgx

kelly_ (Wed, 19 Sep 2018 17:00:34 GMT):
open to feedback

adamludvik (Wed, 19 Sep 2018 17:02:54 GMT):
Those all seem good to me

kelly_ (Wed, 19 Sep 2018 17:47:05 GMT):
cool, also if anyone wanted to write the above article, or is looking for a topic, i was thinking one talking about the different companies/applications building on sawtooth

kelly_ (Wed, 19 Sep 2018 17:47:10 GMT):
though that could probably come some time after 1.1

rberg2 (Wed, 19 Sep 2018 17:47:11 GMT):
@Dan Here are the dependencies for the sawtooth package https://github.com/hyperledger/sawtooth-core/blob/master/ci/ns-control#L28

rberg2 (Wed, 19 Sep 2018 17:47:37 GMT):
> Depends: python3-sawtooth-cli, python3-sawtooth-intkey, python3-sawtooth-poet-cli, python3-sawtooth-poet-common, python3-sawtooth-poet-core, python3-sawtooth-poet-families, python3-sawtooth-poet-simulator, python3-sawtooth-rest-api, python3-sawtooth-sdk, python3-sawtooth-settings, python3-sawtooth-signing, python3-sawtooth-validator, python3-sawtooth-xo

boydjohnson (Wed, 19 Sep 2018 17:48:26 GMT):
@kelly_ That seems like a cool topic, of a round up of companies and their use-cases.

adamludvik (Wed, 19 Sep 2018 18:19:09 GMT):
@kelly_ I am hoping to have time soon to do a more thorough job of documenting consensus. I should be able to roll a blog post into that, provided nothing starts on fire.

Dan (Wed, 19 Sep 2018 18:58:04 GMT):
@pankajgoyal can you report LR7 status here for 1.1/bumper?

pankajgoyal (Wed, 19 Sep 2018 19:04:05 GMT):
Here is the LR7 report summary of sawtooth 1.1 release branch. Configuration parameters are: LR7(AWS): 10 validator nodes, 10 TPS applied transaction rate(intkey 5TPS + smallbank 5TPS) EC2: m4.2xlarge ( 8 CPUs, 32GB RAM), 100 GB SSD 5000 IOPS

pankajgoyal (Wed, 19 Sep 2018 19:05:46 GMT):

LR-status-19Sept.docx

Dan (Wed, 19 Sep 2018 19:15:26 GMT):
@pankajgoyal thanks! It appears this build passes the portion of the release criteria around LR7. Does anyone see differently?

Dan (Wed, 19 Sep 2018 19:16:32 GMT):
@rberg2 when I look at the setup.py in the poet engine directory I see.. ``` name='sawtooth-poet-engine' ```

Dan (Wed, 19 Sep 2018 19:17:44 GMT):
Does that mean that the current depdns in the ns-control file above are out of date? i.e. should we be expecting to see `python3-sawtooth-poet-engine` in that list somewhere?

Dan (Wed, 19 Sep 2018 19:17:44 GMT):
Does that mean that the current depends in the ns-control file above are out of date? i.e. should we be expecting to see `python3-sawtooth-poet-engine` in that list somewhere?

rberg2 (Wed, 19 Sep 2018 19:29:03 GMT):
hmm yeah that package should be in there. I can add that.

adamludvik (Wed, 19 Sep 2018 20:30:04 GMT):
@Dan should we create a `sawtooth-poet` meta package instead of adding poet-engine to the sawtooth meta package? And remove poet from the meta package?

achenette (Wed, 19 Sep 2018 20:42:19 GMT):
@adamludvik and @Dan - Does that imply that there might eventually be other metapackages like `sawtooth-raft`? And if someone wanted to install Sawtooth with their own consensus, would they create their own `sawtooth-MyConsensus` metapackage?

adamludvik (Wed, 19 Sep 2018 20:45:07 GMT):
The meta package pattern is just for convenience when there are many packages to install. With sawtooth-core and sawtooth-poet, this makes sense since there multiple packages that need to be installed to get a functional system. This is not a necessary pattern for consensus engines though, but there is nothing stopping the maintainers of that consensus package from doing so. For example, right now there is only one package for sawtooth-raft, so a meta package wouldn't make sense.

achenette (Wed, 19 Sep 2018 20:53:04 GMT):
It seems we're documenting the metapackage approach in the sys admin guide (and, presumably, in the app dev guide eventually). I was hoping that the doc would be generic enough that people could use it as a model if they wanted to install a different consensus mechanism/algorithm.

achenette (Wed, 19 Sep 2018 20:59:11 GMT):
In other words, I'm hoping for a consistent approach for the metapackages that are under our control.

nhrishi (Thu, 20 Sep 2018 08:38:41 GMT):
Has joined the channel.

Dan (Thu, 20 Sep 2018 12:02:21 GMT):
I'm inclined to keep PoET in the sawtooth meta package for ease of use. Just one install command that way. If raft and eventually pbft are small then maybe just add those too.

adamludvik (Thu, 20 Sep 2018 14:35:05 GMT):
*sawtooth-mega package

amundson (Thu, 20 Sep 2018 15:17:46 GMT):
@Dan I'd rather not have to remove poet on every install

amundson (Thu, 20 Sep 2018 15:17:52 GMT):
:)

amundson (Thu, 20 Sep 2018 15:21:21 GMT):
seriously though, the problem with removing things is it's not as trivial to cleanup the dependencies that get pulled in (all those python packages, etc.)

amundson (Thu, 20 Sep 2018 15:22:36 GMT):
though, the same problem may exist with examples, at least those are all within the core repo

Dan (Thu, 20 Sep 2018 15:24:13 GMT):
Yeah I think it's cleaner with a smaller package but messier for writing install directions.

amundson (Thu, 20 Sep 2018 15:24:48 GMT):
is "apt-get install -y sawtooth sawtooth-poet" messy?

adamludvik (Thu, 20 Sep 2018 15:27:19 GMT):
`apt-get instally -y sawtooth-core sawtooth-poet`?

adamludvik (Thu, 20 Sep 2018 15:27:48 GMT):
sawtooth-core => install everything in sawtooth-core?

amundson (Thu, 20 Sep 2018 15:36:45 GMT):
seems ill-defined in that the definition of core keeps changing. like, if we split out the examples, would that list change?

amundson (Thu, 20 Sep 2018 15:38:00 GMT):
if 'sawtooth' pulls in poet, raft, and pbft, it should also probably pull in sabre and seth. should it pull in supply chain, mktplace, and next directory? that would be "everything in the repo" quite literally

amundson (Thu, 20 Sep 2018 15:40:13 GMT):
we could do 'sawtooth' (default packages that are used in almost every install), 'sawtooth-all' or 'sawtooth-everything' (everything in the repo), sawtooth-poet, sawtooth-raft, sawtooth-pbft, sawtooth-sabre, all separately

amundson (Thu, 20 Sep 2018 15:41:46 GMT):
the most common combination for us going forward will probably be core, raft, and sabre

amundson (Thu, 20 Sep 2018 15:41:46 GMT):
the most common combination for us going forward will probably be core, pbft, and sabre

amundson (Thu, 20 Sep 2018 15:42:44 GMT):
(as pbft becomes stable, obviously)

amundson (Thu, 20 Sep 2018 15:43:54 GMT):
though, we deploy using docker primarily too, so this is already an edge-case

adamludvik (Thu, 20 Sep 2018 15:46:59 GMT):
I think the "everything in core" definition is compelling because of its simplicity. Makes it much easier to decide what should go in it for everyone involved. I'm not sure that "core keeps changing" is a valid counterargument. I was under the impression we were mostly done with taking things out of core, but maybe this is not the case?

kelly_ (Thu, 20 Sep 2018 16:08:34 GMT):
I think given where the industry is today, I think ease of install is preferable to optimal/lean install

kelly_ (Thu, 20 Sep 2018 16:10:01 GMT):
e.g. optimize for the 100 people that may want to experiment with sawtooth vs the 20 core devs

Dan (Thu, 20 Sep 2018 16:37:37 GMT):
yeah i guess I'm fine with ```sudo apt-get install -y sawtooth sawtooth-poet```

achenette (Thu, 20 Sep 2018 17:15:28 GMT):
^ This works well for the docs. It's easy for users to see how to change the command if they want different consensus software.

Dan (Thu, 20 Sep 2018 19:21:03 GMT):
I feel like 1.1 build passing LR7 should be a bigger deal. Is everyone cool that those bits are stable?

adamludvik (Thu, 20 Sep 2018 19:23:54 GMT):
Totally missed that comment somehow

adamludvik (Thu, 20 Sep 2018 19:43:18 GMT):
@Dan That report looks good overall. There is memory leak though, hard to tell how bad from the screenshot.

adamludvik (Thu, 20 Sep 2018 19:52:00 GMT):
I think we need to backport 44530a761905d06cc3533e4987bd5c6b264fb5fc

adamludvik (Thu, 20 Sep 2018 19:55:05 GMT):
https://github.com/hyperledger/sawtooth-core/commit/44530a761905d06cc3533e4987bd5c6b264fb5fc

Dan (Thu, 20 Sep 2018 20:30:13 GMT):
so as a matter of process what would be a good way to share the LR data so that we aren't restricted to screenshot interpretation? the grafana site is publicly accessible btw, but this particular run was already stopped. @pankajgoyal has started a new run with the same bits and I've asked that run continue past 7 days if possible. As far as another backport, that's probably fine. If we got it in tomorrow (maybe along with some necessary rustfmt change that boyd just posted) then we could still get in another LR7 before end of month.

adamludvik (Thu, 20 Sep 2018 20:53:42 GMT):
I prefer to look at the data on grafana myself if it is publicly available, because it gives you some tools for diving deeper on the data. In the past we have kept the data around for awhile after the run ended for people to review it posthumously. For long term archiving, we could figure out how to export the data for a specific run out of influxdb so we can restore the view later.

boydjohnson (Thu, 20 Sep 2018 20:56:36 GMT):
You can export a particular chart to csv

adamludvik (Thu, 20 Sep 2018 22:38:08 GMT):
@Dan here's that backport PR: https://github.com/hyperledger/sawtooth-core/pull/1869

Dan (Fri, 21 Sep 2018 15:09:43 GMT):
@adamludvik https://chat.hyperledger.org/channel/sawtooth-release?msg=hfiZBneDnCtAvDo67

henrytill (Fri, 21 Sep 2018 15:28:53 GMT):
Has joined the channel.

pankajgoyal (Sat, 22 Sep 2018 04:18:42 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=dSHtxargTPiZmTJQ9) @Dan I started LR7 (ubuntu/bumper/nightly) on 19th 23:45 Hrs (IST). The run will stop on 26th at the same time. The previous LR7 was started on 12th at around 20:00 Hrs. That also can be viewed in the same grafana dashboard. Its just that someone needs to modify time to view the data. http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&from=now-228h&to=now&var-DATASOURCE=metrics_lr7

pankajgoyal (Mon, 24 Sep 2018 15:25:13 GMT):
LR7 (ubuntu/bumper/nightly), that I started on 19th is still running. Network looks fine. You can have a look at grafana dashboard http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&from=now-116h&to=now&var-DATASOURCE=metrics_lr7

adamludvik (Mon, 24 Sep 2018 15:40:12 GMT):
@Dan @boydjohnson this PR is blocking releases and getting the memory leak fix backported. What needs to be done to resolve it? Looks like our options are 1. Merge it as is, possibly opening a new PR to peg lint version, 2. Add a new commit to peg the lint version, 3. Drop the PR and add a commit to peg to the pre-breaking lint version.

adamludvik (Mon, 24 Sep 2018 15:40:21 GMT):
https://github.com/hyperledger/sawtooth-core/pull/1867

adamludvik (Mon, 24 Sep 2018 16:21:18 GMT):
From offline discussion, sounds like we want to merge the formatting fixes, and follow up with a separate PR to peg the lint versions on the 1-1 branch.

Dan (Mon, 24 Sep 2018 16:24:39 GMT):
I commented on the PR accordingly.

boydjohnson (Mon, 24 Sep 2018 17:07:08 GMT):
@adamludvik PR merged with fmt fixes for 1-1.

boydjohnson (Mon, 24 Sep 2018 17:24:47 GMT):
Just checking if anyone else is going to do the pinning of the version? If not, I will do so.

adamludvik (Mon, 24 Sep 2018 21:10:45 GMT):
@rberg2 Merged this dockerfile for releasing a sawtooth raft engine docker image when we do the full bumper release.

adamludvik (Wed, 26 Sep 2018 16:01:50 GMT):
Forgot to link you: https://github.com/hyperledger/sawtooth-raft/blob/master/ci/Dockerfile-release

Dan (Wed, 26 Sep 2018 16:37:27 GMT):
@pankajgoyal can you launch an LR7 using the binaries from this PR https://build.sawtooth.me/job/Sawtooth-Hyperledger/job/sawtooth-core/job/PR-1869/4/artifact/build/debs/

Dan (Wed, 26 Sep 2018 16:38:10 GMT):
It has a proposed backport for a memory fix. We want to verify that it doesn't regress vs existing 1-1 branch.

pankajgoyal (Wed, 26 Sep 2018 16:56:37 GMT):
okay...and consensus is PoET-SIM?

adamludvik (Wed, 26 Sep 2018 17:32:48 GMT):
I think yes

pankajgoyal (Wed, 26 Sep 2018 19:32:52 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=nzbvFo6PBEsF5evQk) @Dan LR7 started... Grafana dashboard can be seen at http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&var-DATASOURCE=metrics_lr7_nightly&from=now-5m&to=now

Dan (Wed, 26 Sep 2018 19:33:46 GMT):
Awesome @pankajgoyal !

adamludvik (Wed, 26 Sep 2018 20:57:33 GMT):
The dashboard for the previous run seems slow to load for me, so can't compare directly, but the RAM on this latest run looks good so far.

adamludvik (Wed, 26 Sep 2018 20:58:11 GMT):
Those bumps are most likely forks being purged from the block manager.

Dan (Thu, 27 Sep 2018 04:47:25 GMT):
slow for me too. i assume it's a hosting locale thing.

Dan (Thu, 27 Sep 2018 04:47:49 GMT):
sometimes if you just let it stew in the background it's all painted after you are done with email. :)

pankajgoyal (Thu, 27 Sep 2018 15:36:42 GMT):
@Dan LR1 for Raft (1.1 release repo + Raft) is started today. You can take a look at grafana @ http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&from=now-6h&to=now&var-DATASOURCE=Raft_new

pankajgoyal (Fri, 28 Sep 2018 09:55:29 GMT):
I started LR1 for Raft (1.1 release repo + Raft) on 27th Sept at 16:00Hrs approx (IST) . I setup the following raft consensus parameters: sawtooth.consensus.raft.period=3000 sawtooth.consensus.raft.election_tick=20 sawtooth.consensus.raft.heartbeat_tick=2 Observation: After approx 15 hrs of run, I'm getting queue full on all rest end points. You can have a look at grafana at http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&from=now-18h&to=now&var-DATASOURCE=Raft_new . I'm also attaching the snapshot of grafana dashboard for your reference.

pankajgoyal (Fri, 28 Sep 2018 09:56:52 GMT):

Grafana-Dashboard-AWS-1.1-Raft-intkey5TPS-smallbank5TPS.png

pankajgoyal (Fri, 28 Sep 2018 10:04:58 GMT):
I started LR1 for Raft (1.1 release repo + Raft) on 26th Sept at 22:00Hrs approx (IST) . I setup the following raft consensus parameters: sawtooth.consensus.raft.period=3 sawtooth.consensus.raft.election_tick=1500 sawtooth.consensus.raft.heartbeat_tick=150 Observation: After approx 2 hrs of run, I'm getting queue full on all rest end points except the leader node. You can have a look at grafana at http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&from=now-42h&to=now-32h&var-DATASOURCE=Raft . I'm also attaching the snapshot of grafana dashboard for your reference.

pankajgoyal (Fri, 28 Sep 2018 10:06:21 GMT):

1Grafana-Dashboard-AWS-1.1-Raft-intkey5TPS-smallbank5TPS.png

adamludvik (Fri, 28 Sep 2018 19:43:20 GMT):
@pankajgoyal It looks like the network is still committing blocks though, is that correct? Seems like something is holding back the transaction throughput below whatever the workload rate is. What is the workload rate? What is the max block size? You could try increasing max block size and/or decreasing the raft period to increase throughput.

pankajgoyal (Mon, 01 Oct 2018 02:59:35 GMT):
@adamludvik I posted two grafana sessions above. For one of the sessions, the transactions are getting accepted only at Leader node's rest end point. The details for that are as below: sawtooth.consensus.raft.period=3 sawtooth.consensus.raft.election_tick=1500 sawtooth.consensus.raft.heartbeat_tick=150 max_batches_per_block = 500 Input Rate: 10 TPS (5 TPS intkey + 5 TPS smallbank) Grafana: http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&from=now-42h&to=now-32h&var-DATASOURCE=Raft

pankajgoyal (Mon, 01 Oct 2018 06:46:36 GMT):
@adamludvik I tried modifying the max_batches_per_block and sawtooth.consensus.raft.period but rest end point throws error Bad Request (400)

pankajgoyal (Mon, 01 Oct 2018 08:42:30 GMT):
Started LR1 (1.1 + raft) with below parameters: sawtooth.consensus.raft.period=5000 max_batches_per_block = 500 Input Rate: 10 TPS (5 TPS intkey + 5 TPS smallbank) Grafana: http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&from=now-5m&to=now&var-DATASOURCE=Raft_new

adamludvik (Mon, 01 Oct 2018 16:25:44 GMT):
@kelly_ What is your plan for getting these blog posts out the door?

kelly_ (Mon, 01 Oct 2018 17:06:56 GMT):
Probably start coordination with hl folks this week

kelly_ (Mon, 01 Oct 2018 17:07:16 GMT):
I was thinking yours could be a follow on to the 1.1 release, thoughts?

kelly_ (Mon, 01 Oct 2018 17:07:30 GMT):
Was thinking we could mention a few features and then try to do a blog about each

kelly_ (Mon, 01 Oct 2018 17:07:38 GMT):
E.g. rust, consensus, sabre

adamludvik (Mon, 01 Oct 2018 18:16:05 GMT):
That makes sense.

TomBarnes (Mon, 01 Oct 2018 18:27:28 GMT):
i submitted a PR against the sawtooth-poet NOTICES file. The build failed. Log says "TEST_DYNAMIC_NETWORK - failed". I don't think my changes caused that. Can you remind me of how to restart a PR build? Its been a while.

TomBarnes (Mon, 01 Oct 2018 18:31:32 GMT):
I submitted a NOTICES file to sawtooth-raft. It appears to have the required approvals and passed tests, but I do not see a merge option. Do I have write access to the repo? Alternatively, can someone merge it for me?

boydjohnson (Mon, 01 Oct 2018 19:13:27 GMT):
@TomBarnes When you are logged in and viewing a build there is a button to the right, "Replay".

boydjohnson (Mon, 01 Oct 2018 19:13:27 GMT):
@TomBarnes When you are logged in and viewing a build there is a button to the left, "Replay".

TomBarnes (Mon, 01 Oct 2018 21:27:05 GMT):
@boydjohnson Thanks for re-running that for me. I notice that it failed in exactly the same place.

TomBarnes (Mon, 01 Oct 2018 21:28:48 GMT):
Ryan helped me out and now I have started a 3rd run. If it fails again, I'll see if Ashish can help.

boydjohnson (Mon, 01 Oct 2018 22:12:13 GMT):
No problem, Tom.

TomBarnes (Mon, 01 Oct 2018 23:00:05 GMT):
@adamludvik why is openssl installed in sawtooth-raft? I cant find any place where it is actually used.

adamludvik (Mon, 01 Oct 2018 23:29:17 GMT):
It is probably being pulled in with the rust sdk, which installs it.

TomBarnes (Mon, 01 Oct 2018 23:30:40 GMT):
so it should be installed by the sawtooth SDK, not the raft build - correct?

TomBarnes (Mon, 01 Oct 2018 23:30:47 GMT):
[dependencies] clap = "2" hex = "0.3" log = "0.4" log4rs = "0.8" log4rs-syslog = "3.0" protobuf = "2" raft = "0.3.1" sawtooth_sdk = { git = "https://github.com/hyperledger/sawtooth-core.git" } serde_json = "1" uluru = "0.2"

TomBarnes (Mon, 01 Oct 2018 23:30:59 GMT):
but instead it installs it explicitly

adamludvik (Tue, 02 Oct 2018 00:35:16 GMT):
Actually, it is more complicated than that. We are using openssl as a shared library. The SDK is calling into that library through FFI. (Previously this was done using a small C function I had written, but we are now using the full openssl rust library bindings. The story is basically the same though). If you are getting the rust sdk through github or crates.io, then there isn't a good way to have the SDK install it for you because it is a deb package in an apt repo. If you were getting it through a deb package, then you could just specify it as a dependency, but there is not good way to package Rust libraries that aren't shared libraries as deb packages. There is one last alternative, which is to vender openssl with the SDK, but there are separate licensing considerations there I think. https://github.com/sfackler/rust-openssl#vendored

pankajgoyal (Tue, 02 Oct 2018 04:56:23 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=CkLWvfcQcH3i9CesG) @adamludvik The newly started Raft LR1 session is completely blocked after ~ 15hrs.

adamludvik (Tue, 02 Oct 2018 16:05:01 GMT):
Are you able to glean anything from the logs?

TomBarnes (Tue, 02 Oct 2018 16:11:08 GMT):
@adamludvik thanks for the details on openssl - since Raft clearly uses it, I will leave OpenSSL in the NOTICES file and corresponding documentation.

pankajgoyal (Tue, 02 Oct 2018 16:57:31 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=r2Y6iwBSwyHha3fro) @adamludvik I just observed QUEUE_FULL in rest_api_debug.logs file [2018-10-02 16:26:11.877 [MainThread] route_handlers DEBUG] Received CLIENT_BATCH_SUBMIT_RESPONSE response from validator with status QUEUE_FULL [2018-10-02 16:26:11.878 [MainThread] helpers INFO] POST /batches HTTP/1.1: 429 status, 375 size, in 0.003290 s

adamludvik (Tue, 02 Oct 2018 17:01:11 GMT):
QUEUE_FULL indicates that the validator's batch queue is full. The limit is calculated based on the historical throughput of the network. This could indicate that for some reason, the validator is not able to process batches anymore. This is likely because of one of the following: - Crashed/missing TP - Crashed/missing consensus engine - Internal validator problem - No remaining system resources You will need to look at the status and logs for each of those to determine the root cause.

adamludvik (Thu, 04 Oct 2018 16:33:18 GMT):
@amundson in response to your comments on this PR about backwards compatibility and 1.1 https://github.com/hyperledger/sawtooth-core/pull/1889, I have a few thoughts. First, since we haven't actually released 1.1, I think this PR should be considered for backporting immediately. Second, the Consensus API has not gone through any sort of stabilization and committing to backwards compatibility without an effort to stabilize the API implementation as we did with the TP API would be a mistake in my opinion. If there is a requirement that the Consensus API implementation be stabilized before the 1.1 release, then that is a big gap. Third, without this change, BFT consensus algorithms that depend on signed message passing would not actually be BFT with 1.1, which seems like a significant loss. An example of such an algorithm would be PBFT. An example of an algorithm that is not affected by this is Raft.

amundson (Thu, 04 Oct 2018 16:34:14 GMT):
I like the first, backporting

amundson (Thu, 04 Oct 2018 16:35:22 GMT):
because we want to use pbft with 1.1

Dan (Tue, 09 Oct 2018 14:01:55 GMT):
@ltseeley what kind of uptime are you getting with Raft? On bumper the LR tests are failing after ~15 hours (see a few posts above ^). Also can you copy @pankajgoyal on what settings you are using?

ltseeley (Tue, 09 Oct 2018 14:43:06 GMT):
@Dan @pankajgoyal it's been quite some time since I did more long-term testing of Raft; most of my testing involved shorter runs since we were more concerned with measuring performance. As far as settings for a 10 node network running 10TPS, I would recommend these settings: sawtooth.consensus.raft.period=0 sawtooth.consensus.raft.election_tick=100 sawtooth.consensus.raft.heartbeat_tick=10 max_batches_per_block = 150

ltseeley (Tue, 09 Oct 2018 14:43:06 GMT):
@Dan @pankajgoyal it's been quite some time since I did more long-term testing of Raft; most of my testing involved shorter runs since we were more concerned with measuring performance. As far as settings for a 10 node network running 10TPS, I would recommend these settings: sawtooth.consensus.raft.period=0 sawtooth.consensus.raft.election_tick=10 sawtooth.consensus.raft.heartbeat_tick=100 max_batches_per_block = 150

ltseeley (Tue, 09 Oct 2018 14:44:55 GMT):
As @adamludvik pointed out, there are a number of reasons performance degradation could happen, but it is hard to determine without examining the logs

Dan (Tue, 09 Oct 2018 16:49:11 GMT):
Yeah just for setting expectations have you seen raft survive a full LR1?

ltseeley (Tue, 09 Oct 2018 17:58:37 GMT):
I have not

Dan (Tue, 09 Oct 2018 18:54:46 GMT):
@pankajgoyal can you provide the full logs to me? You can DM me if it's a private location.

pankajgoyal (Wed, 10 Oct 2018 07:42:00 GMT):
@ltseeley Oct 10 07:37:56 ip-10-66-0-198 sawtooth-raft: INFO | sawtooth_raft::engin | Raft Engine Config Loaded: RaftEngineConfig { peers: [02acbf587a1703e9651c45b320fc21f43edc7b7d368dbf2616e6b1f812b9944014, 03e312f7b11c81aa005eb059fa78551f263a5d74a996ddc9fd844279038dff1f9d, 03d04238b164f1525ab68bab2672bc6e26172d0fc454944b729095b41720f16961, 0399b6a79fb6d7a499c9e30581419ad49e80ec3f9bfc93702f1471e639063884f5, 021af1d132aa0298d37d57e2a066ea5e682229c627fc13bb180e2e0ad0a218f37e, 03bfa33ee39e307efb5f6d51d92de96503a0ab0fecb9061fba31bdf5f56f14188a, 0279db4fe60020ba9c3f331e6db4178bb4d92030acaa2552238701999de257f70b, 02b99ecfec338b4ce54b0b689c3cd02cf389f0c3775fbe8c3fb12ffee165d66d70, 02303e56fe4a7f2975c804d0fc1fe19dc2e50dfeac86b04982eeac83683ca6df0f, 038752422eaf62224e2f97b10bd0b3cfd3078d347277e92427f93d49914b37ca0f], period: 0ns, raft: { election_tick: 10, heartbeat_tick: 100, applied: 0 }, storage: cached storage: file-system backed persistent storage } Oct 10 07:37:56 ip-10-66-0-198 sawtooth-raft[7220]: thread 'main' panicked at 'configuration is invalid: ConfigInvalid("election tick must be greater than heartbeat tick")', libcore/result.rs:945:5

pankajgoyal (Wed, 10 Oct 2018 07:42:29 GMT):
@ltseeley I tried with configuration mentioned by you and got the error mentioned above.

ltseeley (Wed, 10 Oct 2018 21:22:43 GMT):
@pankajgoyal oh that was a mistake on my part, sorry for that. The election tick should be 100 and the heartbeat tick should be 10

ltseeley (Wed, 10 Oct 2018 21:22:43 GMT):
@pankajgoyal oh that was a mistake on my part, sorry for that. The election tick should be 100 and the heartbeat tick should be 10 (just edited the original message for posterity's sake)

pankajgoyal (Wed, 17 Oct 2018 18:18:36 GMT):
build.sawtooth.me is not available...I want to fetch sawtooth-raft debians from there

pankajgoyal (Wed, 17 Oct 2018 18:19:15 GMT):
@rberg2 Can you check sawtooth build server

pankajgoyal (Wed, 17 Oct 2018 19:11:30 GMT):
Started the LR1 for sawtooth-core(master) + Raft. Grafana link: http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&var-DATASOURCE=nightly_raft_new&from=now-30m&to=now Parameters: ---------------- sawtooth.consensus.raft.period=0 sawtooth.consensus.raft.election_tick=100 sawtooth.consensus.raft.heartbeat_tick=10 sawtooth.publisher.max_batches_per_block=150 I/P TPS: 10 (5 intkey + 5 smallbank)

kelly_ (Wed, 17 Oct 2018 19:45:06 GMT):
@pankajgoyal looks like it is dead ^

kelly_ (Wed, 17 Oct 2018 19:45:36 GMT):
@jsmitchell fyi this is a master+raft run pankaj just started

jsmitchell (Wed, 17 Oct 2018 19:46:16 GMT):
well, there goes that theory. thanks for testing.

kelly_ (Wed, 17 Oct 2018 19:47:29 GMT):
@pankajgoyal can probably tell you more about what they have seen with raft. I know they had a 12 hour run but that one looks like it went ~30 minutes

pankajgoyal (Wed, 17 Oct 2018 19:58:46 GMT):
Another run for sawtooth-core(master) + Raft. Grafana link: http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&from=now-30m&to=now&var-DATASOURCE=nightly_raft&refresh=5s Parameters: ---------------- sawtooth.consensus.raft.period=3000 sawtooth.consensus.raft.election_tick=20 sawtooth.consensus.raft.heartbeat_tick=2 sawtooth.publisher.max_batches_per_block=500 I/P TPS: 10 (5 intkey + 5 smallbank) With these settings and I/P parameters, It ran for ~12Hrs in Sawtooth-1.1 + Raft.

amundson (Wed, 17 Oct 2018 20:13:01 GMT):
@pankajgoyal have you looked in the logs for anything out of the normal?

Dan (Wed, 17 Oct 2018 21:21:37 GMT):
I looked at logs Pankaj saved from a run last week and there were no errors. I didn't find anything that jumped out. You could see backpressure kick in but I assume that was a consequence of the defect and not the source. The replica was dropping a fair amount of duplicate blocks but that seemed expected and unrelated. The main observed failure was that the replicas stopped accepting transactions and only the leader was 'live'.

amundson (Wed, 17 Oct 2018 22:29:00 GMT):
probably a good next step is to figure out how to repeat it outside of that environment (like in docker)

amundson (Fri, 19 Oct 2018 16:23:56 GMT):
@Dan given the list of things to do yet prior to release, which we should be able to post here in some reasonable form on Monday, we are probably a couple weeks out for the release

amundson (Fri, 19 Oct 2018 16:35:29 GMT):
@Dan re:PBFT/consensus API - I'd consider PBFT support (compatibility?) a blocker for 1.1, and I don't think we want to support two PBFT branches

Dan (Fri, 19 Oct 2018 17:04:36 GMT):
Not clear. the consensus API needs this https://github.com/hyperledger/sawtooth-core/pull/1909 for PBFT. If you are talking about the event pattern for communicating settings changes to a consensus engine, that's not even defined yet so I don't think we would want to hold up 1.1 for weeks / months.

amundson (Fri, 19 Oct 2018 17:10:49 GMT):
well, maybe we say "PBFT needs to target core 1.1" and the question I'm asking is "do we need changes in 1.1 for that to be workable?"

amundson (Fri, 19 Oct 2018 17:11:22 GMT):
@adamludvik ^

adamludvik (Fri, 19 Oct 2018 17:19:41 GMT):
My preference is to not break the consensus API once it is published on the 1.1 branch. I think that means we should have https://github.com/hyperledger/sawtooth-core/pull/1909 merged before releasing 1.1. I do not believe the settings push-notifications would be a breaking change (I see it as more of an optimization), and I don't think it is required to make the PBFT implementation stable.

amundson (Fri, 19 Oct 2018 17:22:17 GMT):
ok, that's the opinion I was looking for :)

adamludvik (Fri, 19 Oct 2018 17:59:30 GMT):
Can I get a rocketchat badge that says "The Opinionator"?

amundson (Fri, 19 Oct 2018 18:07:59 GMT):
sure, I think you just email helpdesk

Dan (Fri, 19 Oct 2018 20:15:34 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=6ZaH3SFK6CjHkEmHQ) @TomBarnes ^

Dan (Mon, 22 Oct 2018 19:22:07 GMT):
@pankajgoyal @adamludvik fyi, i just merged this memory leak backport https://github.com/hyperledger/sawtooth-core/pull/1869 Which I had been inadvertently sitting on for a long time.

TomBarnes (Tue, 23 Oct 2018 00:33:23 GMT):
@amundson Hey Shawn - that list would certainly be helpful - looking forward to seeing it. In the meantime, we (Intel) are planning to re-run LR7 with PoET sim and LR1 with Raft as soon as backports are complete, and we are working to address missing license headers in sawtooth-core, sawtooth-poet, and sawtooth-raft.

amundson (Tue, 23 Oct 2018 00:36:45 GMT):
@TomBarnes perfect, we should have backports wrapped up this week

pankajgoyal (Tue, 23 Oct 2018 02:32:19 GMT):
@rberg2 build.sawtooth.me is not accessible. I need to pull raft debian for LR run

agunde (Tue, 23 Oct 2018 14:07:10 GMT):
@pankajgoyal it is back up.

pankajgoyal (Tue, 23 Oct 2018 14:07:34 GMT):
Thanks @agunde

mfford (Tue, 23 Oct 2018 18:36:26 GMT):
The following tasks are being undertaken to prepare for the Sawtooth 1.1 release: -Identify & apply core backports (Shawn, Adam, Ryan, Anne, others) [1 week] -Final LR7 testing (Pankaj) [1 week] -Create release notes for 1.1 (Shawn, Adam, Andi, Ryan, Anne, others) [1 week] -Website enhancements, automation (Ben, Shawn) [1-2 weeks] -Official FAQ & Community page integrated into website (Ben, Dan A, Shawn) [2 days] -Kubernetes updates (Richard) [3 days] -Release Artifact builds, Tagging, Publishing (Ryan, Richard, Ken, Boyd, Shawn) [2 weeks] -Release announcement (Kelly, maintainers) [1 week] -Post-release blog entries (various topics and authors) [weekly] -Coordination w/HL Marketing (Mark, Dan, Shawn, Kelly) [ongoing until release] -Determine release date (root team: Adam, Andi, Dan, James, Kelly, Peter, Shawn, Tom) [ongoing until release] At request of HL, release date will be discussed privately by the root team prior to announcement. Except for the date, everything else will be discussed in #sawtooth-release. The activity durations are engineering estimates. Activities are expected to happen in parallel. Let us know if there are any release preparation activities not listed in the items shown.

Dan (Tue, 23 Oct 2018 21:10:27 GMT):
If I have some release notes text where should I drop that? (it's about poet and sgx in 1.1) If I have some thoughts on the webpage where should I share that?

mfford (Tue, 23 Oct 2018 21:42:08 GMT):
For now, @Dan send release notes text to me, as I will be collecting them

amundson (Wed, 24 Oct 2018 15:07:28 GMT):
@Dan if the website thoughts are deep, we can have a discussion about it in #sawtooth-outreach . if it's tactical (tasks to do before release), maybe here?

adamludvik (Wed, 24 Oct 2018 23:24:13 GMT):
Are we backporting the bionic upgrade to 1.1?

duncanjw (Wed, 24 Oct 2018 23:45:50 GMT):
Has joined the channel.

amundson (Thu, 25 Oct 2018 00:03:01 GMT):
currently no plan to backport bionic changes

adamludvik (Thu, 25 Oct 2018 00:05:23 GMT):
10-4

adamludvik (Thu, 25 Oct 2018 02:08:30 GMT):
Initial backport PR up for validator and consensus: https://github.com/hyperledger/sawtooth-core/pull/1918

adamludvik (Thu, 25 Oct 2018 02:08:37 GMT):
I left a comment about why it's the "initial" one.

Dan (Thu, 25 Oct 2018 13:20:57 GMT):
57 commits .. whaaaa?! :astonished:

amundson (Thu, 25 Oct 2018 15:30:47 GMT):
@Dan you weren't expecting them to be squashed were you? :)

Dan (Thu, 25 Oct 2018 15:48:57 GMT):
yes that would have been sooo much better :P

Sutrannu (Thu, 25 Oct 2018 15:52:34 GMT):
Has joined the channel.

adamludvik (Fri, 26 Oct 2018 17:13:52 GMT):
@amundson @Dan et. al, any thoughts on this comment in the backports PR: > Note that I think we should also backport the change in 20e2265 as it fixes a known bug with the consensus API. However, this change depends on two components in the validator not being backported (block manager and fork cache) so I will need to rewrite part of the fix for 1-1.

adamludvik (Fri, 26 Oct 2018 17:14:06 GMT):
https://github.com/hyperledger/sawtooth-core/commit/20e2265083fdc059c6660d19c59e5c75f045ae4f

Dan (Fri, 26 Oct 2018 18:51:27 GMT):
i think based on our branch point we are already pretty aggressive with backports. I'd rather see us get 1.1 out and then 1.2 before EOY than add more risk/time to 1.1.

adamludvik (Fri, 26 Oct 2018 20:01:38 GMT):
If you change your mind, here is the PR with more details. I'll let you and @amundson decide if we should include it.

adamludvik (Fri, 26 Oct 2018 20:01:41 GMT):
https://github.com/hyperledger/sawtooth-core/pull/1921

Dan (Fri, 26 Oct 2018 20:49:30 GMT):
63 commits ?! you are a machine.

Dan (Fri, 26 Oct 2018 20:59:23 GMT):
Oh I see that's incremental on the other ginormous backport. You still might be a machine though.

Dan (Fri, 26 Oct 2018 20:59:53 GMT):
Some sort of cherry picking bot. :robot: :cherries:

boydjohnson (Mon, 29 Oct 2018 14:32:42 GMT):
https://github.com/hyperledger/sawtooth-core/pull/1922 @Dan @amundson asked me to do the documentation backports for 1-1. None of these commits affect code, but these are backports to the docs directory.

Dan (Mon, 29 Oct 2018 14:33:03 GMT):
thanks!

amundson (Mon, 29 Oct 2018 14:49:42 GMT):
@Dan @adamludvik I think we should put in Adam's fix for that known bug before we start re-running LR testing, since we have to do the LR runs anyway.

Dan (Mon, 29 Oct 2018 14:50:08 GMT):
so use the builds from the #1921?

amundson (Mon, 29 Oct 2018 14:50:43 GMT):
for LR testing? I think we are going to spin some builds specifically for that once we get all the backporting done

amundson (Mon, 29 Oct 2018 14:51:21 GMT):
i.e. in the appropriate repos, not out of a jenkins PR.

amundson (Mon, 29 Oct 2018 14:52:51 GMT):
ideally we make sure that we have everything in the repo that is consistent to test with (core, poet, etc.) so we know the release will be consistent

Dan (Mon, 29 Oct 2018 14:53:20 GMT):
Sure. If we want to start evaluating the blockmanager stuff today, though, then we should spin up an LR using the bits out of #1921?

amundson (Mon, 29 Oct 2018 14:55:38 GMT):
the change in #1921 is not the block manager. it's a more targeted fix that is 1-1 specific because we didn't want to risk of backporting more

amundson (Mon, 29 Oct 2018 14:56:39 GMT):
to the question though, my hope is that those testable artifacts are not too far behind merging in these backport PRs, and that they would be available later in the day

amundson (Mon, 29 Oct 2018 14:57:48 GMT):
@rberg2 has a kubernetes fix that will need to be backported

amundson (Mon, 29 Oct 2018 14:58:26 GMT):
@rberg2 boyd's doc PR has some kubernetes stuff that references 1.0 - is that fixed in your PR from last week?

rberg2 (Mon, 29 Oct 2018 15:00:19 GMT):
@amundson that PR is needed first then this one https://github.com/hyperledger/sawtooth-core/pull/1915

rberg2 (Mon, 29 Oct 2018 15:00:53 GMT):
the one is building now with the lint fix, as soon as thats done I will merge and make the backport PR

boydjohnson (Mon, 29 Oct 2018 15:56:59 GMT):
@amundson @rberg2's commits to change kubernetes files from 1.0 -> 1.1 are included now in my 1-1 backports PR.

amundson (Mon, 29 Oct 2018 15:58:22 GMT):
@boydjohnson ping me after Anne has reviewed the PR and I'll approve it

boydjohnson (Mon, 29 Oct 2018 15:58:44 GMT):
Cool, thanks.

adamludvik (Mon, 29 Oct 2018 16:45:25 GMT):
@Dan @amundson one more backport I think we want in 1-1: https://github.com/hyperledger/sawtooth-core/pull/1924 This stabilizes the consensus p2p messaging API to something similar in spirit to https://github.com/hyperledger/sawtooth-rfcs/pull/23 and is required for implementing this https://github.com/hyperledger/sawtooth-rfcs/pull/30

Dan (Mon, 29 Oct 2018 17:40:26 GMT):
You're just playing a game with me aren't you @adamludvik

adamludvik (Mon, 29 Oct 2018 17:46:02 GMT):
:camel:

rberg2 (Mon, 29 Oct 2018 17:58:24 GMT):
@adamludvik finding commits to cherry-pick! https://giant.gfycat.com/HilariousSophisticatedGlowworm.gif

boydjohnson (Mon, 29 Oct 2018 19:37:45 GMT):
https://github.com/hyperledger/sawtooth-core/pull/1925 @Dan This PR built and has 2 green check marks. I'm going to cherry-pick the commit to my 1-1 backports pr.

adamludvik (Mon, 29 Oct 2018 19:45:16 GMT):
@amundson @Dan If we decide we want all three of these PRs I suggest we close the first two and just merge the third. Merging them one at a time will require rebasing and waiting for Jenkins to rebuild but the result will be identical to merging just the last one. (https://github.com/hyperledger/sawtooth-core/pull/1918, https://github.com/hyperledger/sawtooth-core/pull/1921, https://github.com/hyperledger/sawtooth-core/pull/1924)

adamludvik (Mon, 29 Oct 2018 20:03:43 GMT):
Or if we just want the first two, we just merge the second one.

Dan (Mon, 29 Oct 2018 21:23:27 GMT):
right.. been sorting out some other stuff and haven't gotten to finish reviewing options 2 and 3 yet.

kodonnel (Mon, 29 Oct 2018 22:04:32 GMT):
Has joined the channel.

Dan (Mon, 29 Oct 2018 23:10:55 GMT):
@adamludvik do you have the master commit handy which #1924 comes from?

adamludvik (Mon, 29 Oct 2018 23:19:00 GMT):
https://github.com/hyperledger/sawtooth-core/commit/a23a73838892df8015e19941b02c86a9e51a2784

adamludvik (Tue, 30 Oct 2018 00:28:26 GMT):
@amundson @Dan still need you to approve this for merging: https://github.com/hyperledger/sawtooth-core/pull/1921 I recommend we merge that branch and start LR testing off of the result.

adamludvik (Tue, 30 Oct 2018 00:29:53 GMT):
https://github.com/hyperledger/sawtooth-core/pull/1924 still needs a little work. Seems I missed a couple things in my haste to get it through. It is entirely API related and should have no effect on stability/performance for an LR run.

adamludvik (Tue, 30 Oct 2018 00:48:12 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=k8H2dPWLJRFpZvwt7) Actually it may just be an issue with protobuf updating this weekend

Dan (Tue, 30 Oct 2018 05:34:35 GMT):
I can't find that commit for 1924 in master. Is it in some other branch?

Dan (Tue, 30 Oct 2018 05:35:08 GMT):
1921 is approved now

Dan (Tue, 30 Oct 2018 13:02:00 GMT):
oh, i see, it's not yet merged in master https://github.com/hyperledger/sawtooth-core/pull/1923

boydjohnson (Tue, 30 Oct 2018 14:30:59 GMT):
The 1-1 documentation backports PR, 1922, has been merged.

adamludvik (Tue, 30 Oct 2018 15:31:08 GMT):
1921 (option 2) is merged. Will rebase the p2p messaging stabilization PR. Can we deploy an LR network from the HEAD of the 1-1 branch? @Dan @rberg2 @pankajgoyal ?

rberg2 (Tue, 30 Oct 2018 15:50:47 GMT):
sure, I will monitor the docker outage thats causing builds to fail right now and will get a network deployed as soon as we get 1-1 built with all these changes

Dan (Tue, 30 Oct 2018 15:51:31 GMT):
do we have an existing jenkins job for the 1-1 branch?

rberg2 (Tue, 30 Oct 2018 15:51:37 GMT):
yes

Dan (Tue, 30 Oct 2018 15:52:25 GMT):
cool. i don't see it on the overview tab.. where would i find that?

rberg2 (Tue, 30 Oct 2018 15:52:57 GMT):
https://build.sawtooth.me/view/all/job/Sawtooth-Hyperledger/job/sawtooth-core/job/1-1/

rberg2 (Tue, 30 Oct 2018 15:53:31 GMT):
`all/sawtooth - official builds/ sawtooth-core` will have all branches and PRs

Dan (Tue, 30 Oct 2018 15:53:42 GMT):
thx!

achenette (Tue, 30 Oct 2018 19:44:51 GMT):
@amundson & @Dan - FYI, I'm doing a handful of quick doc changes to fix broken links and annoying errors. I'd like to backport these changes to 1.1 so that the released docs are clean and all links work. Question: Should I backport each one individually as soon as it's merged into master? Or should I batch them into a single PR once I've finished my link-checking pass?

Dan (Tue, 30 Oct 2018 19:45:21 GMT):
batch please

amundson (Tue, 30 Oct 2018 20:42:29 GMT):
I'm cool with either approach (batch or quick)

adamludvik (Wed, 31 Oct 2018 01:53:38 GMT):
My last backport PR is merged: https://github.com/hyperledger/sawtooth-core/pull/1924

chainsaw (Wed, 31 Oct 2018 14:30:48 GMT):
Has joined the channel.

rberg2 (Wed, 31 Oct 2018 20:48:21 GMT):
@Dan @PankajKulkarni the apt repo `bumper/stable` now exists, and is populated with the latest 1-1 release candidate. can you please get that running an LR test? Thanks!

PankajKulkarni (Wed, 31 Oct 2018 20:48:21 GMT):
Has joined the channel.

Dan (Wed, 31 Oct 2018 21:00:23 GMT):
oops - wrong pankaj! You are looking for @pankajgoyal (this is what's refered to as a pankajing failure)

rberg2 (Wed, 31 Oct 2018 21:14:43 GMT):
whoops, sorry PankajKulkarni!

pankajgoyal (Thu, 01 Nov 2018 11:44:53 GMT):
@rberg2 so, the repo is ubuntu/bumper/stable and the key is 8AA7AF1F1091A5FD. right?

rberg2 (Thu, 01 Nov 2018 14:37:28 GMT):
yep! everything in the stable repos will be signed with that key.

pankajgoyal (Thu, 01 Nov 2018 16:35:00 GMT):
@rberg2 I've installed sawtooth-core (from ubuntu/bumper/stable) and Raft from jenkins. Facing some issue while applying Transaction Access policy.

pankajgoyal (Thu, 01 Nov 2018 16:35:01 GMT):
TASK [Apply Transaction Access Policy] ****************************************************************************************************************************************************** fatal: [13.232.245.120]: FAILED! => {"changed": true, "cmd": "sh /tmp/transactionpolicy.sh", "delta": "0:05:00.388717", "end": "2018-11-01 12:01:53.808888", "msg": "non-zero return code", "rc": 1, "start": "2018-11-01 11:56:53.420171", "stderr": "Error: (503): Service Unavailable", "stderr_lines": ["Error: (503): Service Unavailable"], "stdout": "", "stdout_lines": []}

rberg2 (Thu, 01 Nov 2018 16:44:06 GMT):
@pankajgoyal Is there anything interesting in the sawtooth logs on the genesis node? also check `journalctl`

pankajgoyal (Thu, 01 Nov 2018 16:45:10 GMT):
@rberg2 yes, I'm doing that. Also want to know if this apt repo contains the poet packages also?

rberg2 (Thu, 01 Nov 2018 16:45:46 GMT):
yes poet is in there. I have a lr network running poet-sim from bumper.

pankajgoyal (Thu, 01 Nov 2018 16:59:38 GMT):
@rberg2 In genesis validator_debug.log, I got this: [2018-11-01 11:56:39.127 [Thread-44] permission_verifier WARNING] No public key found, ca3132fd32f623a1db7344f1e3b5e2e96fcb0d39500dd03dd09c15b0e3c84a95b4f955a574fd376c0bcb1fbf33264ad6e582fabde2fd9a9b83228e6f58b5dd92 is not permitted. Close connection.

pankajgoyal (Fri, 02 Nov 2018 17:09:49 GMT):
LR7 run for 1.1 (ubuntu/bumper/nightly) + PoET-SIM. Grafana Link: http://52.197.237.0:3000/d/bV0QF0xik/1-1_run?orgId=1&var-DATASOURCE=metrics_lr7_11&from=now-216h&to=now-48h Observation: In one of the nodes, there is backpressure since quite long time. I don't have access to logs so can't comment on this yet. The session was started by someone else. Attaching the grafana snapshot as well.

pankajgoyal (Fri, 02 Nov 2018 17:11:38 GMT):

Grafana-Dashboard-AWS-1.1-poet-sim.png

Sutrannu (Fri, 02 Nov 2018 20:44:15 GMT):
There is website discussion going on in #sawtooth-outreach prior to the 1.1 release.

jsmitchell (Sun, 04 Nov 2018 20:44:45 GMT):
@pankajgoyal the missing core metrics (eg execution rate) suggest that your grafana setup is out of sync with the metric types the validators are reporting. Also, you should configure telegraf so you can report system metrics.

achenette (Wed, 14 Nov 2018 17:43:10 GMT):
@amundson & @Dan - This final doc backport PR needs 2 official reviewers. (It fixes a number of errors and typos.) I'm hoping that there's still time to get it into the 1.1 release. If not, it should be in the next point release. https://github.com/hyperledger/sawtooth-core/pull/1947

TomBarnes (Wed, 14 Nov 2018 17:46:47 GMT):
@achenette seems odd that rust SDK is shown as experimental in the SDK table when the whole of sawtooth is moving to rust

achenette (Wed, 14 Nov 2018 17:48:03 GMT):
That's a question for the people who determined the "status" of each SDK. I recall that Shawn, Peter, Adam, and Dan were deeply invested in how to mark each SDK.

achenette (Wed, 14 Nov 2018 17:48:21 GMT):
I made a change recently, and none of them said anything about changing the Rust status...

achenette (Wed, 14 Nov 2018 17:48:21 GMT):
I made a (minor) change to this page recently, and none of them said anything about changing the Rust status...

TomBarnes (Wed, 14 Nov 2018 17:50:20 GMT):
@amundson @Dan @pschwarz Is the SDK table in PR 1947 correct in showing rust SDK status as "experimental"? We've moved a lot of code to rust this year so I was expecting that the Rust SDK would be one fo the best maintained and most up to date.

Dan (Wed, 14 Nov 2018 17:57:31 GMT):
That's probably an outdated designation.

achenette (Wed, 14 Nov 2018 18:20:03 GMT):
I'll need info (and agreement) on what corrections should be made. https://sawtooth.hyperledger.org/docs/core/nightly/master/app_developers_guide/sdk_table.html For example, is the Rust SDK a 1 for client signing? Transaction processor? Can we check any other boxes, like Stable API or State Delta?

Dan (Thu, 15 Nov 2018 16:02:23 GMT):
client signing and TP should be 1s @pschwarz can you comment on rust sdk's state delta maturity?

pschwarz (Thu, 15 Nov 2018 16:31:42 GMT):
Yes, they're 1s

pschwarz (Thu, 15 Nov 2018 16:51:35 GMT):
The event stuff is stable and used heavily, yes

amundson (Thu, 15 Nov 2018 18:56:47 GMT):
yes, all 1s but not API stable. it wont' be API stable until we go through some form of review process, at which point we could make it 1.0.

JayeshJawale2 (Mon, 19 Nov 2018 09:12:58 GMT):
Has joined the channel.

achenette (Mon, 19 Nov 2018 23:09:22 GMT):
To confirm: For Rust, the SDK table should change as follows: - Change all three Maturity #s to 1 - Add checkmarks in all three Complete columns (Client Signing, Transaction Processor, and State Delta) - Leave the existing checkmark in the State Delta/Stable API column. - Do not add checkmarks for Client Signing/Stable API and State Delta/Stable API. Is that correct, @amundson & @Dan & @pschwarz?

achenette (Mon, 19 Nov 2018 23:09:22 GMT):
To confirm: For Rust, the SDK table should change as follows: - Change all three Maturity #s to 1 - Add checkmarks in all three *Complete* columns (Client Signing, Transaction Processor, and State Delta) - Leave the existing checkmark in the State Delta/Stable API column. - Do not add checkmarks for Client Signing/Complete and State Delta/Complete. Is that correct, @amundson & @Dan?

achenette (Mon, 19 Nov 2018 23:09:22 GMT):
To confirm: For Rust, the SDK table should change as follows: - Change all three Maturity #s to 1 - Add checkmarks in all three Complete columns (Client Signing, Transaction Processor, and State Delta) - Leave the existing checkmark in the State Delta/Stable API column. - Do not add checkmarks for Client Signing/Complete and State Delta/Complete. Is that correct, @amundson & @Dan?

achenette (Mon, 19 Nov 2018 23:09:22 GMT):
To confirm: For Rust, the SDK table should change as follows: - Change all three Maturity #s to 1 - Add checkmarks in all three Complete columns (Client Signing, Transaction Processor, and State Delta) - Leave the existing checkmark in the State Delta/Stable API column. - Do not add checkmarks for Client Signing/Complete and State Delta/Complete. Is that correct, @amundson & @Dan & @pschwarz?

Dan (Mon, 19 Nov 2018 23:15:43 GMT):
I think you meant to type "Do not add checkmarks for client signing / *stable* and *transaction processor stable* "

Dan (Mon, 19 Nov 2018 23:15:43 GMT):
I think you meant to type "Do not add checkmarks for client signing/*stable* and *transaction processor stable* "

Dan (Mon, 19 Nov 2018 23:15:43 GMT):
I think you meant to type "Do not add checkmarks for client signing / *stable* and *transaction processor stable* "

achenette (Mon, 19 Nov 2018 23:30:56 GMT):
Yup. (Edited my message.) Thanks!

achenette (Mon, 19 Nov 2018 23:31:24 GMT):
_Now_ is the above list correct?

Dan (Mon, 19 Nov 2018 23:53:16 GMT):
almost :) state delta <--> transaction processor

achenette (Tue, 20 Nov 2018 16:14:55 GMT):
Sorry - I went to Toronto over the weekend and came down with a bad case of jet lag. (That one-hour difference is a killer!)

bochuxt (Mon, 26 Nov 2018 07:10:31 GMT):
Has joined the channel.

achenette (Mon, 26 Nov 2018 17:48:50 GMT):
@Dan @amundson @pschwarz @TomBarnes Please check out my proposed Rust changes for the SDK table in the following image. If these changes look good, I'll create a PR with the goal of backporting it to 1.1.

achenette (Mon, 26 Nov 2018 17:49:15 GMT):

SDK-table_Rust-changes_2018-11-26.png

amundson (Mon, 26 Nov 2018 17:50:06 GMT):
@achenette uncheck stable api from 'State Delta'

achenette (Mon, 26 Nov 2018 17:50:17 GMT):
OK

achenette (Mon, 26 Nov 2018 17:53:13 GMT):

SDK-table_corrected-Rust-changes_2018-11-26.png

Dan (Mon, 26 Nov 2018 18:00:27 GMT):
@amundson why aren't the other 2 APIs stable? Are there planned changes? Seemed like there were already a lot of new TPs and the old fundamental TPs ported to rust.

amundson (Mon, 26 Nov 2018 18:01:44 GMT):
needs a final review which hasn't been done yet. after we do that, we will increment the rust sdk version to 1.0.

amundson (Mon, 26 Nov 2018 18:05:16 GMT):
don't expect any radical changes between 0.1.x and 1.0.x and the existing TPs can/should use 0.1.x crate until they explicitly support 1.0

amundson (Mon, 26 Nov 2018 18:11:59 GMT):
for example, one discussion point on that will be whether we would like to purge the use of Box in parts of the API and take the approach Ursa has taken (strong opinions were stated against this, but its worth the discussion before we lock it down)

achenette (Wed, 28 Nov 2018 16:01:48 GMT):
The updated SDK table is in PR 1953. It's not building because of a lint problem (not a doc issue), but it's available for review. https://github.com/hyperledger/sawtooth-core/pull/1953

achenette (Wed, 28 Nov 2018 19:12:41 GMT):
^ The build has succeeded, thanks to @adamludvik's pylint fix. Thanks, Adam!

achenette (Wed, 28 Nov 2018 19:14:09 GMT):
Calling @amundson or @TomBarnes or @pschwarz or @jsmitchell for a second review.

achenette (Wed, 28 Nov 2018 19:16:11 GMT):
Thanks, @Dan and @jsmitchell for the quick reviews!

TomBarnes (Fri, 30 Nov 2018 17:10:37 GMT):
:turtle:

kelly_ (Wed, 05 Dec 2018 23:46:35 GMT):
@mfford @amundson - do we have a calendar for sawtooth blogs yet? In addition to slotting Mic in, I'd like to reach out to others (e.g. BTP, T-mo, etc.). It would also probably be useful to provide to Jessica. If such a thing doesn't exist I'm happy to get one started

amundson (Thu, 06 Dec 2018 05:38:43 GMT):
yes, @mfford has a list

kelly_ (Thu, 06 Dec 2018 17:12:36 GMT):
awesome thanks!

kelly_ (Thu, 06 Dec 2018 17:12:58 GMT):
Nice work everyone !! - https://www.hyperledger.org/blog/2018/12/06/announcing-hyperledger-sawtooth-1-1

kelly_ (Thu, 06 Dec 2018 17:13:20 GMT):
I'll be going into an internal webcast for the next couple hours but looks the links are right in the blog and tweet anouncement

amundson (Thu, 06 Dec 2018 17:52:12 GMT):
that's a very blurry image

amundson (Thu, 06 Dec 2018 17:53:07 GMT):
release page - https://sawtooth.hyperledger.org/release/bumper/

benoit.razet (Thu, 06 Dec 2018 18:20:45 GMT):
the release page looks impressive! that's exciting!

kelly_ (Thu, 06 Dec 2018 18:56:59 GMT):
@mfford - would you mind sharing the list when you get a chance?

kelly_ (Thu, 06 Dec 2018 18:57:08 GMT):
the blog post/date list

kelly_ (Thu, 06 Dec 2018 18:57:23 GMT):
and/or just tell me what weeks are available and i'll try to slot some more in

mfford (Thu, 06 Dec 2018 20:21:10 GMT):
@kelly_ Will do

kelly_ (Thu, 06 Dec 2018 22:35:01 GMT):
thanks @mfford - saw it come through

MohitJuneja (Wed, 16 Jan 2019 00:09:13 GMT):
Has joined the channel.

amundson (Thu, 24 Jan 2019 17:11:24 GMT):
We would like to make it possible to request doing a release. This came up because Anne has some doc commits in the 1-1 branch that haven't been released yet, and its caused some frustration.

amundson (Thu, 24 Jan 2019 17:14:09 GMT):
So, what we are planning to do is watch this channel on Tuesdays for requests for a release of a component. If a reasonable case has been made to do a release of that component, then we will do the release on Thursday. This lets the folks doing the release expect some level of potential work on Thursdays, and gives everyone the ability to request it.

amundson (Thu, 24 Jan 2019 17:14:52 GMT):
This is, of course, for minor point releases. There remains much more governance overhead for X.Y releases.

agunde (Thu, 24 Jan 2019 17:16:43 GMT):
Is there a requirement that the changes are already back-ported (merged into the correct branch) before making the request? For example how Anne's Doc updates are already in the 1-1 branch?

agunde (Thu, 24 Jan 2019 17:17:00 GMT):
(I would assume so but clarifying)

amundson (Thu, 24 Jan 2019 17:17:12 GMT):
Yes, that seems like a good requirement to me. And also, no breaking things between tuesday and thursday.

amundson (Thu, 24 Jan 2019 17:19:07 GMT):
We should do this all pragmatically and not get caught up in the rules unless they matter. And adjust it if we learn this wasn't the best approach.

amundson (Thu, 24 Jan 2019 17:20:26 GMT):
Also, this is always per-component and not "release everything", since only so much time will be available to do these things on Thursdays.

agunde (Thu, 24 Jan 2019 17:22:19 GMT):
:thumbsup:

achenette (Thu, 24 Jan 2019 17:38:48 GMT):
:thumbsup: :thumbsup: :thumbsup:

pschwarz (Tue, 29 Jan 2019 16:35:44 GMT):
Shall we discuss a release?

pschwarz (Tue, 29 Jan 2019 18:37:22 GMT):
The following PR's have been included in the 1-1 branch and should be released: https://github.com/hyperledger/sawtooth-core/pull/1982 https://github.com/hyperledger/sawtooth-core/pull/1984 https://github.com/hyperledger/sawtooth-core/pull/1985 https://github.com/hyperledger/sawtooth-core/pull/1986

pschwarz (Tue, 29 Jan 2019 18:38:03 GMT):
The TL;DR of the above is several bug fixes related to event processing and the genesis block

achenette (Tue, 29 Jan 2019 18:56:35 GMT):
The following documentation PRs have been included in the 1-1 branch and should be released: https://github.com/hyperledger/sawtooth-core/pull/1947 https://github.com/hyperledger/sawtooth-core/pull/1960 https://github.com/hyperledger/sawtooth-core/pull/1996 https://github.com/hyperledger/sawtooth-core/pull/2005 https://github.com/hyperledger/sawtooth-core/pull/2009 https://github.com/hyperledger/sawtooth-core/pull/2011 Plus a related PR that is required by the doc PRs: https://github.com/hyperledger/sawtooth-core/pull/2003 Summary: These doc PRs contain consensus-related updates for the procedures in the App Dev Guide and Sys Admin Guide, an update to Rust maturity in the SDK table (App Dev Guide), and several corrections for errors and broken links.

boydjohnson (Tue, 29 Jan 2019 19:03:43 GMT):
@pschwarz That logger bug fix that is in master should be backported to 1-1.

achenette (Tue, 29 Jan 2019 19:33:54 GMT):
Should that be done for the next release? Andi and Shawn mentioned above that PRs should already be backported by Tuesday in order to be considered for release on Thursday.

achenette (Tue, 29 Jan 2019 19:33:54 GMT):
Should that be done for the next release? Andi and Shawn mentioned above that PRs should already be backported before Tuesday in order to be considered for release on Thursday.

pschwarz (Tue, 29 Jan 2019 19:54:12 GMT):
@boydjohnson let's get that backported on Friday, and it can get into next week's release

boydjohnson (Tue, 29 Jan 2019 19:55:12 GMT):
Only half the code correctly logs without this fix.

pschwarz (Tue, 29 Jan 2019 19:57:19 GMT):
But it would be good to have it tested in 1-1, in case that fix doesn't address all of 1-1's issues w.r.t. logging

pschwarz (Tue, 29 Jan 2019 19:59:03 GMT):
It wasn't broken in master, so there could be another reason

amundson (Tue, 29 Jan 2019 19:59:29 GMT):
yeah, that change fixed some segfault stuff in 1-1 right?

amundson (Tue, 29 Jan 2019 19:59:37 GMT):
maybe "fixed" if it wasn't actually the cause

pschwarz (Tue, 29 Jan 2019 20:00:26 GMT):
The original fix in 1-1 fixed some segfault stuff

pschwarz (Tue, 29 Jan 2019 20:01:37 GMT):
The master fix addressed an observed issue where the code would panic. I don't know if they are related, now that you describe it as a segfault issue.

amundson (Tue, 29 Jan 2019 20:02:03 GMT):
maybe it was panic. @boydjohnson do you recall?

pschwarz (Tue, 29 Jan 2019 20:02:04 GMT):
So I think it needs some more time to be tested against the 1-1 codebase

amundson (Tue, 29 Jan 2019 20:03:06 GMT):
That seems fine to me. We should err on the side of not introducing regressions.

boydjohnson (Tue, 29 Jan 2019 20:04:04 GMT):
I don't recall whether the 1-1 original fix was a panic or a segfault. It wasn't clean, whatever it was.

boydjohnson (Tue, 29 Jan 2019 20:04:39 GMT):
Thinking back about it the second init of the logger caused a panic.

amundson (Tue, 29 Jan 2019 20:04:42 GMT):
now you can test how good your commit messages are :)

amundson (Tue, 29 Jan 2019 20:05:59 GMT):
https://github.com/hyperledger/sawtooth-core/commit/81121bac2572fc90001b7dda8b74e88c3cf24ceb

amundson (Tue, 29 Jan 2019 20:06:06 GMT):
It almost tells us :)

amundson (Tue, 29 Jan 2019 20:06:57 GMT):
so, if its a panic it should be easy to test, but don't we expect the same result we got before?

boydjohnson (Tue, 29 Jan 2019 20:08:20 GMT):
Just a second. I'm going to look at @pschwarz fix to see if it is just a revert.

boydjohnson (Tue, 29 Jan 2019 20:09:28 GMT):
https://github.com/hyperledger/sawtooth-core/commit/c2e5e2b69b41f798179ce8e630e19d7e5fe8392c This is the fix that we need, as well as the revert.

boydjohnson (Tue, 29 Jan 2019 20:10:02 GMT):
Peter's message is more thorough than mine.

pschwarz (Tue, 29 Jan 2019 20:14:11 GMT):
It does explain why we won't get the same result

pschwarz (Tue, 29 Jan 2019 20:14:20 GMT):
if it was panicking

pschwarz (Tue, 29 Jan 2019 20:14:46 GMT):
Which, guessing by Boyd's message, it probably was

pschwarz (Tue, 29 Jan 2019 22:18:35 GMT):
@boydjohnson If it hasn't fixed it, was it a failure that appeared during the tests?

boydjohnson (Wed, 30 Jan 2019 21:28:22 GMT):
I was apparent in all integration tests that used the validator, since the validator would panic on startup.

pschwarz (Wed, 30 Jan 2019 21:29:34 GMT):
Ok. Will create a backport PR for it, but it probably won't get in until next week

boydjohnson (Wed, 30 Jan 2019 21:29:44 GMT):
Ok.

rberg2 (Thu, 31 Jan 2019 15:33:06 GMT):
Hello folks! I am going through my check list for a release of sawtooth-core this afternoon and wanted to check in and make sure all pull requests we wish to have in are merged. I see one still out there https://github.com/hyperledger/sawtooth-core/pull/2013

agunde (Thu, 31 Jan 2019 15:35:10 GMT):
@rberg2 that one will go into the next release.

rberg2 (Thu, 31 Jan 2019 15:35:21 GMT):
:thumbsup:

rbuysse (Thu, 31 Jan 2019 21:14:05 GMT):
We'll be postpoining the release of the 1.1 branch until tomorrow.

rbuysse (Thu, 31 Jan 2019 21:14:05 GMT):
We'll be postpoining the release of the 1.1 branch until next thursday, 2/7.

amundson (Fri, 01 Feb 2019 17:32:37 GMT):
The reason for the postponement is build-related around linting errors.

pschwarz (Tue, 05 Feb 2019 22:48:28 GMT):
The linting issues on the 1-1 branch have been resolved. We should be able to do a release this thursday (2/7/2019)

pschwarz (Tue, 05 Feb 2019 22:48:53 GMT):
@amundson @rberg2 @rbuysse

pschwarz (Tue, 05 Feb 2019 22:48:53 GMT):
@amundson @rberg2 @rbuysse :point_up:

pschwarz (Tue, 05 Feb 2019 22:50:41 GMT):
This was resolved with the merging of https://github.com/hyperledger/sawtooth-core/pull/2015

Gandalf (Wed, 06 Feb 2019 18:19:51 GMT):
Has joined the channel.

boydjohnson (Thu, 07 Feb 2019 16:28:15 GMT):
@pschwarz Will the logging fix you made to master be back ported to 1-1?

pschwarz (Thu, 07 Feb 2019 16:30:02 GMT):
No, because the build was busted, so it will have to go into the next one still

pschwarz (Thu, 07 Feb 2019 16:30:14 GMT):
I.e. it couldn't be tested

pschwarz (Thu, 07 Feb 2019 16:31:09 GMT):
I'll merge it after the release and we can test it a bit more thoroughly

rbuysse (Tue, 12 Feb 2019 17:29:29 GMT):
looks like that logging PR mentioned above got merged. we should do a release to get that published.

colincmcc (Tue, 12 Feb 2019 22:39:00 GMT):
Has joined the channel.

pschwarz (Wed, 13 Feb 2019 17:07:35 GMT):
Yes, we should

pschwarz (Wed, 13 Feb 2019 17:07:51 GMT):
(Probably should have said that yesterday - but we talked offline)

amundson (Wed, 13 Feb 2019 18:58:08 GMT):
to be clear, we are talking about doing a 1.1.x release of sawtooth-core on friday?

rbuysse (Wed, 13 Feb 2019 22:22:50 GMT):
nope, we're gonna shoot for tomorrow.

amundson (Wed, 13 Feb 2019 23:00:27 GMT):
right, Thursday, that's what I meant :)

rberg2 (Thu, 14 Feb 2019 17:12:19 GMT):
Greetings! I am writing to inform you that I have begun the release process for sawtooth-core v1.1.4

amundson (Thu, 14 Feb 2019 17:18:46 GMT):
I don't think it was mentioned here, but @rbuysse published a 0.2.0 of the Rust SDK

rberg2 (Thu, 14 Feb 2019 21:02:29 GMT):
Hello folks! I am wrapping up the sawtooth-core 1.1.4 release. deb packages. docker images, and the python-sdk are all done. all that is left is to publish the documentation and this should be completed within the hour.

rberg2 (Thu, 14 Feb 2019 21:03:23 GMT):
now is within the hour so I am not a liar :)

colincmcc (Fri, 15 Feb 2019 00:34:23 GMT):
Is there a changelog for the 0.2.0 version of the Rust SDK?

danintel (Fri, 15 Feb 2019 16:33:36 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=FjKrr9QNeQtHcMBG9) @colincmcc No, I have not seen one. See https://github.com/hyperledger/sawtooth-sdk-rust/commits/master

danintel (Fri, 15 Feb 2019 16:33:36 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=FjKrr9QNeQtHcMBG9) @colincmcc See https://lists.hyperledger.org/g/sawtooth/message/555

rbuysse (Fri, 15 Feb 2019 17:27:25 GMT):
@colincmcc I'll have something for you in just a sec!

rbuysse (Fri, 15 Feb 2019 17:31:53 GMT):
Hyperledger Sawtooth Rust SDK release 0.2.0 is now available. The release is available on creates at https://crates.io/crates/sawtooth-sdk/ or via the git repository on the 0-2 branch at https://github.com/hyperledger/sawtooth-sdk-rust/tree/0-2. New and changed features in Rust SDK 0.2.0 (since 0.1.0): Non-breaking changes: Derive PartialEq, Eq, and Hash traits for PeerInfo and Block. This enables comparison and hashing of PeerInfo and Blocks so they can be used in HashSets and HashMaps Corrected response to ping requests from the validator.

danintel (Fri, 15 Feb 2019 18:36:30 GMT):
Hyperledger Sawtooth core release 1.1.4 is now available (bug fixes only): https://lists.hyperledger.org/g/sawtooth/message/554

colincmcc (Sat, 16 Feb 2019 16:01:20 GMT):
@danintel @rbuysse Thanks!

pankajgoyal (Mon, 18 Feb 2019 06:47:45 GMT):
[?]: We are planning to have next dot release of Raft consensus. So far we are using nightly (bionic) branch of sawtooth-core to test Raft. So, we want to ask if there is a tagged bionic branch of sawtooth-core nightly which we can use now and perform Raft release activities.

manojgop (Mon, 18 Feb 2019 09:34:00 GMT):
Has joined the channel.

amundson (Mon, 18 Feb 2019 14:53:24 GMT):
@pankajgoyal there are no 1.2.x core releases yet. the intent would be that poet, pbft, and raft all have to support both 1.1 and master. so you should to test against 1.1 as well.

amolk (Tue, 19 Feb 2019 09:27:15 GMT):
@amundson agreed. The question was whether there is a branch for bionic we can peg our release activities to. The master is a moving target. Is it OK to tag the master?

amundson (Tue, 19 Feb 2019 14:25:11 GMT):
@amolk my impression is that poet+core master has issues passing liveness tests. I don't think we would want to do a release of core while that remains the case (tag == release).

manojgop (Wed, 20 Feb 2019 06:07:23 GMT):
@amundson Is the release of core dependent/blocked on sawtooth-poet ? Can we have a sawtooth-core release for bionic which will work with PBFT and RAFT ?

amolk (Wed, 20 Feb 2019 10:02:54 GMT):
@amundson Could you please share more info on what's the issue w/ PoET? AFAIK it hasn't changed in a while. The last meaningful changes were in December, before the 1.1 release.

amundson (Wed, 20 Feb 2019 14:39:37 GMT):
@amolk I don't think root cause is known yet, but its an interaction between PoET and core master. It could be a bug in master.

amundson (Wed, 20 Feb 2019 14:40:18 GMT):
It is informative though if your RAFT testing is against core master and it is stable.

amundson (Wed, 20 Feb 2019 14:41:07 GMT):
@ltseeley @rbuysse @pschwarz do you guys have any more commentary on this that would help describe the issue?

ltseeley (Wed, 20 Feb 2019 15:10:43 GMT):
From what I've been able to tell (and @pschwarz may be able to clarify some of the finer points), it seems that the issue is caused by changes to the way the validator manages blocks. There are certain scenarios that occur with PoET that the validator didn't have a problem with before, but now it takes exception to. We aren't totally sure yet if it's the validator that's incorrect or PoET (or quite possibly a bit of both).

ltseeley (Wed, 20 Feb 2019 15:12:51 GMT):
Specifically, it seems like an issue with the fork resolution and how the validator keeps track of references to blocks. That's why we're seeing issues with PoET and not the non-forking algorithms Raft and PBFT.

HarshaIntel (Thu, 21 Feb 2019 09:15:59 GMT):
Has joined the channel.

arsulegai (Sun, 24 Feb 2019 05:09:56 GMT):
How to reproduce it and see what's happening? Will running PoET for some duration get us to the issue point?

amolk (Sun, 24 Feb 2019 09:38:02 GMT):
@ltseeley do you have any plans to fix the PoET issue? It seems like a significant change to the validator behavior.

satelander (Tue, 26 Feb 2019 18:41:47 GMT):
Has joined the channel.

arsulegai (Wed, 27 Feb 2019 08:11:21 GMT):
@rbuysse @rberg2 @pankajgoyal Is sawtooth-raft latest debian available from repository?

arsulegai (Wed, 27 Feb 2019 08:11:21 GMT):
@rbuysse @rberg2 @pankajgoyal Is sawtooth-raft latest docker image available from dockerhub?

rbuysse (Wed, 27 Feb 2019 15:22:41 GMT):
https://hub.docker.com/r/hyperledger/sawtooth-raft-engine

rbuysse (Wed, 27 Feb 2019 15:22:57 GMT):
we're not currently doing nightly images for that, but it's planned

arsulegai (Wed, 27 Feb 2019 15:38:46 GMT):
Ok

pankajgoyal (Mon, 11 Mar 2019 17:45:39 GMT):
@amundson @rberg2 We have been testing sawtooth-raft against sawtooth-core master branch (hash: 0cf2e8c0cd908e68cf1453c8160468736a1323aa). Can a tag be placed at this hash of master branch which will be the reference of sawtooth-core for raft release?

amundson (Mon, 11 Mar 2019 21:42:41 GMT):
@pankajgoyal the consensus engines shouldn't depend on a specific version of the core repo right? if you want to test against a stable version, why not use 1.1.x?

amundson (Mon, 11 Mar 2019 21:44:07 GMT):
a release of core right now needs more discussion, because PoET tests fail against it

amundson (Mon, 11 Mar 2019 21:44:55 GMT):
I think we either make a decision to fully deprecate PoET (which seems unlikely) or we hold the release until everything is working together again

pankajgoyal (Tue, 12 Mar 2019 04:12:51 GMT):
@amundson There is an important patch that is needed for raft. This is PR from seeley (https://github.com/hyperledger/sawtooth-core/pull/2019). And this patch is on top of sawtooth-core master (0cf2e8c0cd908e68cf1453c8160468736a1323aa). And we have been testing raft by applying seeley's patch on top of this master hash. So, we want a TAG on this master hash without worrying about any further changes that keep coming into master branch. And yes, we are testing raft against 1.1.x also.

HarshaIntel (Tue, 12 Mar 2019 04:17:28 GMT):
@amundson This patch disables the gossip n/w and it s proven to work for long hours (LR runs) without backpressure, hence this patch is needed to be taken on top of teh master shared above.

amundson (Tue, 12 Mar 2019 04:46:19 GMT):
@HarshaIntel back pressure is good. the only way to avoid back pressure is to have a really low workload, which means the test isn’t stressing the network. glad this patch helps. curious if you also get stable results if you load the network with a workload just above what it can handle.

amundson (Tue, 12 Mar 2019 04:48:38 GMT):
@pankajgoyal are you saying raft is not stable against 1.1? I believe pbft is, and I would expect raft could be as well.

amolk (Tue, 12 Mar 2019 04:51:22 GMT):
It is stable on 1.1 but performs better with the patch. Would request you to merge it and backport to 1.1

amundson (Tue, 12 Mar 2019 04:52:25 GMT):
It seems possible that this patch helps raft because it makes it less likely to trigger performance/timing bugs, and for solely functional reasons. thoughts?

amundson (Tue, 12 Mar 2019 04:55:26 GMT):
in terms of tags, we only do them for releases (our versioning code would be potentially sensitive to arbitrary tags), which is why I am interpreting your tag request as a request for a release. And like I said before, releasing while poet tests are failing seems like the wrong path forward.

amolk (Tue, 12 Mar 2019 04:59:41 GMT):
We just need a fixed point of reference to run our final Raft validation and point anyone interested in running Raft on Bionic. If a tag isn't the right way to go about it, we'll be happy to have some other point of reference. BTW, there's a 1.2 tag that seems to have been created back in September :)

amolk (Tue, 12 Mar 2019 05:04:07 GMT):
And you're right about the patch. It makes the processing of consensus messages a bit more efficient and reduces some of the timing dependent issues we see under heavy loads. The right long term solution would be to eliminate the GIL related bottlenecks on queue processing.

amundson (Tue, 12 Mar 2019 05:14:43 GMT):
@amolk that bottleneck comment is inconsistent with all the performance data I have seen in the past (which suggested a primary bottleneck in the predecessor tree). if you have data that shows something different, that would be good info for #sawtooth-core-dev. the use of python is going away, and so thus will the GIL. the transact library should address both the GIL and predecessor tree performance when we get to using it later in the year.

amundson (Tue, 12 Mar 2019 05:17:11 GMT):
you should only test under heavy loads if thats what exposes the raft bugs. assuming you want to get to a stable raft release.

amundson (Tue, 12 Mar 2019 05:18:54 GMT):
@amolk do you mean literally only raft on bionic as in a docker container, or do you mean sawtooth?

amundson (Tue, 12 Mar 2019 05:24:07 GMT):
the 1.2.0 tag exists at the branch point; it is an artifact of the branching and versioning process.

amundson (Tue, 12 Mar 2019 05:24:47 GMT):
backporting isn’t going to help w/bionic

amundson (Thu, 14 Mar 2019 18:20:51 GMT):
@amolk I'd like to start considering a feature cut-off date for 1.2 so we can start to do testing. Do you have a sense for how long the remaining features desired for 1.2 that have RFCs in-progress for will take to implement?

amolk (Mon, 18 Mar 2019 09:23:35 GMT):
@amundson Raft is mostly done. We'll restart work on PoET 2 once Raft is done and aim to be ready later in Q2.

amolk (Mon, 18 Mar 2019 09:25:48 GMT):
regarding your earlier comment, backporting that PR would help with Raft on 1.1. That's separate from the Bionic requirement.

manojgop (Mon, 18 Mar 2019 09:40:50 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=xEY5HFBizlRnOVbD3s) @amundson Could you give some more details on "transact library" ?

amundson (Mon, 18 Mar 2019 14:06:08 GMT):
@manojgop basically, a rust re-implementation of the tep within sawtooth (schedulers, context management, execution, and state)

manojgop (Mon, 18 Mar 2019 15:43:59 GMT):
Thanks @amundson . Could you please clarify what is predecessor tree and what is the bottleneck there ?

amundson (Mon, 18 Mar 2019 16:00:16 GMT):
@manojgop the predecessor tree is a component of the parallel scheduler which helps determine implicit dependencies between transactions. the bottleneck is CPU.

manojgop (Mon, 18 Mar 2019 16:09:08 GMT):
@amundson So if I understand correctly, Rust implementation will make sawtooth core multi threaded and performance can improve on multi core CPUs. That's very encouraging if we can make Sawtooth performance (in terms of TPS) competitive with other ledgers for various workloads

amundson (Mon, 18 Mar 2019 16:24:17 GMT):
@manojgop we are already competitive in apples-to-apples comparisons, AFAIK. but yeah, it is going to be a substantial performance increase.

ltseeley (Tue, 02 Apr 2019 15:46:47 GMT):
I'd like to propose a new 1.1 release to incorporate the latest bugfixes and updates. The following PRs have been merged since the last release: https://github.com/hyperledger/sawtooth-core/pull/2034 (Python lint update) https://github.com/hyperledger/sawtooth-core/pull/2036 (chain controller bug fix)

ltseeley (Tue, 02 Apr 2019 15:48:49 GMT):
I'd like to propose a new 1.1 release to incorporate the latest bugfixes and updates. The following PRs have been merged since the last release: https://github.com/hyperledger/sawtooth-core/pull/2034 (Python lint update) https://github.com/hyperledger/sawtooth-core/pull/2036 (chain controller bug fix) https://github.com/hyperledger/sawtooth-core/pull/2038 (consensus proxy bug fix) https://github.com/hyperledger/sawtooth-core/pull/2039 (docs update) https://github.com/hyperledger/sawtooth-core/pull/2048 (gossip/consensus messaging bug fix) https://github.com/hyperledger/sawtooth-core/pull/2052 (grafana docker image fix)

pschwarz (Tue, 02 Apr 2019 17:53:22 GMT):
Sounds good to me

rbuysse (Tue, 02 Apr 2019 23:15:11 GMT):
seems prudent

donalddw (Mon, 15 Apr 2019 15:42:30 GMT):
Has joined the channel.

ltseeley (Mon, 15 Apr 2019 15:44:49 GMT):
Want to reiterate my request for a 1.1 release. Two more fixes have been backported: https://github.com/hyperledger/sawtooth-core/pull/2058 (fix documentation building) https://github.com/hyperledger/sawtooth-core/pull/2068 (fix bug with transaction receipts)

sah (Tue, 16 Apr 2019 04:19:53 GMT):
Has joined the channel.

Dan (Tue, 16 Apr 2019 14:10:38 GMT):
@amundson I don't see any unmerged backport PRs. Is there anything blocking from your perspective?

amundson (Tue, 16 Apr 2019 14:11:57 GMT):
@Dan we changed the procedure slighly in your absence

amundson (Tue, 16 Apr 2019 14:12:22 GMT):
the new procedure is basically: anyone can requests a point release of a component on tuesday, and if there is no objection, then it will be done on thursday

Dan (Tue, 16 Apr 2019 14:12:24 GMT):
I was waiting for the note that "we fixed the glitch"

amundson (Tue, 16 Apr 2019 14:14:47 GMT):
@ltseeley is specifically requesting a sawtooth-core release. other components won't be released.

amundson (Tue, 16 Apr 2019 14:14:57 GMT):
(unless requested)

Dan (Tue, 16 Apr 2019 14:15:45 GMT):
cool

amundson (Tue, 16 Apr 2019 14:19:32 GMT):
also, I don't have any objection. I think there are some critical fixes for a few users in these backports.

Dan (Tue, 16 Apr 2019 14:21:14 GMT):
how do we communicate that? are we hitting the list with a bug fix release note?

pschwarz (Tue, 16 Apr 2019 16:57:13 GMT):
We send out release notes to the mailing list

rberg2 (Thu, 18 Apr 2019 16:26:12 GMT):
Hello all, I will be releasing sawtooth-core 1.1.5 shortly.

rberg2 (Thu, 18 Apr 2019 17:14:32 GMT):
FYI: deb packages, docker images and the python SDK V1.1.5 has been released. still up to do Documentation and release notes.

ltseeley (Thu, 18 Apr 2019 17:21:14 GMT):
@eugene-babichenko @donalddw I believe you both were waiting for the v1.1.5 release for fixes to bugs you were experiencing.

eugene-babichenko (Thu, 18 Apr 2019 17:21:15 GMT):
Has joined the channel.

rbuysse (Thu, 18 Apr 2019 20:10:14 GMT):
Hyperledger Sawtooth Core release 1.1.5 is now available. Documentation is available at https://sawtooth.hyperledger.org/docs/core/releases/1.1.5/ New and changed features in Hyperledger Sawtooth Core 1.1.5 (since 1.1.4): Non-breaking changes: - Fixed a bug in fork resolution where the resulting chain was empty - Fixed a consensus registration bug caused by peering delays - Updated documentation of consensus settings - Fixed a gossip bug that could prevented consensus message delivery - Updated broken Grafana docker image - Fixed doc building error caused by unicode - Corrected transaction receipt data field

eugene-babichenko (Fri, 19 Apr 2019 14:44:59 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=iAmWavcPDam9x8mQt) @ltseeley That helped. Thanks the team for that!

donalddw (Sun, 21 Apr 2019 09:38:30 GMT):
thanks @ltseeley and team for this release, will try it out as soon as possible!

manojgop (Mon, 22 Apr 2019 15:29:30 GMT):
@amundson @ltseeley Can we tag sawtooth-raft based on latest code in master branch and release it independently from Sawtooth 1.2. As I understand as part of sawtooth-raft release , the Docker and Debian image will also be released and available to download. Let me know if there are any concerns

manojgop (Mon, 22 Apr 2019 15:30:03 GMT):
@Dan @amolk :point_up_2:

Dan (Mon, 22 Apr 2019 15:33:31 GMT):
Yes that's fine. I support a new point release of this component.

arsulegai (Mon, 22 Apr 2019 15:34:53 GMT):
Before dot release of Raft, the PR https://github.com/hyperledger/sawtooth-raft/pull/58 would be good.

ltseeley (Mon, 22 Apr 2019 15:52:02 GMT):
@arsulegai I just merged PR 58 ^

arsulegai (Mon, 22 Apr 2019 16:01:57 GMT):
Thanks, we request for dot release / tag for sawtooth-raft

eugene-babichenko (Tue, 23 Apr 2019 16:35:47 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=bRDjNB9G76cNXTdLG) @rbuysse A little question about this release. When a node receive a new consensus message is that message broadcasted to its peers?

rbuysse (Tue, 23 Apr 2019 16:39:48 GMT):
@eugene-babichenko no, consensus messages are not gossiped currently

eugene-babichenko (Tue, 23 Apr 2019 16:58:04 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=BZEehqtTueKXqB2LK) @rbuysse So there is no changes. Just wanted to make sure. Thanks!

Dan (Wed, 24 Apr 2019 14:08:04 GMT):
Per question at Monday's contributor meeting, stake holders interested in delete by prefix do *not* view that as a blocking item for sawtooth core 1.2 release.

amundson (Wed, 24 Apr 2019 15:07:30 GMT):
@Dan ah, great, thanks! I assume they are still interest in it post-1.2 though?

Dan (Wed, 24 Apr 2019 15:07:56 GMT):
Yeah. I think they have a workaround today so they wouldn't hold up the release for it.

amundson (Wed, 24 Apr 2019 15:47:21 GMT):
I wonder if we actually have any blocking features then.

mfford (Wed, 24 Apr 2019 16:03:58 GMT):
For those that could not attend, here is the link to the notes taken from the 4/22 Hyperledger Sawtooth Contributor Meeting: https://wiki.hyperledger.org/pages/viewpage.action?pageId=9110236

arsulegai (Thu, 25 Apr 2019 02:25:39 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=evgbrvqfiA5zJRejC) @amundson Please consider raw transaction header a part of 1.2

rberg2 (Thu, 25 Apr 2019 20:26:13 GMT):
Greetings! sawtooth-raft 0.1.2 has been released!

danintel (Fri, 26 Apr 2019 16:14:43 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-release?msg=45Sfs8GWG7rmqGvua) @rberg2 Does that mean the on-chain setting `sawtooth.consensus.algorithm.version` has to be updated before (or maybe after) upgrading to RAFT 0.1.2 from 0.1?

ltseeley (Fri, 26 Apr 2019 16:16:42 GMT):
@danintel no, it shouldn't. The version for that setting should still be `0.1`

ltseeley (Fri, 26 Apr 2019 16:18:55 GMT):
The convention we've used is to only include the major.minor version, not the .patch number. But whatever the engine reports its version as, that's what the setting has to match. Here's where Raft's is set: https://github.com/hyperledger/sawtooth-raft/blob/master/src/engine.rs#L110

amundson (Fri, 26 Apr 2019 17:08:19 GMT):
FYI - @wkatsak mentioned adding ipv6 support prior to the 1.2 release

wkatsak (Fri, 26 Apr 2019 17:08:20 GMT):
Has joined the channel.

danintel (Fri, 26 Apr 2019 17:54:49 GMT):
@ltseeley Thanks. The Raft documentation stays to use version `0.0.1`. Or It used to say that--now it says to use the current version but now that is (unhelpfully) removed. It would be nice, at least, to have a link to the source code or some obscure command line syntax so the user can somehow discover what version to use. :slight_smile:

amundson (Fri, 26 Apr 2019 17:55:08 GMT):
specifically, the sawtooth.consensus.algorithm.version setting is the _protocol_ level and has nothing to do really with software version conceptually

Dan (Fri, 26 Apr 2019 19:28:56 GMT):
a critical bug fix might be conceptually a protocol version change in that you don't want people attaching broken nodes to the network even if the wireline is the same.

pschwarz (Mon, 29 Apr 2019 14:30:00 GMT):
That sounds like it would be effectively a behaviour change, so sounds reasonable to bump the version presented to the validator, via settings

rllalloshi (Tue, 30 Apr 2019 11:58:23 GMT):
Has joined the channel.

wkatsak (Tue, 30 Apr 2019 12:02:18 GMT):
Hello, as @amundson mentioned, I (and Taekion) have a patchset for 1.1 that enables running Sawtooth on IPv6 networks. We are in the process of "smoothing out" the patches and validating it on master.

wkatsak (Tue, 30 Apr 2019 12:03:16 GMT):
What is the timeframe for getting it into 1.2, and what type of testing would you like to see? It essentially consists of a zmq flag, and other small changes (rest api, etc) to correct assumptions that only work for ipv4 addresses.

wkatsak (Tue, 30 Apr 2019 12:03:49 GMT):
We have a testnet that ONLY has ipv6 connectivity (but has local ipv4 stack for localhost, etc), so this was the motivation.

amundson (Tue, 30 Apr 2019 14:32:57 GMT):
@wkatsak this week would be good

wkatsak (Thu, 02 May 2019 13:16:26 GMT):
Hello, I am trying to make sure the tests run with my patches in place, as per the contributing guide.

wkatsak (Thu, 02 May 2019 13:16:56 GMT):
and I am getting a failure: "ERROR:__main__:Test UNIT-SIGNING failed", even without my patches (even on tag v1.1.5, actually)

wkatsak (Thu, 02 May 2019 13:17:01 GMT):
Am I doing something stupid?

rberg2 (Thu, 02 May 2019 14:06:44 GMT):
@wkatsak can you see any errors or other reasons for that failure? usually there is an error printed a page or two up in the scroll back.

wkatsak (Thu, 02 May 2019 14:07:36 GMT):
``` INFO:__main__:Getting result with: ['docker', 'inspect', '-f', '{{.State.ExitCode}}', 'latest_unit-signing_1'] Error: No such object: latest_unit-signing_1 ERROR:__main__:Failed to retrieve exit status of test. ERROR:__main__:Command '['docker', 'inspect', '-f', '{{.State.ExitCode}}', 'latest_unit-signing_1']' returned non-zero exit status 1. Traceback (most recent call last): File "/local/sawtooth-core/bin/run_docker_test", line ```

rberg2 (Thu, 02 May 2019 14:10:06 GMT):
thanks! I am going to see if I can replicate that here

mfford (Thu, 02 May 2019 14:13:41 GMT):
@wkatsak Would you mind creating a JIRA ticket for your patchset for enablement of Sawtooth on IPV6? We are tracking items intended for version 1.2 together on Jira for Sawtooth. In addition to the instructions for "Tracking Issues" in the community doc, also create it as issue type= improvement, indicate Sawtooth Version 1.2 in the "Fix Version/s" field and assign it to yourself. If you need help, you can DM me directly. Here is the link: https://sawtooth.hyperledger.org/docs/core/releases/latest/community/issue_tracking.html

wkatsak (Thu, 02 May 2019 14:25:07 GMT):
@mfford Ok, I've done it.

mfford (Thu, 02 May 2019 14:39:50 GMT):
Looks good! Thanks @wkatsak

wkatsak (Thu, 02 May 2019 18:19:08 GMT):
@mfford I noticed the test build on github failed, but it seems its a permissions issue (didn't like my username).

rberg2 (Thu, 02 May 2019 19:01:27 GMT):
that's an unrelated issue.

ltseeley (Tue, 07 May 2019 16:15:50 GMT):
I'd like to request a new release for PBFT to include the latest improvements and bugfixes

ltseeley (Tue, 07 May 2019 16:15:50 GMT):
I'd like to request a new release for PBFT to include the latest improvements and bug fixes

rbuysse (Thu, 09 May 2019 21:21:04 GMT):
PBFT release is complete! version 0.1.3 has been published to the bumper apt repo and dockerhub

Dan (Wed, 15 May 2019 15:28:15 GMT):
Intel has an internally hosted regression test environment. They would like to help validate the 1.2 candidate (extended regression tests, LR testing of all 3 consensus protocols). Probably the minimal coordination is just awareness of the 1.2 branch point. @amolk on point for that.

Dan (Wed, 15 May 2019 15:36:48 GMT):
@amundson remind me the of the code name nomenclature.. are code names for major releases or minor releases?

amundson (Wed, 15 May 2019 16:14:10 GMT):
@Dan code names are for project-level releases. Sawtooh 1.0, 1.1, 1.2, etc.

Dan (Wed, 15 May 2019 16:16:38 GMT):
So in terms of semver that would be minor versions (and implicitly major versions).

amundson (Wed, 15 May 2019 16:20:13 GMT):
two separate things - version numbers on components (very semver, have minor versions, etc.) and project-level releases which are essentially sawtooth distributions

amundson (Wed, 15 May 2019 16:20:13 GMT):
two separate things - version numbers on components (very semver, have X.Y.Z versions, etc.) and project-level releases which are essentially sawtooth distributions

Dan (Wed, 15 May 2019 16:50:00 GMT):
So a tangible aspect of that distinction is that if I were to pull apt packages for any sawtooth component, I would pull from a unified repo for that distribution e.g. ubuntu/multiball/ Which itself could include python3-sawtooth-poet-cli 1.45.2 and python3-sawtooth-intkey 27.1.2

amundson (Wed, 15 May 2019 17:55:09 GMT):
yes

amundson (Wed, 15 May 2019 17:56:10 GMT):
in fact, many of the components will be the same version between bumper and chime

Dan (Wed, 15 May 2019 18:26:15 GMT):
@TomBarnes ^ regarding versioning and "sawtooth 1.2"

amundson (Wed, 29 May 2019 18:09:07 GMT):
Current plan is to create a sawtooth-core 1-2 branch next week 6/5

rbuysse (Mon, 03 Jun 2019 21:23:32 GMT):
we've just released a new version of the sabre-sdk! https://crates.io/crates/sabre-sdk/0.3.0

amolk (Thu, 06 Jun 2019 05:48:31 GMT):
Please let us know when the 1.2 branch is created. We'll get doing regression testing and run LR tests on it.

Dan (Thu, 06 Jun 2019 13:12:49 GMT):
I believe the branch is created now. A note to this channel would have been good. https://github.com/hyperledger/sawtooth-core/tree/1-2

amundson (Thu, 06 Jun 2019 13:17:20 GMT):
We are going through the tasks on the board in JIRA - @rbuysse @rberg2 maybe you can drop notes here as the more important items complete

rberg2 (Thu, 06 Jun 2019 14:14:20 GMT):
We created the `chime` nightly and stable apt repositories yesterday. Currently those repos are only populated with the Sawtooth dependencies

Dan (Thu, 06 Jun 2019 14:42:32 GMT):
@amolk I've not been watching Jira as frequently as I used to. I need to get back on that. Good for others to be engaged there too.

amolk (Thu, 06 Jun 2019 14:42:54 GMT):
Agree

Dan (Mon, 10 Jun 2019 15:58:00 GMT):
@amolk do you have any LR testing plans or thoughts on communicating results/analysis to share?

amolk (Wed, 12 Jun 2019 07:00:59 GMT):
Regression tests have been run on PBFT. LR1 tests have started on PoET, PBFT and Raft. LR7 tests will start later this week or early next. We will provide regular updates on the results here on this channel.

amundson (Wed, 12 Jun 2019 15:45:31 GMT):
@amolk great you are testing too

amundson (Wed, 12 Jun 2019 15:45:51 GMT):
what specifically do you mean by "Regression tests have been run on PBFT."?

amundson (Wed, 12 Jun 2019 15:47:38 GMT):
In general, PBFT is very well-tested at this point and passes LR7s. We maybe see a slow increase in memory usage over time, but we think it is more pronounced in 1.2 because we Sawtooth+PBFT is faster.

amundson (Wed, 12 Jun 2019 15:48:46 GMT):
AFAIK, Raft may not pass the same level of testing under load, but it does not matter for the upcoming release of Sawtooth because we aren't planning on making any claims about Raft stability.

amundson (Wed, 12 Jun 2019 15:50:26 GMT):
PoET on the other hand... it needs more LR7 testing for sure, and work to fix some apparent issues with poet-engine. Nodes drop out of the network.

amolk (Wed, 12 Jun 2019 16:08:53 GMT):
@amundson We have a test suite that's meant to exercise Sawtooth via the REST interface. By and large most test cases are applicable across the board and not dependent on the consensus mechanism. The outcome of some of the tests depends on the consensus being used (e.g. a RAFT follower may keep an invalid transaction in queue and not return a transaction failure unlike a PoET validator). We've used this test suite for the 1.1 release, for Raft and now for PBFT on the 1.2 branch. The only findings to note are that for some malformed messages trying to read state, the client gets back an 'Internal Server Error' instead of a meaningful return code. These are not new and we've classified them as low severity.

amundson (Wed, 12 Jun 2019 16:12:30 GMT):
@amolk have you entered tasks in JIRA for them, or do you mean internally?

rranjan3 (Wed, 12 Jun 2019 16:22:00 GMT):
Has joined the channel.

amolk (Wed, 12 Jun 2019 16:24:08 GMT):
STL-1371, although now that I look at it, the description needs to be meaningful

amolk (Wed, 12 Jun 2019 16:24:52 GMT):
RAFT and PBFT are stable so far 12+ hours into the LR1. Both are on 10 node networks.

amundson (Wed, 12 Jun 2019 16:25:16 GMT):
@amolk what load?

amolk (Wed, 12 Jun 2019 16:25:32 GMT):
Nominal load of 10TPS

amundson (Wed, 12 Jun 2019 16:25:40 GMT):
that's not high enough IMO

amundson (Wed, 12 Jun 2019 16:26:29 GMT):
but, like I said, we did PBFT under the max load it can handle. it's good. but I think that low load is why Raft is succeeding?

amundson (Wed, 12 Jun 2019 16:27:02 GMT):
the load should be set right below what it's capable of processing on the given hardware configuration (all the bugs seem to come out then)

amundson (Wed, 12 Jun 2019 16:27:29 GMT):
(but again, I'm less worried about Raft passing)

amolk (Wed, 12 Jun 2019 16:28:16 GMT):
We'll keep increasing the load in subsequent runs. We're running PBFT for the first time and haven't run Raft in a while so not sure how any validator changes might affect it.

amundson (Wed, 12 Jun 2019 16:28:17 GMT):
for PoET, maybe at least do 20TPS? can you replicate problems with it at 10TPS?

amolk (Wed, 12 Jun 2019 16:29:33 GMT):
We're seeing some intermittent failures in summarize block for PoET. Had seen them in Raft as well long ago.

amundson (Wed, 12 Jun 2019 16:29:37 GMT):
what workload generator are you using? intkey?

amolk (Wed, 12 Jun 2019 16:30:08 GMT):
intkey mainly. On another test network we're using intkey+smallbank

amundson (Wed, 12 Jun 2019 16:30:12 GMT):
increasing the load might help the failures come out faster

amundson (Wed, 12 Jun 2019 16:31:17 GMT):
I'm curious if there is a difference between 1.1 and 1.2 in this respect

amundson (Wed, 12 Jun 2019 16:32:21 GMT):
some of our comparison testing between 1.1 and 1.2 wsn't possible as 1.1 can't handle the same level of testing as we are now doing in 1.2

amundson (Wed, 12 Jun 2019 16:32:43 GMT):
but I'm not sure that comparison has been done w/PoET engine

rranjan3 (Wed, 12 Jun 2019 16:35:16 GMT):
Have witnessed the FutureTimeoutError on summarize call (@Amol pointed) in 1.1.5. Yet to verify on latest(1.2).

Dan (Wed, 12 Jun 2019 16:36:33 GMT):
PoET error: ```Jun 07 21:19:10 lr7b-node0 sawtooth-validator[5616]: [2019-06-07 21:19:10.805 ERROR (unknown file)] [src/journal/chain.rs: 1060] An error occurred while committing block Block(id: 531fad52d0f934b48358f50e9ef58e25ca646e8c2e9a6545672a26bda885f3ca59b07bd0721ec5f3882fb8755af1b7c9589b1accbef225c82e85f9706f0a6a3c, block_num: 75, state_root_hash: 5de40966fbc596127acaf7b2fab15ff6dfee9cd4dba32c9e0c893f9238d9271e, previous_block_id: 63f903f4aa5ef8391f22153aeb10d0cec1f69510a864a60a8c897c89d14d23d36dd135b1892c91fa20bc8e50e067af4e9d656f398d09b1f7e9e94dae747b8b20): ConsensusError("Consensus has already decided on this block") Jun 07 21:20:30 lr7b-node0 sawtooth-validator[5616]: [2019-06-07 21:20:30.454 WARNING (unknown file)] [src/journal/block_validator.rs: 272] Block 80682f1c9877cbf455db8b5e0974a5e359414f9a1565864d28f51a4a4e67399d139356a10b9d9fa41e0e50de0c84cf6e5a90fbecbc7f5050c18195bba6e8d2b2 failed validation: Validation failure, duplicate batch 2676315dfaea044b00670920c52fe6e6c3a540b794fb53ccba9542f4940640e1457092a884b2255c0606b1de9ad33cc74fd167d440bbc77aad8116ba05d400ac```

amolk (Wed, 12 Jun 2019 17:10:29 GMT):
@amundson what are the recommended settings for PBFT for load and configuration?

amundson (Wed, 12 Jun 2019 17:12:28 GMT):
try 40 tps

amundson (Wed, 12 Jun 2019 17:12:55 GMT):
depending on your hardware, might be able to push that up

ltseeley (Wed, 12 Jun 2019 18:03:16 GMT):
@amolk for PBFT (and Raft), you'll definitely want to set `sawtooth.gossip.time_to_live=1` to disable broadcasting (since the networks are fully peered).

ltseeley (Wed, 12 Jun 2019 18:03:16 GMT):
@amolk for PBFT (and Raft), you'll definitely want to set `sawtooth.gossip.time_to_live=1` to disable re-broadcasting (since the networks are fully peered).

VishalBatra (Thu, 13 Jun 2019 02:19:04 GMT):
Has joined the channel.

VishalBatra (Thu, 13 Jun 2019 05:15:18 GMT):
Hi, may I request the team here to publish the next version of Java SDK? This upcoming version has APIs for deleting State and application-specific events which we need urgently in our project. Thanks.

amolk (Thu, 13 Jun 2019 06:16:49 GMT):
Raft and PBFT have passed the initial LR1 runs. No issues detected in either of the networks.

arsulegai (Thu, 13 Jun 2019 08:38:56 GMT):
@Dan This is different from what we've observed in our runs, did you observe it in long run tests? How do we get more info to debug?

arsulegai (Thu, 13 Jun 2019 10:20:35 GMT):
@ltseeley setting sawtooth.gossip.time_to_live=0 should also work, the issue with it is fixed in 1.2

Dan (Thu, 13 Jun 2019 13:38:17 GMT):
@arsulegai , i got it from @jsmitchell

amolk (Fri, 14 Jun 2019 13:31:15 GMT):
An updated LR1 for PBFT on a 10 node network at 40TPS has completed successfully.

jsmitchell (Fri, 14 Jun 2019 16:18:36 GMT):
👏🏻

amundson (Mon, 24 Jun 2019 18:21:16 GMT):
@amolk any progress on testing poet w/1.2?

rbuysse (Wed, 26 Jun 2019 18:00:54 GMT):
I'm going to be tagging most of the sawtooth github repos in the next couple days.

rbuysse (Wed, 26 Jun 2019 18:01:23 GMT):
If anyone's doing development and comes across an error like `ERROR: VERSION file and (bumped?) git describe versions differ:`, after fetching tags and rebasing on master you should be good to go.

arsulegai (Thu, 27 Jun 2019 05:17:57 GMT):
Isn't it normal for a block to be rejected, then the sender of the block needs to fork to the version which other nodes are at.

pankajgoyal (Thu, 27 Jun 2019 06:37:28 GMT):
LR run status on PBFT: ==================== Hardware: NUC, ubuntu 18.04 I/P TPS: 40 TPS (20 intkey + 20 smallbank) sawtooth packages version: 1.2.1~dev615-1 pbft package version: 0.1.4-dev24 python sdk version: 1.2.2~dev15-1 PBFT settings: ============= sawtooth.consensus.algorithm.name=pbft sawtooth.consensus.algorithm.version=0.1 sawtooth.gossip.time_to_live=1 sawtooth.consensus.pbft.block_duration=100 sawtooth.consensus.pbft.view_change_timeout=4000 sawtooth.consensus.pbft.message_timeout=10 sawtooth.consensus.pbft.max_log_size=1000 Observation: One node had backpressure after ~4.5 hours of run and got out of network. Pending batches is increasing for all other nodes. Grafana: http://52.66.91.194:3000/d/dRHP9TDik/dashboard?orgId=1&from=1561558284895&to=1561601484000&var-DATASOURCE=metrics_sawtooth_1_2

pankajgoyal (Thu, 27 Jun 2019 06:38:47 GMT):

40TPS-sawtooth1.2-pbft.png

amolk (Thu, 27 Jun 2019 06:41:24 GMT):
Seeing some issues with PBFT

ltseeley (Thu, 27 Jun 2019 12:55:23 GMT):
Anything interesting in the logs around the time the first node stopped making progress?

pankajgoyal (Fri, 28 Jun 2019 03:32:59 GMT):
It is back pressure that occurred. Message like: [00:11:49.455 [ThreadPoolExecutor-7_0] ffi INFO] [src/journal/chain.rs: 557] Failed block Block(id: 41c55363519ceb0aa5a2db33073ea5088d6410f20fbf4e39065905e9b94591e82a6fc7f02cf2efcbe5e4224c979e5f000f9583139e76a0da04bca920d295d044, block_num: 15303, state_root_hash: fe42e39a015b2f08e2214253bd13ef907f3c389bf3a6235364b33aa9ab256d05, previous_block_id: 9f7800201df2e95d29055453b845691db9b2077408cec0f41961f8eb66cd08ac71806f2296d662b598ddb0c2761e1d11a671c686fd4b4de607bffdf300200cfe) [00:11:49.537 [ThreadPoolExecutor-2_4] back_pressure_handlers INFO] Applying back pressure on client submitted batches: current depth: 500, limit: 500

ltseeley (Fri, 28 Jun 2019 13:16:18 GMT):
Backpressure is usually symptom of something else going wrong; the node can't commit blocks/batches for some reason. Can you check the PBFT logs to see what happened around that time? Also, are there any errors in the validator?

amundson (Fri, 28 Jun 2019 14:20:34 GMT):
I'm curious if the validator was restarted there

amolk (Fri, 28 Jun 2019 21:33:31 GMT):

validator-debug.zip

amolk (Fri, 28 Jun 2019 21:33:35 GMT):
Validator wasn't restarted. Attaching logs for the validator that fell out of sync. Look from Block number 15400.

ltseeley (Mon, 01 Jul 2019 17:16:34 GMT):
It starts failing all blocks starting at block 15293. Can you see why PBFT failed block 15293?

ltseeley (Mon, 01 Jul 2019 17:16:39 GMT):
@amolk

RealDeanZhao (Wed, 10 Jul 2019 06:06:05 GMT):
Hi, any news of sawtooth 1.2? When will it be released?

arsulegai (Wed, 10 Jul 2019 06:07:03 GMT):
Soon :relaxed:

RealDeanZhao (Wed, 10 Jul 2019 06:08:56 GMT):
:grinning:

amundson (Wed, 10 Jul 2019 15:51:41 GMT):
@RealDeanZhao the release is blocked on a regression which shows up during PoET long-running network testing (PBFT runs do not exhibit the same issue). once that's resolved, it should not take long for the release to be official.

arsulegai (Wed, 10 Jul 2019 16:42:33 GMT):
There are interesting observations with 1.2 release candidate

arsulegai (Wed, 10 Jul 2019 16:43:55 GMT):
1. We observe a KeyError issue (a side effect of validator sending duplicate block to consensus engine) in validator version 1.2 but not on latest master build or earlier 1.1 validator

arsulegai (Wed, 10 Jul 2019 16:44:34 GMT):
2. There are too many forks on 1.2 when compared to 1.1, with same PoET binary

Dan (Wed, 10 Jul 2019 16:59:27 GMT):
I want to make sure we are aligned on what build is being tested. It looks like we've continued to have doc backports but the last coding change is ~June 28. https://build.sawtooth.me/job/Sawtooth-Hyperledger/job/sawtooth-core/job/1-2/changes @arsulegai do you know which build your LR is executing?

arsulegai (Wed, 10 Jul 2019 18:19:00 GMT):
I will take a step back here before commenting more. However as pasted in #sawtooth-core-dev along with logs, the KeyError issue logs I have is for validator version 1.3.1-dev12-dirty

Dan (Wed, 10 Jul 2019 18:30:22 GMT):
1.3.1 sounds like master

Dan (Wed, 10 Jul 2019 18:30:58 GMT):
1.2: https://github.com/hyperledger/sawtooth-core/blob/1-2/VERSION master: https://github.com/hyperledger/sawtooth-core/blob/master/VERSION

arsulegai (Wed, 10 Jul 2019 18:54:25 GMT):
There's one more log with version version 1.2.1-dev615-dirty which has seen the KeyError issue

arsulegai (Thu, 11 Jul 2019 08:22:24 GMT):
Ok, now I am confident on receiving the duplicate block from validator. It's seen in yesterday's nightly 1.2 build as well

arsulegai (Thu, 11 Jul 2019 14:24:46 GMT):
I created an issue in Jira to track it https://jira.hyperledger.org/browse/STL-1664

arsulegai (Fri, 12 Jul 2019 03:17:34 GMT):
Clarification on point 1 of my earlier message. The validator sends duplicate block on latest master as well, just that it didn't end up in KeyError issue. It's however messing up the state machine in the PoET. https://github.com/hyperledger/sawtooth-poet/pull/38 handles and solves the issue because of validator's changed behavior.

arsulegai (Fri, 12 Jul 2019 03:22:57 GMT):
Clarification on point 2: We found a suitable configuration settings for the 10 node network to run smoothly.

Dan (Fri, 12 Jul 2019 19:22:38 GMT):
Reviewed and merged #38. I guess we need to backport that to 1-2.

arsulegai (Sat, 13 Jul 2019 05:40:45 GMT):
1-1, 1-2, master all share the same PoET and this change has no effect on 1-1. With earlier versions of Sawtooth, this issue doesn't occur at Validator. However doesn't harm to backport to 1.0, shall I?

Dan (Sun, 14 Jul 2019 15:55:32 GMT):
oh I don't know what I was thinking. no need to backport.

Dan (Sun, 14 Jul 2019 15:56:41 GMT):
Are we all set now for Chime / 1.2 with PoET LR success or is there still some regression to be resolved?

arsulegai (Mon, 15 Jul 2019 11:23:13 GMT):
PoET-SGX shows stability at 10tps

pschwarz (Mon, 15 Jul 2019 15:35:45 GMT):
How long of a run?

arsulegai (Mon, 15 Jul 2019 15:46:56 GMT):
LR1 completed

arsulegai (Mon, 15 Jul 2019 15:47:11 GMT):
(with the pending patches in sawtooth-poet repository)

Dan (Tue, 16 Jul 2019 14:17:11 GMT):
@arsulegai reports that the LR testing is looking good. We have one PR in sawtooth-poet that needs a tweak and then that is the last thing on my end that is holding up `chime`.

arsulegai (Thu, 18 Jul 2019 09:15:45 GMT):
Question: It came up during app developers' forum and somebody asked a update procedure. There was a PR raised for it and merged to sawtooth-website but it's not reflected in website still. Anything wrong? https://github.com/hyperledger/sawtooth-website/commit/fc691c8e1b084fddb2f35c52b003a013049231f3

arsulegai (Thu, 18 Jul 2019 09:15:45 GMT):
Question: It came up during app developers' forum and somebody asked a question on points to consider while updating Sawtooth. There was a PR raised for it and merged to sawtooth-website but it's not reflected in website still. Anything wrong? https://github.com/hyperledger/sawtooth-website/commit/fc691c8e1b084fddb2f35c52b003a013049231f3

rbuysse (Thu, 18 Jul 2019 14:36:10 GMT):
Hm, isn't this it? https://sawtooth.hyperledger.org/faq/upgrade/

arsulegai (Thu, 18 Jul 2019 14:55:39 GMT):
I couldn't find it from FAQ main page https://sawtooth.hyperledger.org/faq/

arsulegai (Thu, 18 Jul 2019 14:55:53 GMT):
* find a link for it from

arsulegai (Thu, 18 Jul 2019 14:56:03 GMT):
Thanks

danintel (Thu, 18 Jul 2019 23:54:23 GMT):
@arsulegai If your PR added a page, you need to add it to https://github.com/hyperledger/sawtooth-website/blob/master/generator/source/faq/faq.rst Also updates to sawtooth-website are not immediate.

arsulegai (Fri, 19 Jul 2019 03:00:51 GMT):
Right, I realised it late

danintel (Fri, 19 Jul 2019 16:22:42 GMT):
I should have caught it when reviewing it--sorry.

rberg2 (Tue, 06 Aug 2019 18:46:06 GMT):
Hello all, transact 0.1.5 has been released to crates.io

amundson (Tue, 06 Aug 2019 20:07:09 GMT):
@rberg2 you should mention that is #transact

VishalBatra (Thu, 08 Aug 2019 03:22:35 GMT):
Hi, any update on when the next version of the Java SDK for Sawtooth planned for release? The new version has support for two important features - deleting an address and application-specific events.

danintel (Thu, 08 Aug 2019 09:26:43 GMT):
@VishalBatra The SDK should appear with the rest of the Sawtooth release

VishalBatra (Thu, 08 Aug 2019 09:41:19 GMT):
Ok, thank you very much. Is there a tentative date planned for this release?

arsulegai (Thu, 08 Aug 2019 09:51:11 GMT):
August 13 was the earlier planned date, but now it's postponed by 2 weeks.

amundson (Thu, 08 Aug 2019 14:25:20 GMT):
(a minimum of 2 weeks, we haven't picked a new date yet)

amundson (Thu, 08 Aug 2019 14:27:39 GMT):
but, the SDK point releases are actually independent of the overall release. @rberg2 ^ java sdk release request

rberg2 (Thu, 08 Aug 2019 18:16:32 GMT):
Hello, I did a release of the java sdk version 0.1.3 on Jun 28 2019. I do not see any code changes since that release. Is anything missing from 0.1.3 that you expect to be there?

arsulegai (Fri, 09 Aug 2019 09:27:00 GMT):
@VishalBatra ^

LeonardoCarvalho (Sat, 10 Aug 2019 17:10:24 GMT):
I see the tag v0.1.3, withe the VERSION bumped to 0.1.3, but the POM and Readme showing v0.1.2 ,,,

rberg2 (Mon, 12 Aug 2019 14:16:38 GMT):
I believe the POM is changed with the command `mvn versions:set -DnewVersion=v0.1.3` during release

amundson (Mon, 12 Aug 2019 15:18:08 GMT):
Still, the versions should be kept in sync. To match what we do everywhere else, the version in the repo at HEAD should be the next version (the one not yet released).

rberg2 (Mon, 12 Aug 2019 16:07:20 GMT):
kk I made a note in the release docs to do that. looking at one of the released pom files it did get updated during release, so I don't think that's a problem. https://repo1.maven.org/maven2/org/hyperledger/sawtooth/sawtooth-sdk-protos/v0.1.3/sawtooth-sdk-protos-v0.1.3.pom

arsulegai (Fri, 23 Aug 2019 14:44:20 GMT):
Is PBFT deb available?

rbuysse (Fri, 23 Aug 2019 14:53:58 GMT):
yep, it should be in all the repos except 1.0

arsulegai (Fri, 23 Aug 2019 15:58:31 GMT):
👍 thanks

Atlowell (Mon, 23 Sep 2019 18:14:03 GMT):
Has joined the channel.

Atlowell (Mon, 23 Sep 2019 18:14:48 GMT):
Hello all, is there a release notes document somewhere which describes the major features/fixes of each release?

arsulegai (Tue, 24 Sep 2019 05:39:36 GMT):
@Atlowell here you go https://sawtooth.hyperledger.org/release/

Atlowell (Tue, 24 Sep 2019 14:28:53 GMT):
@arsulegai Thanks!

Atlowell (Tue, 24 Sep 2019 14:29:02 GMT):
Does anyone know when it will be updated with 1.2 or 1.3?

pankajgoyal (Mon, 30 Sep 2019 12:57:30 GMT):
I am facing a strange issue with Jenkins today. If I want to make a change in Manage Jenkins -> Configure System and tries to save it, it doesn't save that. It tries for some time and then throws network error. I tried to create Jenkins server on 2 different machines and both have the same behaviour. Any leads will be appreciated.

rbuysse (Fri, 07 Feb 2020 20:04:11 GMT):
PBFT 1.0.2 has been released. You can read the release notes here: https://github.com/hyperledger/sawtooth-pbft/blob/v1.0.2/RELEASE_NOTES.md

arsulegai (Sat, 08 Feb 2020 09:52:28 GMT):
^ @VishalBatra

VishalBatra (Mon, 10 Feb 2020 05:39:40 GMT):
Thank you @arsulegai Upgraded our nodes to use the latest version

ltseeley (Tue, 11 Feb 2020 18:15:52 GMT):
I'd like to request a new Rust SDK release (v0.4.1) to make changes from https://github.com/hyperledger/sawtooth-sdk-rust/pull/39 and https://github.com/hyperledger/sawtooth-sdk-rust/pull/40 available

ltseeley (Tue, 11 Feb 2020 18:16:41 GMT):
Also a Sawtooth Sabre (v0.5) release

ltseeley (Wed, 12 Feb 2020 15:48:59 GMT):
Also want to request a libsawtooth release

rbuysse (Wed, 12 Feb 2020 16:21:01 GMT):
I'll get that taken care of this week.

rbuysse (Wed, 12 Feb 2020 23:00:29 GMT):
A new version (0.5.0) of sawtooth-sabre has been released. You can view the release notes at https://github.com/hyperledger/sawtooth-sabre/blob/v0.5.0/RELEASE_NOTES.md

rbuysse (Thu, 13 Feb 2020 21:25:05 GMT):
A new version (0.5.1) of sawtooth-sabre has been released. You can view the release notes at https://github.com/hyperledger/sawtooth-sabre/blob/v0.5.1/RELEASE_NOTES.md

rbuysse (Fri, 14 Feb 2020 19:58:52 GMT):
A new version (0.4.1) of the sawtooth-rust-sdk has been released. You can view the release notes at https://github.com/hyperledger/sawtooth-sdk-rust/blob/v0.4.1/RELEASE_NOTES.md

rbuysse (Tue, 18 Feb 2020 21:31:38 GMT):
A new version (0.2.2) of Transact has been released. You can view the release notes at https://github.com/hyperledger/transact/blob/v0.2.2/RELEASE_NOTES.md

rbuysse (Thu, 20 Feb 2020 21:17:01 GMT):
A new version (0.2.3) of Transact has been released. You can view the release notes at https://github.com/hyperledger/transact/blob/v0.2.3/RELEASE_NOTES.md

ltseeley (Tue, 25 Feb 2020 17:37:26 GMT):
Requesting a new sabre release because of the fixes here: https://github.com/hyperledger/sawtooth-sabre/pull/102/

arsulegai (Mon, 09 Mar 2020 11:21:41 GMT):
Requesting a new tag for PoET repository with this commit included https://github.com/hyperledger/sawtooth-poet/commit/754766d35fe24837d68afe9e848568b26fb1065b

arsulegai (Mon, 09 Mar 2020 11:21:51 GMT):
@lucgerrits ^

lucgerrits (Mon, 09 Mar 2020 11:21:51 GMT):
Has joined the channel.

agunde (Tue, 10 Mar 2020 12:39:55 GMT):
@rbuysse ^

rbuysse (Tue, 10 Mar 2020 16:20:25 GMT):
@arsulegai sounds good, I'll get that out either tomorrow or monday.

ltseeley (Fri, 01 May 2020 18:36:09 GMT):
Requesting a new patch release of the Sawtooth Rust SDK because of the stabilization of the `transact-compat` feature.

RajaramKannan (Tue, 26 May 2020 05:36:28 GMT):
Has joined the channel.

johnfranklin (Tue, 02 Jun 2020 04:33:23 GMT):
Has joined the channel.

jmbarry (Tue, 16 Jun 2020 17:32:11 GMT):
Has joined the channel.

pschwarz (Thu, 23 Jul 2020 22:13:26 GMT):
I'd like to request a new sawtooth rust sdk release

ParitoshPandey (Thu, 27 Aug 2020 17:54:20 GMT):
Has joined the channel.

danintel (Tue, 06 Oct 2020 18:53:16 GMT):
Has left the channel.

ajayjadhav (Wed, 14 Oct 2020 19:13:15 GMT):
Has joined the channel.

rjones (Wed, 23 Mar 2022 17:35:59 GMT):