## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
• Mar 15 16:55
dependabot[bot] labeled #93
• Mar 15 16:55
dependabot[bot] opened #93
• Mar 15 16:55

dependabot[bot] on nuget

Bump Microsoft.Data.OData in /t… (compare)

• Mar 15 16:55
dependabot[bot] labeled #92
• Mar 15 16:55
dependabot[bot] labeled #91
• Mar 15 16:55
dependabot[bot] opened #92
• Mar 15 16:55
dependabot[bot] labeled #90
• Mar 15 16:55
dependabot[bot] opened #91
• Mar 15 16:55

dependabot[bot] on nuget

Bump Microsoft.Data.OData from … (compare)

• Mar 15 16:55
dependabot[bot] opened #90
• Mar 15 16:55

dependabot[bot] on nuget

Bump Microsoft.Data.OData in /t… (compare)

• Mar 15 16:55

dependabot[bot] on nuget

Bump Microsoft.Data.OData from … (compare)

• Mar 15 16:54
dependabot[bot] labeled #89
• Mar 15 16:54
dependabot[bot] opened #89
• Mar 15 16:54

dependabot[bot] on nuget

Bump Microsoft.Data.OData in /S… (compare)

• Mar 15 16:54
dependabot[bot] labeled #88
• Mar 15 16:54
dependabot[bot] opened #88
• Mar 15 16:54

dependabot[bot] on nuget

Bump Microsoft.Data.OData in /t… (compare)

• Mar 15 16:51
dependabot[bot] labeled #87
• Mar 15 16:51
dependabot[bot] labeled #86
Jakub Konecki
@jkonecki
NP ;-)
Jakub Konecki
@jkonecki
Hi @nehmebilal - I'm happy with your changes, all tested OK
@onionhammer I LOVE yamslocal - such a brilliant little tool! I have 6 apps running at the same time, I can make a change in code, compile solution and only affected apps will restart! Huge time saver! I've just written an internal wiki page telling all my coworkers to use it ;-)
Nehme Bilal
@nehmebilal
Great!
I also just added CI build using VSTS with a badge on Github page
didn't know that VSTS had github integration :)
I'll try to publish a release tomorrow
Nehme Bilal
@nehmebilal
I will most likely move the build to AppVeyor because VSTS builds cannot be accessed publicly
Jakub Konecki
@jkonecki
I also just added CI build using VSTS with a badge on Github page
Awesome!
onionhammer
@onionhammer
@jkonecki glad you found it useful
Nehme Bilal
@nehmebilal
I haven't get the chance to play with it yet but indeed it looks pretty cool!
Nehme Bilal
@nehmebilal
@jkonecki Latest nugets published
onionhammer
@onionhammer
whats new?
Nehme Bilal
@nehmebilal
@onionhammer mainly the way upgrade domains are rolled. I will published a github Release soon to describe the changes
1.8 is very similar to 1.7 plus the logging improvements that @jkonecki did
Nehme Bilal
@nehmebilal
Nehme Bilal
@nehmebilal
Heads up, there was a bug in 1.7/1.8 preventing the nodes from updating the status blob every 5 seconds (instead the blob was only updated when something changes in the cluster). Some will see that as a feature but I fixed it in 1.8.1
Jakub Konecki
@jkonecki
PR #72 is ready for review. Publishing packages using NuGet SDK is a pita, especially since NuGet team 'is hard working on documentation' for over a year now :-(
I imagine that in most cases packages will be pushed to NuGet feed by the build server - I agree that it would be nice to have it supported.
Nehme Bilal
@nehmebilal
@jkonecki Looks great! I added some minor comments, nothing blocking. Let's figure out how we want to package/distribute it and then we can merge it in
Jakub Konecki
@jkonecki
I want to beta test it with my system before release
Nehme Bilal
@nehmebilal
:+1:
Yevhen Bobrov
@yevhen
@jkonecki what this YamsLocal tool is doing and where to find it?
Jakub Konecki
@jkonecki
It runs the cluster on local machine in a separate folder - when you compile locally it will pick up dlls from bin\Debug and copy them to separate folder and run the apps from there. It means that when you recompile the files are not locked, and Yams Local will notice the changes, shut down the app, copy files and start the app again
You create a console app and add a nuget package
Yevhen Bobrov
@yevhen
Nice!
Jakub Konecki
@jkonecki
I've experienced an issue with updates today - for a reason unknown one of the nodes (Update Domain 1) finished an update session but didn't remove an entry from Yams Update Session Table - that caused the other node (Update Domain 0) to keep downloading the apps and failing to obtain the session. Node in UD1 was working happily without releasing the session (I assume it noticed that there are no updates pending as all apps were updated successfully).
Issue may have been caused by me deploying a new version of Cloud Service or instance rebooting during update.
Maybe we should consider adding addtional checks to YamsHost to release any orphaned update sessions? I solved the problem my changing updateDomain entry from 1 to 0.
Nehme Bilal
@nehmebilal
@jkonecki this can happen if the nodes fails to update the table after finishing updating (e.g. node crashes). The current solution is using a ttl on the entry added by the node. In fact, after some configurable ttl, the entry from the node that crashed will be ignored and other update domains will be able to start
However, it's a bit tricky to find a good value for the ttl because it also has to be long enough to give the node a chance to finish updating
One solution would be to take the health of the node into account.. if the nodes have not reported healthy, ignore the entries from that node
btw this issue would have also happen with the old way of using an update blob, so it's not a regression
Nehme Bilal
@nehmebilal
Looking at the code:
            // We will only end the update session if the update was successful. Otherwise, the update session will stay open and will prevent
// the deployment from moving to the next update domain.
await _updateSessionManager.EndUpdateSession(); 
it's also possible that something went wrong with your update
we need to document a simple way of unblocking the update however,, one simple option would be to deploy a new version
Nehme Bilal
@nehmebilal
it's actually a choice that we have to make, we either consider the node dead or we block the update until someone manually intervenes (to avoid breaking the whole cluster)
Jakub Konecki
@jkonecki
Looking at my logs, it may have been a failed deployment that stopped the session from ending - the sideeffect is that CheckUpdate keeps downloading the apps, which cause Windows Defender scans, which takes CPU to 100%
I really need to finish support for nuget packages - downloads will be smaller to begin with ;-)
My orleans cluser unpacked is over 100MB
Nehme Bilal
@nehmebilal
Jakub Konecki
@jkonecki
Agree
Nehme Bilal
@nehmebilal
@jkonecki You mentioned above that the NuGet repo will allow you to avoid downloading the package multiple times when the update domain is blocked. I am wondering why? I believe that Yams will download and extract the package anyway, even if it already did because it can't be sure that the package is fully downloaded/extracted (e.g. the node crashed while extracting the package)
Jakub Konecki
@jkonecki
I only said the download will be smaller. It will still be happening multiple times as with blob. NuGet package in my case is 25% of the size of binaries
Nehme Bilal
@nehmebilal
Ok sounds good.. the downside however is that you won't be able to implement a differential download with nugets
justmara
@justmara
is there any way to start .net core app with yams? without building it as self-contained ;)
Nehme Bilal
@nehmebilal
@justmara If the app has all the dependencies it needs, it will start.. Yams does not manage app dependencies, it will just start the app for you as an exe based on the way you configure it
justmara
@justmara

@nehmebilal .netcore app isn't self-running, it is started via dotnet myapp.dll command. So one must configure AppConfig.json with somehing like this:

  "ExeName": "C:\\Program Files\\dotnet\\dotnet.exe",
"ExeArgs": "myapp.dll",

but this way it fails to start because of space in path :) If you move your dotnet folder it won't start anyway because Yams tries to start it, using dotnet.exe's folder as startup folder - so sure it cannot find my dll. So it goes like some strange dance with path's/files combinations.. Which I've failed and just built it as self-contained, until we migrate to linux and forget about yams totally.

Nehme Bilal
@nehmebilal
@justmara Right. I believe YAMS assume that this is an ExeName and not a path but that's probably not so hard to fix.. you can also use a script instead of an exe or dll in your app and make the script call dotnet myapp.dll