text:
Mismatch between the marketplace and the cli when publish a service

When we deploy a service from the CLI the link is not the same than the one on the Marketplace
CLI:
✔ Service published with success with sid "testservice" and marketplace hash "Cxy3D19E9hWmmNxRU7WXaV73mJ3bvTwDp6PMAYyW7LYF"
✔ See it on the marketplace: https://marketplace.mesg.com/services/testservice/Cxy3D19E9hWmmNxRU7WXaV73mJ3bvTwDp6PMAYyW7LYF

Marketplace:
https://marketplace.mesg.com/services/testservice/DMBeya65nkMmt3UCTnJ7C2KJH2SXeYTSbRx9GxSf2YXq

Here is the tx for this transaction https://ropsten.etherscan.io/tx/0xc2399171bd382b5a14e09be1bb566a4617feca7368ffe285d7df4a82797bb0f4

The CLI is using the marketplace service version hash for the link.
The website is using the service hash (the one output by command service deploy for example).

Which one should we use?
It makes sense to use the service hash and keep the marketplace hash as internal system only.
BUT, on the current marketplace, the service hash alone is not unique. The combination of sid, ipfs hash of the manifest data and the address of the sender needs to be unique.
If the website always require the sid and the service hash, then it's fine.

But in order to deploy a service using the marketplace URL:
mesg-core service deploy mesg://marketplace/service/9TpMWrifmGM99vE3YN7mbY8UEt7TdL9Y1GPoPoxojHeu

It's currently use the marketplace version hash (for unicity).
We could switch to sid + service hash if we want to use the same system for the website and deployment.

After discussion with Anthony, this is a website issue.
The website should use the versionHash instead of the service's hash.

Move to marketplace website repo https://github.com/mesg-foundation/marketplace.mesg.com/issues/15

repo: mesg-foundation/core


text:
[mesheryctl] Build check failure: Golang Unit Test

See mesheryctl Command Tracker for current status of commands.
Current Behavior
The Golang unit tests are failing in this build check - https://github.com/meshery/meshery/runs/4674993078?check_suite_focus=true

Contributor Resources

mesheryctl Contributing Guide
Beginner's guide to contributing to Meshery and mesheryctl
mesheryctl Command Tracker
Meshery CLI Commands and Documentation
🙋🏾🙋🏼 Questions: Layer5 Discussion Forum and Layer5 Community Slack

I can take this up @leecalcote 💯

This would be excellent, @unnati914. Let's give you a beat to tie-off other assignments currently on your plate, and then, get this one assigned straight-away.

sure 🥇

Old issue, actions are passing now.

source: gharchive/issue

authors: leecalcote piyushsingariya unnati914

repo: meshery/meshery

license_type: permissive

license_source: github-api


text:
Deploy preview test

Signed-off-by: Lee Calcote lee.calcote@layer5.io
Description
This PR fixes #
Notes for Reviewers
Signed commits

[ ] Yes, I signed my commits.

🚀 Preview for commit b4f769bc0667d2b099b1176e1ced5078e51e6143 at: https://630787d1d3714f0dd6fa1e19--meshery-docs-preview.netlify.app

source: gharchive/pull-request


text:
[Docs] Improve REST API Docs Legibility

Notes for Reviewers
This PR fixes #7365
Completed bellow desired state in this PR

Improve mockup of these API docs to use brand-appropriate colors.
Improve information architecture in the Description (too much bold text, not enough bullets, no code <code> markup, no hyperlinks, and so on).

Current state.

Signed commits

[x] Yes, I signed my commits.

🚀 Preview for commit 5ae9260648d085df2452634697a14bc39ddd3b7d at: https://6416ced10327f1181607b76e--meshery-docs-preview.netlify.app

@ritiksaxena124 would you like to review?

Thanks, @senali-d!
The greens used here are not within brand coloring.

🚀 Preview for commit bf663aa2436a06ace11acbff59edd586d05dbd2d at: https://641861449d0f4346e68a698e--meshery-docs-preview.netlify.app

Current:

Your version:

@vishalvivekm Thanks for the feedback.
OK. Let's keep them as it is in the current version.

🚀 Preview for commit 8b2e770fa8ab24e2f8346df71d8b5c2308fbbb82 at: https://6418854dc816976a9b3a490d--meshery-docs-preview.netlify.app

Thanks, @senali-d 👍

hey, @senali-d you did great work, but we still have some typo issues. it would be great if you fix those as well

Sure. I'll fix them.

🚀 Preview for commit f400c4b694adfa8093b0194ea049abc3441b0c84 at: https://641afd2d2268470830e66d3a--meshery-docs-preview.netlify.app

@ritiksaxena124 Fixed typo issues mention in the above comment.

Merge conflicts...

Great work @senali-d 👏

🚀 Preview for commit 09cb170c1475a2b4fa5cbde30b301a509111f16a at: https://6421cc42e3015f164f822211--meshery-docs-preview.netlify.app

@vishalvivekm Any feedback?

Codecov Report
Patch and project coverage have no change.

Comparison is base (9d6ed73) 16.06% compared to head (09cb170) 16.06%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##           master    #7368   +/-   ##
=======================================
  Coverage   16.06%   16.06%
=======================================
  Files         119      119
  Lines       16716    16716
=======================================
  Hits         2685     2685
  Misses      13543    13543
  Partials      488      488

Flag
Coverage Δ

e2etests
∅ <ø> (?)

gointegrationtests
5.58% <ø> (ø)

unittests
11.93% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

server/handlers/common_handlers.go
0.00% <ø> (ø)

server/handlers/component_handler.go
0.00% <ø> (ø)

server/handlers/fetch_results_handler.go
0.00% <ø> (ø)

server/handlers/meshery_application_handler.go
0.00% <ø> (ø)

server/handlers/meshery_pattern_handler.go
0.00% <ø> (ø)

server/handlers/oam_handler.go
0.00% <ø> (ø)

server/handlers/relationship_handlers.go
0.00% <ø> (ø)

server/handlers/schedule_handlers.go
0.00% <ø> (ø)

server/handlers/user_handler.go
0.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@vishalvivekm Any feedback?

Yeah, I'll be back with 'em soon, a lot to look in so.. :)

Eliminating merge conflict.

🚀 Preview for commit 17ab7224ee8a4a164a328e5abb749e8c67dcbb31 at: https://64261e7c1f98421e03eec720--meshery-docs-preview.netlify.app

authors: codecov-commenter goldfishdolphin l5io leecalcote ritiksaxena124 senali-d vishalvivekm


text:
[UI] Fixes along missing design-configurator header, and code cleanup

Notes for Reviewers
This PR fixes #
Signed commits

[x] Yes, I signed my commits.

@leecalcote Merging and releasing again.

let me wait for UI build before releasing (over confidence sucks)


text:
Speeding up loading of large projects

Doing some timing tests, I found it currently takes the CCLE project page ~15 seconds to load. While this may not seem like much, it is 15 seconds every time the project page is loaded, making it quite slow for users to go to the CCLE project page, check out a sample, go back to the CCLE project page, check out a different sample, and so on.
CCLE is just 329 samples. For TCGA or PCAWG (each ~2500 samples), or Genomics England (>16,000 samples), the load time for the project page will become far too long.
The timing tests revealed that the longest part of this process (~14 seconds) is the following lines of code:
    dfl = []
    samples = df['Sample_name'].unique()
    for sample in samples:
        project, sample_info = get_one_sample(project_name, sample)
        dfl.append(pd.DataFrame(sample_info))

    aggregate = pd.concat(dfl)

The call to get_one_sample is relatively expensive since it iterates over the entire set of samples and finds the one with the matching name.
        current = runs[sample_num]
        if len(current) > 0:
            if current[0]['Sample name'] == sample_name:
                 sample_out = current

We will need to optimize this process greatly to accommodate larger-scale datasets.

Fix was relatively simple, and is implemented in #97. Reduces loadtime of the CCLE project page from 15s to 1-2s (critical step reduced from 14s to 0.6s).

repo: mesirovlab/AmpliconRepository


text:
Add an "explanation for a 4 years old" of what the project is about

Hello @meson800 ,
I was a bit confused after reading through the readme, so I had a look at the code, and I am now even more confused.O_o
tame is an interesting package, but it is hard to understand how to use it; is it even usable at this time? I am not sure.
Thanks for clarifying a little bit.
Cheers

Thanks for the interest! I've gotten somewhat sidetracked in my own research, and had some classes to take last term. Next term I also have my PhD candidacy exam next term, so likely won't be super free to get this towards a version 1 in the next few months. I welcome help though!
As to the roadmap, it's not currently usable because there isn't actually a fully working CLI or GUI. A lot of the backend is written, so most of the functionality can be accessed via Python directly. There were some unexpected issues to solve (specifically, what if someone specifies a circular dependency? How do we handle that properly, or do we restrict people to non-circular methods? I chose the first, which involves a decent amount of graph algorithms.
Remaining tasks are then:

Check that inheritance works properly (e.g. you inherit your parents, such that it is searchable, so that you can do searches like 'which microscopy experiments involve this gene construct?').
Finish up the backend tests to make sure we don't trigger regressions.
Write a CLI interface.
Write read-the-docs style documentation so it's usable.
Write a GUI interface (currently I'm imagining something Zotero-like).

Hey, thanks for the quick reply.
I was looking at master, but the action is in the Develop branch; that's a bit more helpful.
I think tame might intend to do what I am looking for, but it is hard to tell: the project is in desperate need of a 20 lines explanation of what it intends to do precisely; right now, it assumes that the reader knows what good and bad habits biologists have; however, having no familiarity with that domain, I am still scratching my head after spending 30 minutes reading everything I could find, including the code in the 'not-so-obvious-to-find' branch.
I understand you are busy, but if you could find the time to push an 'explanation for a 4 years old', that would be of tremendous help to me, and to others too.
Cheers

To be fair, the develop branch stuff is a well known git layout called git flow that's been around for a while, but definitely point taken; I will add this to the README on master for those not familiar :)
I'll probably write up something within the next week. The current README is pretty much as you say, it was notes that I wrote up for myself for implementation sake, it's definitely not what I imagine the final documentation to be like.
For a short preview:
The basic question tame tries to answer is how to we add description and context to files we generate? Images come with embedded EXIF metadata that stores the camera settings, lens and sensor size, date, and even sometimes GPS location. Certain file formats like HDF5 allow you to create "self-descriptive" datasets, where everything you need to interpret the data is given within the file. This is not true for most files.
In the more biology realm, this could mean microscopy data, single-cell data, or sequencing data, where the full context (such as what organism did we use? Did we do any engineering modifications to it? What experimental conditions did we use?) is not included in the files we generate.
For more of a software engineering/sysadmin perspective, maybe we are making a log aggregator, which stores a bunch of log files from different servers. There's some obvious metadata that we might want to attach (which server a log file came from), but there is also less obvious stuff that would make sense to be inherited, like specific software configurations that servers might share. tame would let you do stuff like have a metadata file representing a server, which depends on other metadata files that define configurations for certain software. Then, you could do operations like "pull up all of the tracked log files for servers that are running an Apache webserver with version < x"
Tame is then a way of having human-editable metadata (stored in .yaml files). At it's most basic, you can assign arbitrary metadata tags (like name, or date last updated, or random strings, etc) to certain files, but there is enough power underneath to do these complex hierarchies (say logfile blah.log comes from server alpha, which itself has a certain python configuration and a different docker configuration). You can do all of this stuff just with a text editor, but tame then gives you the ability to search and operate on this rich metadata information.
That was the quick off-the-cuff version; does that make some more sense, or more basic? Also, can you describe what your usecase is more?

Wonderful, thank you! I think I better understand now.
My use case is to attach 'informal' (loosely defined?) metadata to the files underlying a text based notes management system; I think tame covers my needs; I'll take a closer look.
Cheers

If you don't need metadata hierarchy, you might just look into using YAML directly. It excels at doing this type of loosely defined metadata, so most of tame is just software tools for the complexities that would come up with manually managing hierarchies of metadata or doing stuff like gathering files with certain metadata tags together.
The best YAML example I've seen is here, you can use pyyaml in Python to read/write YAML (which is one of the things that tame is doing).

Yes, you might be correct, thank you, IDK yet. I am at the stage of gathering information. Would you by chance have links to good reading on metadata hierarchies.

license: MIT


text:
Upgrade CSI to v0.2 and set PluginVersion to 0.2.0

This PR upgrades the csilvm plugin to CSI v0.2.
The plugin version situation is a bit of a mess. I tagged v0.1.0 but forgot to change the PluginVersion to 0.1.0. This means that v0.1.0 of this plugin reports is version as '1.11.0'. Sigh.
I'm proceeding to "reverse" the version to v0.2.0 in this PR. Again, sigh. Not sure what else to do here, what's done is done.
Fixes https://jira.mesosphere.com/browse/DCOS_OSS-3309

I think this logic might make sense as part of the startup sequence vs. Probe. If the startup sequence fails, then the program can either crash (read: fail-fast, preferred) or can linger and just return unhealthy (less preferred).

I've moved the create/remove logic from Probe to a new (*Server).Setup() method.

I changed Probe to run pvck and vgck.

CI errors

pkg/csilvm/csilvm_test.go:2092::warning: declaration of "err" shadows declaration at csilvm_test.go:2087 (vetshadow)

pkg/csilvm/csilvm_test.go:2096::warning: declaration of "err" shadows declaration at csilvm_test.go:2087 (vetshadow)

Hmm - that's a good point I didn't know there was a timeout, although it makes sense.
If we have an explicit grpc error to return from Probe that would help immensely.

Can you elaborate on what the status code would indicate? I'm wondering if,
instead of an error code, we should include a field in the ProbeResponse
that indicates "readiness". "healthy" is indicated by Probe NOT returning
an error.
On Wed, May 9, 2018 at 11:52 AM, Gustav Paul notifications@github.com
wrote:

Hmm - that's a good point I didn't know there was a timeout, although it
makes sense.
If we have an explicit grpc error to return from Probe that would help
immensely.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/mesosphere/csilvm/pull/73#issuecomment-387786264, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACPVLKTsrRWBjlbRef18meFSO9I6hTlSks5twxC5gaJpZM4T0ztt
.

include a field in the ProbeResponse that indicates "readiness"

This is very cool. It basically captures my intent, just without piggy-backing on errors.

I took an action item today in the CSI sync to propose changes to the Probe
API
On Wed, May 9, 2018 at 12:12 PM, Gustav Paul notifications@github.com
wrote:

include a field in the ProbeResponse that indicates "readiness"
This is very cool. It basically captures my intent, just without
piggy-backing on errors.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/mesosphere/csilvm/pull/73#issuecomment-387792497, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACPVLPs2Ti14_u5Ci9c_iLWpI_F_oezRks5twxVogaJpZM4T0ztt
.

I merged this PR with the understanding that we'll revisit this when https://github.com/container-storage-interface/spec/pull/228 lands or the Initialization / Probe timeout issue is addressed.

https://jira.mesosphere.com/browse/DCOS-34540

authors: gpaul jdef

repo: mesosphere/csilvm


text:
[INFINITY-2030] Add state store utils unit tests

This PR adds unit tests for StateStoreUtils (see https://jira.mesosphere.com/browse/INFINITY-2030).
The main focus was fetchTasksNeedingRecovery(), but some smaller methods have also been covered. Since this is my first PR, the following would be appreciated:

Notes/comments on style
Notes/comments on the setup of the config, store, task info and task status objects.
Notes/comments on the granularity of the commits (should a squash the edits instead).

Either's fine, I don't think it's a big deal either way. The getter does imply a bit more formality than these internal tests really warrant

Merging since the CI is GREEN.

authors: elezar nickbp

repo: mesosphere/dcos-commons


text:
Adds support for the custom executor

In order to support the custom executor, it made sense to make it a subproject and so the main project had to be restructured. Essentially the main project moved to core and the custom executor is at executor. The new structure is:
├── LICENSE
├── README.md
├── build
│   ├── classes
│   ├── libs
│   ├── reports
│   ├── test-results
│   └── tmp
├── build.gradle
├── build.sh
├── cli
│   ├── README.md
│   ├── _example
│   ├── commands.go
│   ├── http.go
│   ├── response.go
│   └── runcli.go
├── core
│   ├── build
│   ├── build.gradle
│   ├── gradle
│   ├── gradlew
│   ├── gradlew.bat
│   └── src
├── docs
│   ├── architecture.png
│   ├── automatic-repair.md
│   └── tutorial.md
├── executor
│   ├── build
│   ├── build.gradle
│   ├── gradle
│   └── src
├── gradle
│   ├── checkstyle
│   ├── findbugs
│   ├── quality.gradle
│   ├── spock.gradle
│   └── wrapper
├── gradle.properties
├── gradlew
├── gradlew.bat
...
...

Logging issue has been fixed, slf4j-simple:1.6.2 was a dependency for log4j-over-slf4j:1.7.10

Addressed comments, though not too sure about how we want to restructure the project.

:bike: :house: How about sdk instead of core?

I think SDK better suits as a collective name for these library modules. Because we are breaking down the code-base into multiple modules, I think we should call out each module with a name that conveys it's place in whole SDK.

authors: NimaVaziri mohitsoni nickbp


text:
Update kafka 1.1.0

Updating kafka base tech from kafka 1.0.0 to kafka 1.1.0

@samvantran I don't understand why this was merged despite failing infinity/kafka teamcity tests?
This broke our CI: https://jira.mesosphere.com/browse/DCOS-38318

@porridge sorry that was a bad call on my side. I had saw the previous two merged PRs had failing kafka CI tests and assumed that it was a known issue, plus this PR had already been approved by Ben so I decided to merge. My main intention was to get this in to backport to sdk040 so that we could soak and test it working.
Thanks for reverting though and I'll dig into why Kafka is causing those auth issues.

@samvantran which two previous PRs?

#2524 & #2527 - these were merged to master before this one

Yes, there are known Kafka and Elastic issues tracked in two JIRA tickets: https://jira.mesosphere.com/browse/DCOS-38235 https://jira.mesosphere.com/browse/DCOS-38238, respectively which also failed for the two PRs mentioned. We do sometimes make a decision to override these checks -- especially if these seem to be upstream issues, but we should limit this and only do so after we've confirmed an existing issue that is tracked in a JIRA ticket.

I'd add a requirement to mention relevant Jira ID in a PR comment right
before hitting the merge button in such case.

Yes, for DC/OS PRs they use mergebot to link the JIRA tickets to the github overrides.

authors: Gupta-Amrit benclarkwood elezar porridge samvantran


text:
can't launch a kafka service in dcos 1.9

when i use confluent-kafka 1.1.19.1-3.2.0e,the broker-0 can't startup it show this:

kafka.common.KafkaException: Unable to parse PLAINTEXT:///opt/mesosphere/bin/detect_ip: line 4: ip: command not found:0 to a broker endpoint
	at kafka.cluster.EndPoint$.createEndPoint(EndPoint.scala:50)
	at kafka.utils.CoreUtils$$anonfun$listenerListToEndPoints$1.apply(CoreUtils.scala:281)
	at kafka.utils.CoreUtils$$anonfun$listenerListToEndPoints$1.apply(CoreUtils.scala:281)
	at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
	at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
	at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:33)
	at scala.collection.mutable.WrappedArray.foreach(WrappedArray.scala:35)
	at scala.collection.TraversableLike$class.map(TraversableLike.scala:234)
	at scala.collection.AbstractTraversable.map(Traversable.scala:104)
	at kafka.utils.CoreUtils$.listenerListToEndPoints(CoreUtils.scala:281)
	at kafka.server.KafkaConfig.getAdvertisedListeners(KafkaConfig.scala:1028)
	at kafka.server.KafkaConfig.<init>(KafkaConfig.scala:967)
	at kafka.server.KafkaConfig$.fromProps(KafkaConfig.scala:779)
	at kafka.server.KafkaConfig$.fromProps(KafkaConfig.scala:776)
	at kafka.server.KafkaServerStartable$.fromProps(KafkaServerStartable.scala:28)
	at kafka.Kafka$.main(Kafka.scala:58)
	at kafka.Kafka.main(Kafka.scala)

when i use kafka 1.1.19.1-0.10.1.0 is the same as confluent-kafka 1.1.19.1-3.2.0e
when i use beta-kafka 1.1.22-0.10.1.0-beta,it will show this error:

Exception in thread "main" com.mesosphere.sdk.kafka.upgrade.KafkaConfigUpgrade$KafkaConfigUpgradeException: Aborting Kafka Configuration Upgrade !!!
	at com.mesosphere.sdk.kafka.upgrade.KafkaConfigUpgrade.startUpgrade(KafkaConfigUpgrade.java:75)
	at com.mesosphere.sdk.kafka.upgrade.KafkaConfigUpgrade.<init>(KafkaConfigUpgrade.java:58)
	at com.mesosphere.sdk.kafka.scheduler.KafkaService.<init>(KafkaService.java:35)
	at com.mesosphere.sdk.kafka.scheduler.Main.main(Main.java:16)

and
ERROR 2017-05-24 10:31:10,513 [main] com.mesosphere.sdk.kafka.upgrade.KafkaConfigUpgrade:verifyOldTasks(132): Task broker-2 target configuration does not match with target : e505fed9-1141-49e1-bb3a-aeeae03ec4f1

@eurekao please ask for help on the DC/OS Community Slack first. If it's determined that the problem is with Universe specifically, create a new issue here with the relevant details. Thanks!

authors: cruhland eurekao

repo: mesosphere/universe

license_source: bigquery


text:
Add a Get started tutorial

Created a docs folder and placed the tutorial folder inside it
Added a walkthrough style tutorial markdown file
Created a required package called time-server and placed it in the same directory.

FYI @jsancio

thanks for doing this @takirala. Few comments based a quick read.

@klueska @vinodkone Tarun took your dogfooding feedback and created a getting started document. Does this address your feedback? Please comment if there are any changes you would like to see.

@joel-hamill Can you take a look at this PR when you get a chance?

Updated as per review suggestions. Thanks @cruhland for the detailed feedback!!

authors: jsancio ryadav88 takirala


text:
Release spark 1.1.1-2.2.0 (automated commit)

Release spark 1.1.1-2.2.0 (automated commit)
Changes since revision 26:
0 files added: []
0 files removed: []
4 files changed:
--- 26/command.json
+++ 27/command.json
@@ -1,5 +1,5 @@
 {
   "pip": [
-    "https://downloads.mesosphere.com/spark/assets/1.1.0-2.1.1/dcos_spark-0.5.19-py2.py3-none-any.whl"
+    "https://downloads.mesosphere.com/spark/assets/1.1.1-2.2.0/dcos_spark-0.5.19-py2.py3-none-any.whl"
   ]
 }
--- 26/config.json
+++ 27/config.json
@@ -45,12 +45,12 @@
         "spark-dist-uri": {
           "type": "string",
           "description": "Spark distribution URI.  This is only used to run spark-submit on your local machine.  The DCOS Spark CLI will fetch this Spark distribution.  This variable has no effect on the Spark distribution running the dispatcher, drivers, nor executors.  If you want to customize the Spark build used in the jobs themselves, configure service.docker-image.",
-          "default": "https://downloads.mesosphere.com/spark/assets/spark-2.1.1-bin-2.6.tgz"
+          "default": "https://downloads.mesosphere.com/spark/assets/spark-2.2.0-bin-2.6.tgz"
         },
         "docker-image": {
           "type": "string",
           "description": "The docker image used to run the dispatcher, drivers, and executors.  If, for example, you need a Spark built with a specific Hadoop version, set this variable to one of the images here: https://hub.docker.com/r/mesosphere/spark/tags/",
-          "default": "mesosphere/spark:1.1.0-2.1.1-hadoop-2.6"
+          "default": "mesosphere/spark:1.1.1-2.2.0-hadoop-2.6"
         },
         "log-level": {
           "type": "string",
--- 26/package.json
+++ 27/package.json
@@ -20,6 +20,6 @@
     "batch",
     "analytics"
   ],
-  "version": "1.1.0-2.1.1",
+  "version": "1.1.1-2.2.0",
   "website": "https://docs.mesosphere.com/service-docs/spark/"
 }
--- 26/resource.json
+++ 27/resource.json
@@ -2,7 +2,7 @@
   "assets": {
     "container": {
       "docker": {
-        "spark_docker": "mesosphere/spark:1.1.0-2.1.1-hadoop-2.6"
+        "spark_docker": "mesosphere/spark:1.1.1-2.2.0-hadoop-2.6"
       }
     }
   },

I will create a new PR after back porting a change to 2.2.0.

authors: mesosphere-ci susanxhuynh


text:
makerdao: Indexing Errors

ethereum: Block #16802255 - https://okgraph.xyz/?q=messari%2Fmakerdao-ethereum - Mapping aborted at src/common/helpers.ts, line 614, column 5, with message: [updatePosition]balance for position 0x66ae0574eb28b92c82569b293b856bb99f80f040-0xa13c0c8eb109f5a13c6c90fc26afb23beb3fb04a-BORROWER-0 -2528510946552692086451 < 0	wasm backtrace:	    0: 0xa3c3 - !src/common/helpers/updatePosition	    1: 0xde50 - !src/mapping/handleVatFrob	 in handler handleVatFrob at block #16802255 (a84508d010ee98a289946a29ea684d2a799de8b9ed6652d97c4d3634307998b6)

@tnkrxyz Could you take a look at this when you get the chance? Thanks!

@tnkrxyz Could you take a look at this when you get the chance? Thanks!

Working on it.

Fix in #1858 (to be verified).

This looks good on the QA side. Will let @jaimehgb review the PR. Thanks @tnkrxyz

@jaimehgb can we deploy this to the messari-hosted?

authors: bye43 this-username-is-taken tnkrxyz

repo: messari/subgraphs


text:
Hot

Creating a distributed decentralized tasking system with a mesh network for emergency response involves combining various technologies and approaches. Here's a conceptual overview of how you might approach such a system:

Mesh Network Infrastructure:

Establish a mesh network using devices like smartphones, portable Wi-Fi hotspots, or specialized mesh hardware. These devices should be able to communicate with each other directly, forming a decentralized network.

Decentralized Tasking Protocol:

Design a protocol that enables task assignment and coordination without relying on a central authority. Blockchain technology or similar decentralized ledgers can be used to record tasks and verify their completion.

User Interfaces:

Develop user-friendly interfaces for both emergency responders and the general public to report emergencies and volunteer for tasks. Mobile apps or web portals could serve this purpose.

Task Assignment Algorithm:

Implement an algorithm that intelligently assigns tasks to nearby responders based on their skills, availability, and proximity to the emergency.

Task Verification and Incentives:

Use smart contracts to verify task completion and automatically release rewards or incentives to responders upon successful completion of tasks. This incentivizes participation.

Emergency Reporting:

Create a mechanism for individuals to report emergencies via the mesh network, including text, images, and location data. Ensure that reports can reach responders quickly.

Data Privacy and Security:

Implement robust security measures to protect sensitive information and ensure data privacy, especially when dealing with sensitive emergency information.

Offline Functionality:

Ensure that the system can function even when internet connectivity is limited or unavailable, which is critical in emergency scenarios.

Scalability:

Design the system to scale easily as the number of users and tasks increases during emergencies. Consider load balancing and optimizing resource usage.

Training and Onboarding:

Provide training and onboarding materials for responders and volunteers to ensure they understand how to use the system effectively.

Community Engagement:

Engage with local communities and authorities to promote the use of the system and build trust.

Redundancy and Resilience:

Plan for redundancy in the mesh network and distributed servers to ensure system reliability in the face of network failures or disruptions.

Testing and Simulation:

Conduct extensive testing and simulations to validate the system's performance and responsiveness in various emergency scenarios.

Legal and Regulatory Compliance:

Ensure that the system complies with relevant laws and regulations, particularly concerning data handling and emergency response procedures.

Feedback Mechanism:

Establish a feedback mechanism for users to provide input on system improvements and report any issues.

Building a distributed, decentralized tasking system with a mesh network for emergency response is a complex endeavor that requires collaboration between technology experts, emergency responders, and community stakeholders. It should be designed to be robust, adaptable, and user-friendly to effectively assist in emergency situations.

Distributing OpenStreetMap (OSM) data as data packets in a distributed manner can be a complex task, but it's possible to achieve using various techniques. Here's a high-level overview of how you could approach it:

Data Partitioning: Divide the OSM data into smaller, manageable pieces, such as regions, cities, or even smaller grid cells. Each of these partitions will become a data packet.

Data Format: Convert the OSM data into a suitable format for distribution, such as GeoJSON or Protocol Buffers (protobuf). This format should be efficient for both storage and transmission.

Distribution Nodes: Set up a network of distribution nodes or servers. These nodes will store and serve the data packets to users on request.

Metadata: Each data packet should contain metadata describing its content, such as geographical boundaries, date of creation, and any relevant tags.

Data Versioning: Implement a versioning system to track changes in the OSM data. Users should be able to request specific versions of the data.

Data Replication: Distribute copies of the data packets across multiple distribution nodes for redundancy and load balancing.

Querying Mechanism: Develop a querying mechanism that allows users to request specific data packets based on their geographical area of interest or other criteria.

Data Synchronization: Regularly update the data packets to reflect changes in the OSM database. This can be done through automated processes that sync with the OSM database.

Access Control: Implement access control mechanisms to ensure that only authorized users can access and download the data packets.

API or Protocol: Define a standard API or communication protocol that users can use to interact with the distribution nodes and request data packets.

Peer-to-Peer (P2P) Distribution: Consider using peer-to-peer distribution protocols to reduce the load on central servers and distribute the data more efficiently.

Data Integrity and Validation: Implement checks to ensure the integrity of the data packets during transmission and upon receipt by users.

Documentation: Provide clear documentation on how users can access and use the distributed OSM data packets.

Remember that distributing OSM data as data packets is a significant undertaking, and you'll need to address scalability, data consistency, and user access requirements effectively. Additionally, staying up-to-date with the latest developments in OSM and geospatial data distribution techniques is essential for maintaining an efficient and reliable system.

repo: meta-introspector/meta-meme


text:
Display molecule status when not created

status displays not_created when the instance(s) are not created.
Added offline status to functional test suite.
Also, believe fixed a bug with molecule status with docker driver.
Was displaying status for the wrong hosts.

Fixes: #339

  syntax: commands succeeded
  py27-ansible19-unit: commands succeeded
  py27-ansible19-functional: commands succeeded
  py27-ansible20-unit: commands succeeded
  py27-ansible20-functional: commands succeeded
  py27-ansible21-unit: commands succeeded
  py27-ansible21-functional: commands succeeded
  docs: commands succeeded
  congratulations :)

:+1:

💯

authors: abrown-sg kireledan retr0h

repo: metacloud/molecule

license: mit


text:
How do we help Uncommons activate Asia-based research and standards creation?

[ ] chat with them about P2P workshop ideation and planning
[ ]  share insight on how to onboard researchers (thinking: open problems doc - can we build on that and add a part for asia, or can we create an asia version of that document, events with institutions such like DAO Harvard/ Stanford @thelastjosh , Eugene's experience with engaging with college blockchain clubs)
[ ] how to we enable/ empower/ coordinate standards creation in Asia

No progress this week.

authors: thelastjosh unfriendlyamendment

repo: metagov/daostar


text:
fixes TestIntegrationServerUpdateComponents intermittent failures

This resolves #105 where the test case made some assumptions about the fixtures and failed
intermittently.

@joelrebel could you re-visit the PR description to give more descriptive detail about what's being changed? This only explains the "why".

Codecov Report

Merging #118 (81e7ea5) into main (2d845d2) will increase coverage by 0.15%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #118      +/-   ##
==========================================
+ Coverage   74.00%   74.15%   +0.15%
==========================================
  Files          32       32
  Lines        2577     2577
==========================================
+ Hits         1907     1911       +4
+ Misses        494      491       -3
+ Partials      176      175       -1

Flag
Coverage Δ

unittests
74.15% <ø> (+0.15%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/api/v1/router_firmware.go
57.40% <0.00%> (+3.70%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

force pushed with signed commits

authors: JAORMX codecov-commenter joelrebel

repo: metal-toolbox/hollow-serverservice


text:
🐛 Fix remediation cleanup

What this PR does / why we need it:
The updated remediation flow introduced by https://github.com/metal3-io/cluster-api-provider-metal3/pull/668 has an issue, the remediations CRs can't be deleted because the finalizer isn't removed.
The fix is: Initialize patch helper after getting current CR!!! Otherwise nothing will deleted by patch, only added.
Some more improvements done along the way deugging this:

Requeue CR when patch fails
CRs with deletion timestamp are handled in normal CR flow (finalizer needs to be removed)
add CR deleted check to e2e test
slightly better logging
use controller utils for finalizer handling

/ok-to-test

/test-ubuntu-e2e-main
/test-centos-e2e-main

/test-ubuntu-integration-main


text:
Update README file

Add FakeIPA to the root README file

/approve
I am fine with this commit but if possible create further PRs that extend the READMI with documentation related to the usage of the fake-ipa tool eg. an example workflow or something similar.

Can we please make such additions under fake-ipa README. I don't think the global readme needs more than this quick intro, and a link to further reading.

authors: mboukhalfa tuminoid


text:
User stories for Dataset Viewer

@richardgoater Responsible for ensuring this task is taken to completion by early April

@LachlanStuart First step - made gdoc, define structure of user stories, add one example, communicate to others & send to Theo to add more
@LachlanStuart and/or @richardgoater talk to the team to find any missing use cases (Veronika, Måns, Chris et al.)
Arrange dev team meeting to discuss user stories

I'm closing this task as it was intended to be part of Richard's onboarding and was never actioned.

I'm closing this task as it was intended to be part of Richard's onboarding and was never actioned.