-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-768 Store config uniqueness enforced by StoreManager #1555
base: main
Are you sure you want to change the base?
GH-768 Store config uniqueness enforced by StoreManager #1555
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beyond simplification requested, everything looks good.
.await?, | ||
); | ||
&StoreSpec::filesystem(FilesystemSpec { | ||
content_path: current_dir |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is too complicated. Would be simpler to keep MemorySpec
here. I know it isn't pure but we don't have consistent way to test FilesystemStore
. We need one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good @mkeen There's a few things to tidy up and I also want one of two other maintainers to look at the rename and deletion of store_factory
. After lots of thought, I'm in favor of that change, but we simply need to boost awareness.
I want to think just for a few more hours also about what the error text should say when there are conflicting store configurations. What you have is fine, but can it be improved. I'm not sure.
Ok(data_len.try_into().unwrap()) | ||
} | ||
|
||
async fn make_store_manager() -> Result<Arc<StoreManager>, Error> { | ||
let store_manager = Arc::new(StoreManager::new()); | ||
store_manager.add_store( | ||
make_and_add_store_to_manager( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my understanding, what is the reason why you moved away from store_factory
rather than modifying store_factory
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still using store_factory
to build the Store, but wrapping up in make_and_add_store_to_manager
because it makes building and adding a Store to a StoreManager a single step from a public-facing perspective.
@@ -35,7 +35,7 @@ use nativelink_proto::google::devtools::build::v1::{ | |||
PublishBuildToolEventStreamRequest, PublishLifecycleEventRequest, StreamId, | |||
}; | |||
use nativelink_service::bep_server::BepServer; | |||
use nativelink_store::default_store_factory::store_factory; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems heavy at first read but maybe it is an improvement to both the naming and the functionality. store_factory
as a name says nothing about what its function is, but developers could go look at the definition. make_and_add_store_to_manager
is definitely clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
store_factory
is still used but I made private and think that make_and_add_store_to_manager
is better as a front-facing API because it makes and associates the Store with a StoreManager
-- rather than leaving them as separate steps. The door is still open to manually build any Store instance though and call add_store
on StoreManager
.
@@ -0,0 +1,48 @@ | |||
// Copyright 2024 The NativeLink Authors. All rights reserved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PERFECT!
@@ -12,11 +12,21 @@ | |||
// See the License for the specific language governing permissions and | |||
// limitations under the License. | |||
|
|||
|
|||
|
|||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what are these spaces for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will remove these and make sure formatting gets run again. My mistake on these spaces here.
use std::collections::{HashMap, HashSet}; | ||
|
||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and these? I mean empty lines.
|
||
|
||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and these?
@@ -45,7 +55,7 @@ use nativelink_service::cas_server::CasServer; | |||
use nativelink_service::execution_server::ExecutionServer; | |||
use nativelink_service::health_server::HealthServer; | |||
use nativelink_service::worker_api_server::WorkerApiServer; | |||
use nativelink_store::default_store_factory::store_factory; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@allada and @aaronmondal you two are going to need to sign off on moving away from store_factory
. I would say this new name is more self-describing for sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The big thing here guys is that make_and_add_store_to_manager
enforces that all factory-built stores are part of a StoreManager so it's less likely that an unmanaged Store would be hanging around. Still possible to build them separately and pass into add_store
this way though (useful for testing and probably other reasons). The old store_factory
is still there and used by the new make_and_add_store_to_manager
function, but store_factory
is no longer public in this changeset.
@@ -13,7 +13,9 @@ | |||
// limitations under the License. | |||
|
|||
use std::collections::HashMap; | |||
use std::ptr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need this.. will remove
} | ||
|
||
for existing_store in stores.values().into_iter() { | ||
if ptr::eq(&store, existing_store) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will remove this check. Thanks to rust's memory model and the fact that in this design, ownership of the struct instance is passed to the StoreManager on line 58. We don't have Store instance pointer being passed around with a risk of passing the same pointer N times. We have a single instance of which ownership is transferred exactly once in guaranteed fashion (thanks Rust).
So instance protection is no longer a goal or needed. But I do think the config overlap detection is valuable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Rust is an underrated comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 2 LGTMs obtained, and 0 of 14 files reviewed, and pending CI: Bazel Dev / macos-13, Bazel Dev / macos-14, Bazel Dev / ubuntu-24.04, NativeLink.com Cloud / Remote Cache / macos-14, NativeLink.com Cloud / Remote Cache / ubuntu-24.04, Remote / lre-cc / large-ubuntu-22.04, Remote / lre-rs / large-ubuntu-22.04, asan / ubuntu-22.04, docker-compose-compiles-nativelink (22.04), integration-tests (22.04), macos-13, pre-commit-checks, ubuntu-22.04, and 12 discussions need to be resolved
nativelink-config/src/stores.rs
line 435 at r11 (raw file):
} impl StoreSpec {
nit: We don't allow complex functions in the config. We use these configs as simple definitions with some macro magic (like number->string conversions and such in serde).
Description
Ensuring that when new Stores are added to StoreManager, that
memory
,experimental
,filesystem
,grpc
, andredis_store
stores will not experience overlap within aStoreManager
instance. The same data store may be used for multiple values for the listed types only if relevantStoreSpec
configuration values differ (such as connection details, key namespace, etc). Dictated bydisallow_duplicates_digest
implementation being present on the relevantStoreSpec
enum type.Primary changes:
make_and_add_store_to_manager
to make sure thestore_factory
function is not used for config that overlaps on enforced Store entitiesadd_store
so that duplicate-named items cannot be addedStoreSpec
entities are defined instores.rs
and enforced bystore_manager.rs
.StoreSpec
entities that don't need to be unique aren't encumbered by uniqueness enforcementDRAFT STATUS: Need to finalize tests and do a bit more cleanup where possible
Fixes #768
Type of change
not work as expected)
How Has This Been Tested?
Please also list any relevant details for your test configuration
Checklist
bazel test //...
passes locallygit amend
see some docsThis change is