Clarification on "4. Configure the migrations assembly".

Hi All,
I'm writing a WPF App, using EF Core as the ORM.
I'm attempting to follow Using a Separate Migrations Project as I believe it to be the correct process for my solution.
I've done steps 1 through 3, so far so good. My target project is called PSSytem, and my migrations project is called DevMigrations. I would share the git repo but unfortunately it has to stay private.
However, when attempting step 4, I am unclear as to where I am meant to write the provided code. In PSSytem, there is an automatically generated AssemblyInfo.cs; however there is no such item in DevMigrations. So I'm failing to see where I could "configure an assembly".
Any clarification would be wonderful.
Many Thanks,
Fisher.
(PS: This ambiguity may fully be due to my lack of experience with C#, .NET, and EF; It's also 4am here and I might just be blind).

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b545eeff-6c33-3cc0-09ce-a3ad342d7438
Version Independent ID: 34bc1bac-7338-d8ab-390d-8c5e88a48c10
Content: Using a Separate Migrations Project - EF Core
Content Source: entity-framework/core/managing-schemas/migrations/projects.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @bricelam
Microsoft Alias: avickers

I ended up just moving migrations back in to the main project.

Duplicate of #933
This page definitely needs some work.

Duplicate of #933
This page definitely needs some work.

Duplicate of #933
This page definitely needs some work.

Ah, sorry for not finding the duplicate first!!
Probably already mentioned there, but from my limited knowledge this page is messy because it assumes knowledge of ASP.NET, then describes actions based on an ASP solution structure.
If you know ASP.NET then that's fine, you can "translate" it for other projects. But if you don't then it leaves you in the dark.
Or I could be completely off the mark with this.
Anyway, thanks for getting back to me!

Duplicate of #933
This page definitely needs some work.

Ah, sorry for not finding the duplicate first!!
Probably already mentioned there, but from my limited knowledge this page is messy because it assumes knowledge of ASP.NET, then describes actions based on an ASP solution structure.
If you know ASP.NET then that's fine, you can "translate" it for other projects. But if you don't then it leaves you in the dark.
Or I could be completely off the mark with this.
Anyway, thanks for getting back to me!

Well, it's not exactly a dupe, but I wanted to link it so we didn't miss your specific feedback when updating that page.

Well, it's not exactly a dupe, but I wanted to link it so we didn't miss your specific feedback when updating that page.


refactor: smiplify csp

Codecov Report

Merging #3489 into dev will increase coverage by <.01%.
The diff coverage is 100%.

@@           Coverage Diff            @@
##             dev   #3489      +/-   ##
========================================
+ Coverage   99.1%   99.1%   +<.01%
========================================
  Files         18      18
  Lines       1112    1114       +2
  Branches     299     300       +1
========================================
+ Hits        1102    1104       +2
  Misses        10      10

Impacted Files
Coverage Δ

lib/common/nuxt.config.js
100% <ø> (ø)
:arrow_up:

lib/core/middleware/nuxt.js
100% <100%> (ø)
:arrow_up:

lib/common/options.js
100% <100%> (ø)
:arrow_up:

lib/core/renderer.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d9d2d9e...4c188e6. Read the comment docs.


Fix docker build command option

Hi,
Docker build command occurred error.
[digdag file]
timezone: UTC

_export:
  docker:
    image: ubuntu:14.04
    build: ["echo hello world"]

+step1:
  sh>: tasks/shell_sample.sh

[error]
2016-06-26 15:46:33 +0900: Digdag v0.8.2
2016-06-26 15:46:35 +0900 [WARN] (main): Reusing the last session time 2016-06-24T00:00:00+00:00.
2016-06-26 15:46:35 +0900 [INFO] (main): Using session .digdag/status/20160624T000000+0000.
2016-06-26 15:46:35 +0900 [INFO] (main): Starting a new session project id=1 workflow name=digdag-docker session_time=2016-06-24T00:00:00+00:00
2016-06-26 15:46:35 +0900 [INFO] (0019@+digdag-docker+step1): sh>: tasks/shell_sample.sh
invalid argument "rev-1-2016-06-26T06:46:34.954Z" for t: Error parsing reference: "rev-1-2016-06-26T06:46:34.954Z" is not a valid repository/tag
See 'docker build --help'.
2016-06-26 15:46:35 +0900 [ERROR] (0019@+digdag-docker+step1): Task failed with unexpected error: Docker build failed
java.lang.RuntimeException: Docker build failed
	at io.digdag.standards.command.DockerCommandExecutor.buildImage(DockerCommandExecutor.java:207)
	at io.digdag.standards.command.DockerCommandExecutor.startWithDocker(DockerCommandExecutor.java:68)
	at io.digdag.standards.command.DockerCommandExecutor.start(DockerCommandExecutor.java:50)
	at io.digdag.standards.operator.ShOperatorFactory$ShOperator.runTask(ShOperatorFactory.java:104)
	at io.digdag.util.BaseOperator.run(BaseOperator.java:49)
	at io.digdag.core.agent.OperatorManager.callExecutor(OperatorManager.java:265)
	at io.digdag.cli.Run$OperatorManagerWithSkip.callExecutor(Run.java:658)
	at io.digdag.core.agent.OperatorManager.runWithWorkspace(OperatorManager.java:231)
	at io.digdag.core.agent.OperatorManager.lambda$runWithHeartbeat$1(OperatorManager.java:124)
	at io.digdag.core.agent.NoopWorkspaceManager.withExtractedArchive(NoopWorkspaceManager.java:20)
	at io.digdag.core.agent.OperatorManager.runWithHeartbeat(OperatorManager.java:122)
	at io.digdag.core.agent.OperatorManager.run(OperatorManager.java:106)
	at io.digdag.cli.Run$OperatorManagerWithSkip.run(Run.java:640)
	at io.digdag.core.agent.LocalAgent.lambda$run$0(LocalAgent.java:70)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
2016-06-26 15:46:35 +0900 [INFO] (0019@+digdag-docker^failure-alert): type: notify
error:
  * +digdag-docker+step1:
    Docker build failed

Docker tag reference is "repository/tag".
And, I think docker container tag don't use uppercase and colon.
Please review PR.

Build option has a known design problem (described bellow). My plan is to remove it (that's why build option is not written in the documents at all). Otherwise the build code needs almost complete redesign.
Alternative option for you is to build the image in advance before running the workflow. Then, you can use name of the pre-built image.
The problem happens with cache. A built Docker image should be cached. Otherwise running one task will build one image. You will se many images built on your docker engine because a workflow builds image again and again for each task.

I redesigned the strategy instead.
Behavior is in the commit comment at 78baeab02596615a48591e82a213f1b7115a7e07


[Question] How to make sure orderless write requests will be reordered in the I/O scheduler

Hi,
I am trying to send orderless write requests to a file through liburing (for example, write offset = 0, 1, 3, 2, and at first the file size is 0), so I put them in the SQ through io_uring_get_sqe() and io_uring_prep_writev() one by one and send them in a batch through io_uring_submit(). I hope they will be reordered to 0, 1, 2, 3 in the I/O scheduler (I think mq-deadline may help me do this). But the results from CQ show that write offset = 3 will always fail, which means that the order doesn't change.
So I wonder if the orderless write requests will be reordered in the scheduler and can I use liburing achieve my goal? Thanks for help!

The order of requests are not guaranteed since they are run in parallel.
If you want them running in any order, try IO_SQE_IOLINK

Thanks for your reply, but I think I made my question confused.
I don't want them run in specified order in the user space, on the contrary, I allow them orderless, and I know that mq-deadline scheduler will reorder my orderless write, so I want to use liburing to check if it really does it. But the result shows that it doesn't, so I am not sure if the requests sent by liburing will be processed in the block I/O layer.

Hi,
I am trying to send orderless write requests to a file through liburing (for example, write offset = 0, 1, 3, 2, and at first the file size is 0), so I put them in the SQ through io_uring_get_sqe() and io_uring_prep_writev() one by one and send them in a batch through io_uring_submit(). I hope they will be reordered to 0, 1, 2, 3 in the I/O scheduler (I think mq-deadline may help me do this). But the results from CQ show that write offset = 3 will always fail, which means that the order doesn't change.
So I wonder if the orderless write requests will be reordered in the scheduler and can I use liburing achieve my goal? Thanks for help!

Hi,
you actually put forward two questions:

Is liburing write requests go to block layer?
AFAIK, a direct write request definitely goes through block layer. While a buffered write request may probably not since it
just write data to page cache unless it causes writeback.
Does mq-deadline reorder the requests?
I haven't read the source code of this scheduler but I think it's not reasonable for a block layer scheduler to reorder requests
by their logic offset.. it even don't know the logic offset info since when bio/request already carries the physical info.
btw, the requests in block layer is a different concept with requests in io_uring.

Hi,
I am trying to send orderless write requests to a file through liburing (for example, write offset = 0, 1, 3, 2, and at first the file size is 0), so I put them in the SQ through io_uring_get_sqe() and io_uring_prep_writev() one by one and send them in a batch through io_uring_submit(). I hope they will be reordered to 0, 1, 2, 3 in the I/O scheduler (I think mq-deadline may help me do this). But the results from CQ show that write offset = 3 will always fail, which means that the order doesn't change.
So I wonder if the orderless write requests will be reordered in the scheduler and can I use liburing achieve my goal? Thanks for help!

Hi, you actually put forward two questions:

Is liburing write requests go to block layer?
AFAIK, a direct write request definitely goes through block layer. While a buffered write request may probably not since it
just write data to page cache unless it causes writeback.
Does mq-deadline reorder the requests?
I haven't read the source code of this scheduler but I think it's not reasonable for a block layer scheduler to reorder requests
by their logic offset.. it even doesn't know the logic offset info since bio/request already carries the physical info.
btw, the requests in block layer is a different concept with requests in io_uring.

Regards, Hao

@HowHsu Thanks for your heartful reply. If liburing surely goes through block layer using O_DIRECT, I think I should read the source of mq-deadline scheduler to find further progress.


v1 candidate

This PR is closer to a request for comment.
I was unable on my host to get the specs running, and as such did not add any (although the approach should allow all of the functionality to exist. Also, these changes require the changes I added to the hiera-vault gem to support real LIST requests https://github.com/hashicorp/vault-ruby/pull/201.
The function has been re-written such that it behaves more like the other standard hiera back ends, running the function once per uri passed in. It takes advantage of the global vault client, but reconfigures it before each lookup to ensure environment caching doesn't cause any problems. Configuration is cached for each path, and the keys found at each path and any values returned are cache to reduce the calls to vault and provide as static a view on the secret set as possible.
There is a construct for adding other backends, and supporting interleaved backends is now possible as the configuration for the mount and the list of paths are handled separately.
A pattern for handling environment specific field values (eg for testing a new version of a secret before rolling it out infra wide) also has been developed with the environment_delimiter option.

@traviscosgrave This looks great! The main issue is that I dont really want to merge this until the features are added into the core gem...
Let me check on the status of that and see if I can get that merged

Of course! We're running both forks locally, and I'm not sure my patch to the core gem is the best way to solve the problem of the HTTP client on supporting the LIST method. Gotta keep moving though.
Also, this is now up-to-date with our current implementation. I ran into some issues with cached environments and JRubies either garbage collecting or nodes in a weird state (migrating from one cluster to another) hitting the error and the global $vault being blown away. The most recent change removes the forced nil on the $vault client and will recreate one if it get's GC'd. Thanks for following up

Any news on this?
The hiera fallback is something that I'll really like to have :)

I'm still battling the error mentioned above, I hope to have some kind of solution this week and I'll update the PR accordingly.

Using the retry feature of the vault client I was able to resolve the race condition whereby a pool is shutting down mid-request especially in cached environments. I've also eliminated the need for the weird support of the LIST http method by instead upgrading the local vault agent to the latest 1.1.3 (in which a bug preventing query string parameters from being proxied was fixed).
This is now looking good in our environment. Looking forward to the comments.
Asside: I did attempt to use the built in Puppet::HttpPool, but it required some nasty tricks and was about 50% slower on catalogs with many lookups even after forcing it to reuse connections.

@traviscosgrave You still need https://github.com/hashicorp/vault-ruby/pull/201 before merging this ?

hashicorp/vault-ruby#201 is only required if you plan to use vault agent before version 1.1.3. It shouldn't be required if you talk directly from your puppet server/agent to vault. (Although that case is currently outside our scope due to a strict vault cipher set that is unsupported by the jruby net:http implementeation). [The current code is what we have have running now.]

@traviscosgrave Can you resolve the conflict then I can merge? 👍

I'll see what I can do, there's a lot that I moved around.

I've merged https://github.com/petems/petems-hiera_vault/pull/41 in the mean time, which doesnt seem to require changes to the gem, can you test this works for you now?

I tried #41- and it is broken for v2 stores (and actually doesn't work well for v1 either).
This PR works very well (really good job, @traviscosgrave!) and I do hope this gets merged! As mentioned, it does not require hashicorp/vault-ruby#201 as long as an updated Vault-agent is used.
I just have two nitpicks:

The continue_if_not_found option should be documented and/or should be true by default as Hiera will otherwise stop making further lookups if no value is found on first URI - which might not be expected behaviour.
The environment_delimiter option could be made optional as some might prefer separating environments by URI instead.


Merge  and  when possible

It's useless to have both, in the worst case I'll add a class to the label to make it look bold.

Done by Spuds.


Radio Paradise

Hi. Could you pls. be so kind as to add the 4 great Radio Paradise Stream Links:
https://radioparadise.com/listen/stream-links
mp3 or ogg streams will do for many for sure. Thx.

Hi there @supertevran
Thanks for suggesting these stations. :+1:
I've added them to pmrp. You can find them here,
Medley -> 35 - Radio Paradise World
Medley -> 40 - Radio Paradise Mix
Medley -> 41 - Radio Paradise Mallow
Rock -> 09 - Radio Paradise Rock
Enjoy :smile:

Dear "hakerdefo"
This is really amazing and absolutely great - mindblowing! I make a small remark and just a couple of hours later you not only reply but make a dream come true!
These current times are really crazy, weird. The pandemic is still affecting all of us. It's just great that there are people like you around.

@supertevran
Sorry about the inconvenience there. Please get the updated version of pmrp as I've fixed the issue and all of the Radio Paradise stations should work now, hopefully :wink:
And the pandemic has robbed me of everything that I used to call life and has given me the depression that is never ending. Anyway this ain't the place to discuss my pain and sorrow. Sorry about that.
Have a great day/night head.


Fixed Kotlin and cli issues

Kotlin - Changed folder from src\test\java to src\test\kotlin to place runner and step definition classes.
CLI - Removed command at beginning of section. It is duplicate.
Minor typos and indentation.

@mlvandijk For kotlin I always stored the stepdefs and runner in src/test/kotlin in my code and it worked. I had made a mistake writing the correct folder in the guide. Do you have the below in kotlin-maven-plugin? Have not configured anything in surefire or failsafe.
   <configuration>
   	<sourceDirs>
   			<source>src/test/java</source>
   			<source>src/test/kotlin</source>
   	</sourceDirs>
      </configuration>

For CLI the command already exists with the 'parallel' folder in the section. Have removed the confusing command at beginning. If it is still not working will remove the whole CLI section and create a separate PR for later.
Thanks

Thnx @grasshopper7


[IOTDB-1194]Fix a bug of checking time partition in DeviceTimeIndex

Behavior
The link of the corresponding Jira issue is: https://issues.apache.org/jira/browse/IOTDB-1194
Reason
The reason is startTimes and endTimes array may be larger than the number of devices in the loaded tsfile, and they are assigned default values for those positions which are larger than the number of devices.
Solution
So, either traversing the startTimes   until  the number of devices, or traversing the deviceToIndex and using its index to access startTimes.

could you explain why it is correct by changing the traversing order  in the device order?

An IT needed

The failure is casued by time unit transformation in IT. The unit of the parameter in config.setPartitionInterval() is second, while I treated it as milisecond before.


Custom type imports

This is another in my series of threads about custom types. I can't find an original issue from which the custom types where originally imagined, so pardon the new threads on it, but I thought separate threads for each idea made more sense than one giant one.
Import Custom Types
In this first iteration of custom types, they're each defined in modules and provide a more rigid structure to the input parameters in a way that's consumable by the callers of these modulues. But I think this leaves ample opportunity on the table to better organize the data in larger "orchestration" modules upstream. Today, the root module remains a mess of raw data inputs that are just waiting to be passed into the structured types of the referenced modules.
I'd like to see greater reusability of types (like interfaces in C# or Typescript) and would thus to see the idea of namespaced types enter the larger picture. Bicep today treats separate files as whole modules and I'd like to build on that by allowing a wholly separate file to contain a collection of types. From a development perspective then, I'd like to see the inclusion of an @import-types './types.bicep' (naming is hard) statement at/near the top the file/module that can reference other modules and include their types from an intellisense and incorporation standpoint.
Keep the approach today for those types that are module-specific as they don't need to be imported anywhere else. But this would allow for greater type re-use in a manner that also allows type usage outside of strictly from a parameter-validation scenario, e.g.:
//types.bicep

@minLength(1) //Indicating that the individual element should have a min string length of 1
type nodeType = string

@minLength(1) //Indicating that the array itself should have a min length of 1
type nodeTypes = nodeType[]

type certificateAssignment = {
  name: string
  targets: nodeTypes
}

//main.bicep
@import-types './types.bicep'

type deployment = {
  name: string
  assignments: certificateAssignment[]
}

param Deployment deployment = {
  name: 'MyDeployment'
  assignments: [
    name: 'example.com'
    targets: [
      'frontend'
      'backend'
    ]
  ]
}

Especially because the custom types themselves are bundled in with the deployment, the import of the types should not mean that all types are included in the modules importing them, but rather only those that are explicitly or implicitly referenced should be included in the output build.
Import Anything
Extending this idea a bit from just types, on a number of community calls I've heard asks for globalized values that can be referenced collectively across the deployment. I'd like to submit a variation of this as my own preferrerd solution to that ask. A true global namespace (like that in Javascript on the window) can be an unwieldy mess of variables (limiting the utility of Intellisense to narrow the intent) and really muddy the waters about what a (non-constant) variable is set to, especially given order-of-operations concerns.
Rather, I'd ask for a variation of the ask above - change the keyword from @import-types to @import and allow both types and variables to be passed as immutable constants back to the consuming modules. Locally, they can be manipulated and derivatives created as needed, but without being able to write back to the module they're originally defined in. Like the types, if the variables in the module aren't referenced, don't include them in the output build.
//types.bicep

@minLength(1) //Indicating that the individual element should have a min string length of 1
type nodeType = string

@minLength(1) //Indicating that the array itself should have a min length of 1
type nodeTypes = nodeType[]

type certificateAssignment = {
  name: string
  targets: nodeTypes
}

var assignments certificateAssignment[] = [
  {
    name: 'example.com'
    targets: [
      'frontend'
      'backend'
    ]
  }
  {
    name: 'another.com'
    targets: [
      'frontend'
    ]
  }
]

Because this module references the assignments variable from types.bicep, all types and variables from types.bicep would be included in this module at build.
// main.bicep

@import './types.bicep'

module myModule './whatever.bicep'  = {
  name: 'Test'
  parameters: {
    targetAssignments: assignments //included from types.bicep
  }
}

This module only uses two of the types (explicitly uses nodeTypes and implicitly uses nodeType) so it would exclude the other type and variable from the output module.
// nodeTypes.bicep

@import './types.bicep'

param nodeTypeNames nodeTypes = [ //Uses imported nodeTypes type definition
  'frontend'
  'backend'
]

module nodeTypeDeployment './myNodeTypeDeployment.bicep' = [for nodeTypeName in nodeTypeNames: {
  name: 'node-type-${nodeTypeName}'
  parameters: {
    name: nodeTypeName
  }
}]

Import select types
Addressing some of the comments on this thread, it'd be great to be able to selectively import only some types. Just like the example immediately above this, it should emit identical output because both the nodeType (implicitly included via its explicit reference in the original type definition) and nodeTypes type definition should be included in this outputted module as though it was defined here to begin with (assuming the same runtime as used today for custom types, but allowing room for optimization down the road), but the other unused types (certificateAssignment) would be excluded because they're not explicitly imported. The earlier example excluded the remaining unused types implicitly because they were imported, but simply not used.
// nodeTypes.bicep
@import { nodeTypes } from './types.bicep'

param nodeTypeNames nodeTypes = [ //Uses imported nodeTypes type definition
  'frontend'
  'backend'
]

module nodeTypeDeployment './myNodeTypeDeployment.bicep' = [for nodeTypeName in nodeTypeNames: {
  name: 'node-type-${nodeTypeName}'
  parameters: {
    name: nodeTypeName
  }
}]

Type aliases
Addressing the concern in #9639 around the symbolic names, it would be great to support aliases on the imported types to prevent in-module name collisions.
Repurposing the same example above, I'd like to offer the as keyword to denote the symbol to use for the type as an alias in place of its original symbol. When producing the output module (again, assuming today's ARM runtime approach for custom types wherein the type is bundled with every module), the alias should be used as the type's name instead of its original name so as to prevent any naming collisions. For example:
// nodeTypes.bicep
@import { nodeTypes as manyNodes } from './types.bicep'

param nodeTypeNames manyNodes = [ //Uses imported nodeTypes type definition, but aliased as 'manyNodes'
  'frontend'
  'backend'
]

module nodeTypeDeployment './myNodeTypeDeployment.bicep' = [for nodeTypeName in nodeTypeNames: {
  name: 'node-type-${nodeTypeName}'
  parameters: {
    name: nodeTypeName
  }
}]

When built, this should place the type definition inline using the alias such that it would be no different than having originally written (except that the former is easier on developers since it allows reusability and what follows is representative of the experience today):
// nodeTypes.g.bicep
@minLength(1)
type nodeType = string

@minLength(1)
type manyNodes = nodeType[] //Note that it uses the alias provided instead of the original symbol

param nodeTypeNames manyNodes = [
  'frontend'
  'backend'
]

module nodeTypeDeployment './myNodeTypeDeployment.bicep' = [for nodeTypeName in nodeTypeNames: {
  name: 'node-type-${nodeTypeName}'
  parameters: {
    name: nodeTypeName
  }
}]

These suggestions would greatly simplify the idea of using a deployment for a wide variety of implementation as these types and values could simply be implemented in project-wide and more narrowly-applicable modules can also be built as needed.
For locally-referenced imports, I can't immediately think of why the importation would be necessary to maintain in the build output and would instead recommend this be syntactical sugar for the repetition throughout the deployment. In other words, in the output ARM template, the variable and types should be referenced as though they were defined in the module and referencing modules themselves instead of imported.
Import Anything from Anywhere
Especially with the notion of public registries, I'd like to further see an evolution of the idea that allows for importing types and variables from versioned registry-based modules. I haven't worked much with the public registries myself, so I defer to the team as to whether it make sense to maintain a link to the registry for imports or again just use this import statement as a shortcut at build-time to copy all the utilized variables and types in the resulting module.
Change log:
2/13: Added suggestion to import specific types instead of a blanket import as well as aliases to imported symbols
Thank you for considering my request.

Related to #9357

I'd be very interested in something like this as well. I've just this morning looked into userDefinedTypes and it currently isn't really an option for our highly modular bicep template.
I'm not sure of the inner workings of Bicep but I'm wondering if a typescript export type style approach would be possible, allowing multiple types to exist in the same definition files and also allowing modules to pick and choose which items are relevant.
// types/Animals.bicep

type Cat = {
  name: string
  furStyle: string
  age: int
}

type  Elephant = {
  name: string
  trunkLength: int
  toeNailsPainted: bool
}

export { Cat, Elephant }

// deployCats.bicep

@import { Cat } from './types/Animals';

param cats: Cat[]

// deployElephants.bicep

@import { Elephant } from './types/Animals';

param elephants: Elephant[]

Yep gave custom types a whirl today, and hit the need for this immediately.
For now have resorted to copying custom types around into the various templates that need them.
We have modules that build on top of other modules, and as such sometimes those higher level modules want to naturally reference the types exposed by the lower level ones - however they can't define a custom that leverage those lower level custom types. For example:

vm.bicep
vm-cluster.bicep
main.bicep

Here, the logic to deploy a single vm is in vm.bicep and it exposes some custom types that are pretty primitive for a VM for example the Image spec.
The vm-cluster.bicep references vm.bicep but handles deploying multiple vm's as a cluster. It has options about how many to vm's to deploy etc. However it still also needs to take Image spec so it can pass that through to vm.bicep. At the moment I have to duplicate this type in both templates.

I really like this import anything idea, though variables might not be compile-time constants so in my mind it doesn't make sense to import them. Maybe a new const keyword could be added for compile-time constants?
Right now a .bicep file itself defines a module: a set of resources with dependencies, inputs and outputs which can be deployed to Azure. Defining a type to use internally in a module makes sense, but importing types from other modules like this seems like it would be mixing two worlds.
I would instead suggest fundamentally changing what a .bicep file does, from defining a single module to defining multiple things: modules, types and perhaps constants and functions which can be exported and imported in other files. This would of course require a way to define which module is the "root" of the deployment. It could be the one called main, it could be exported with a special keyword, or it could be specified on the command line when compiling. Taking inspiration from Go, one could call what a .bicep file defines this way a package, and perhaps even allow defining a single package across multiple files.
This could for example look something like this:
// landingZoneSubscription.bicep

include { Budget } from 'budget.bicep'

// define a type
type LzSubscriptionDefintion = {
  applicationName: string
  subscriptionName: string
  addressPrefix: string
  budget: Budget
}

// define a module
def LandingZoneSubscription tenant = {
  // inside these brackes would basically be a copy-paste of an old-style .bicep file
  @description('The Landing Zone Subscription\'s definition')
  param defintion LzSubscriptionDefinition

  resource subscriptionAlias 'Microsoft.Subscription/aliases@2021-10-01' = {
    name: definition.subscriptionName
  }

  // more resources here

  output subscriptionId string = subscriptionAlias.properties.subscriptionId
}

export { LzSubscriptionDefinition, LandingZoneSubscription }

// landingZones.bicep

include { LzSubscriptionDefinition as LzDef, LandingZoneSubscription as LzSub } from 'landingZoneSubscription.bicep'

def LandingZones tenant = {
  @description('An array of definitions of all the Landing Zones to create')
  param landingZoneDefinitions LzDef[]

  module landingZones LzSub = [for lzDef in landingZoneDefinitions: {
    name: `deploy-lz-${lzDef.subscriptionName}`
    params: {
      definition: lzDef
    }
  }]
}

A backwards-compatible way would instead be C/C++-style header files that can only define types, constants and functions, which could then be imported by multiple .bicep files. The example above would then be:
// landingZoneSubscription.biceph

include { Budget } from 'budget.biceph'

// define a type
type LzSubscriptionDefintion = {
  applicationName: string
  subscriptionName: string
  addressPrefix: string
  budget: Budget
}

// landingZoneSubscription.bicep

targetScope = 'tenant'

include { LzSubscriptionDefintion } from 'landingZoneSubscription.biceph'

// inside these brackes would basically be a copy-paste of an old-style .bicep file
@description('The Landing Zone Subscription\'s definition')
param defintion LzSubscriptionDefinition

resource subscriptionAlias 'Microsoft.Subscription/aliases@2021-10-01' = {
  name: definition.subscriptionName
}

// more resources here

output subscriptionId string = subscriptionAlias.properties.subscriptionId

// landingZones.bicep

targetScope = 'tenant'

include { LzSubscriptionDefinition as LzDef } from 'landingZoneSubscription.biceph'

@description('An array of definitions of all the Landing Zones to create')
param landingZoneDefinitions LzDef[]

module landingZones LzSub = [for lzDef in landingZoneDefinitions: {
  name: `deploy-lz-${lzDef.subscriptionName}`
  params: {
    definition: lzDef
  }
}]

@pelle-domela I like the use of the include keyword instead of import, as to me that more accurately conveys how this feature would work under the hood. Type definitions would be copied into the compiled JSON template, so the mechanism would be much closer in spirit to C's #include than it would be to JavaScript's import. Since import has already been used for extensibility providers (#3565), I think it would be confusing if import './path/to/template.bicep' did something completely different from import <extensibility provider name>.
Besides types and compile-time resolvable variables, one other construct that might be useful to share via include would be user-defined functions (#9239). /cc @SimonWahlin

I agree - I haven't done anything with the extensibility providers, so I hadn't realized that was already a reserved keyword.

Because we're looking at using sharing functions, variables, and types at compile time, I opened the include proposal as a new issue: #10121

Well, in that case, bump!


identity

One thing that we will need to embed here is the identity. Deltas should be signed and verified by peers. I'm not sure which API we should expose, but I'm thinking of something along the lines of having a session intermediating collaborations:
const session = await app.session(credentials)
const collaboration = await session.collaborate('collab name', 'type', options)

@satazor do you mind taking this one? (after the DWeb Summit, of course).

@pgte Yes. Note that I'm still on Discussify as well.
We need to define priorities after the DWeb Summit so that we are aligned in terms of what's to do next and expectations. Hopefully, we will be able to chat with a lot of people about Identity and Authentication on the event to better consolidate our ideas on https://github.com/ipfs-shipyard/peer-star/pull/15.

@satazor understood.

Notes from personal discussion: we should provide a "validation" hook of CRDT operations so that anyone can bring their own identity/verification system. Then we would have a library that would provide a hook that glues the IndentityManagerClient, validating signatures and the present of the public key in the DID document.


Creating VMs in Azure using the GoSDK

We have a question on creating VM in Azure.
We are trying to create a VM using the go sdk where we want to use our private linux image.
The Image parameters that Azure needs are Publisher, sku, offer  and version and uses them to get the image from the marketplace.
What values will we need for our private image to be passed in the vmClient.CreateOrUpdate function?
type ImageReference struct {
  ID          *string json:"id,omitempty"
  Publisher *string json:"publisher,omitempty"
  Offer       *string json:"offer,omitempty"
  Sku         *string json:"sku,omitempty"
  Version   *string json:"version,omitempty"
  }
Is there a way to pass just the vmName?
`

Howdy @pitthu, sorry this has gone without a response for a few weeks!
My colleague @devigned actually just finished updating the sample for managing virtual machines to include dealing with private images. You can find that code here:
https://github.com/devigned/virtual-machines-go-manage/blob/image-ref-update/example.go
It hasn't made it's way into the main Azure-Sample repository yet, but rest assured that it will.
I hope that helps!
-Martin

Hi Martin,
Thanks for replying. We have been in contact with David, he has helped a
lot with the create instance :)
Best,
Sunanda
On Thu, Oct 12, 2017 at 3:25 PM, Martin Strobel<EMAIL_ADDRESS>wrote:

Howdy @pitthu https://github.com/pitthu, sorry this has gone without a
response for a few weeks!
My colleague @devigned https://github.com/devigned actually just
finished updating the sample for managing virtual machines to include
dealing with private images. You can find that code here:
https://github.com/devigned/virtual-machines-go-manage/
blob/image-ref-update/example.go
It hasn't made it's way into the main Azure-Sample repository
https://github.com/Azure-Samples?utf8=✓&q=&type=&language=go
yet, but rest assured that it will.
I hope that helps!
-Martin
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-sdk-for-go/issues/780#issuecomment-336294045,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGl3i3ZnJFYEIaySuYXHW4xcHINdqH0Jks5srpHYgaJpZM4Pf03C
.


Uniformity in output.json file name in software importer

Hi @noteboom , from our tests we find out that is it very important the name assigned to the output files. In particular we need to use the same nomenclature for the common output files.
Currently the only common output file between the method is the output.json log file.
In the software import, you should use the name out_log, in order to allow the web app the right access to this file.
To do this update, you can directly open your method in software importer and change the name of this output

OK, I will use out_log. Thanks

OK, I will use out_log. Thanks

Thanks to you.
Please write here when the method has been updated, thanks

Updated SSI04 method. (uses now out_log as parameter name)

Thank you


Moved: Vivaldi.Vivaldi.Snapshot version 5.1.2553.3

This pull request is automatically generated by 🥟 Dumplings
Microsoft Reviewers: Open in CodeFlow

/AzurePipelines run


BUG：got error when launch model with vllm-v0.3.2  in multiple GPU mode

Describe the bug
In order to use Qwen1.5 with vllm  in xinferrence， i upgrade vllm from v0.3.0 to v0.3.2, bug got the following error messsage when launch model with multiple GPU:
AssertionError: [address=<IP_ADDRESS>:10725, pid=58281] daemonic processes are not allowed to have children

but when change the num of GPU to 1 , it works fine
To Reproduce
To help us to reproduce this bug, please provide information below:

Your Python version.  --> python3.11
The version of xinference you use. --> v0.8.5
Versions of crucial packages. -->  vllm 0.3.2
Full stack of the error. --> AssertionError: [address=<IP_ADDRESS>:10725, pid=58281] daemonic processes are not allowed to have children
Minimized code to reproduce the error.  --> enable vllm and launch xinferrence -> choose 'qwen1.5-chat' -> choose pytorch format and n_gpu > launch model

Not suer this bug related to the xinferrence of vllm

Seems is not compatible with latest vllm, v0.3.0 has suppoerted qwen 1.5 series, you can fix version for now.

Confirmed that vllm==0.3.2 has this issue, the full traceback:
2024-02-22 06:33:22,982 xinference.api.restful_api 155837 ERROR    [address=<IP_ADDRESS>:33063, pid=156010] daemonic processes are not allowed to have children
Traceback (most recent call last):
  File "/home/codingl2k1/inference/xinference/api/restful_api.py", line 674, in launch_model
    model_uid = await (await self._get_supervisor_ref()).launch_builtin_model(
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/xoscar/backends/context.py", line 227, in send
    return self._process_result_message(result)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/xoscar/backends/context.py", line 102, in _process_result_message
    raise message.as_instanceof_cause()
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/xoscar/backends/pool.py", line 657, in send
    result = await self._run_coro(message.message_id, coro)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/xoscar/backends/pool.py", line 368, in _run_coro
    return await coro
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/xoscar/api.py", line 384, in __on_receive__
    return await super().__on_receive__(message)  # type: ignore
  File "xoscar/core.pyx", line 558, in __on_receive__
    raise ex
  File "xoscar/core.pyx", line 520, in xoscar.core._BaseActor.__on_receive__
    async with self._lock:
  File "xoscar/core.pyx", line 521, in xoscar.core._BaseActor.__on_receive__
    with debug_async_timeout('actor_lock_timeout',
  File "xoscar/core.pyx", line 526, in xoscar.core._BaseActor.__on_receive__
    result = await result
  File "/home/codingl2k1/inference/xinference/core/supervisor.py", line 772, in launch_builtin_model
    await _launch_model()
  File "/home/codingl2k1/inference/xinference/core/supervisor.py", line 736, in _launch_model
    await _launch_one_model(rep_model_uid)
  File "/home/codingl2k1/inference/xinference/core/supervisor.py", line 720, in _launch_one_model
    await worker_ref.launch_builtin_model(
  File "xoscar/core.pyx", line 284, in __pyx_actor_method_wrapper
    async with lock:
  File "xoscar/core.pyx", line 287, in xoscar.core.__pyx_actor_method_wrapper
    result = await result
  File "/home/codingl2k1/inference/xinference/core/utils.py", line 45, in wrapped
    ret = await func(*args, **kwargs)
  File "/home/codingl2k1/inference/xinference/core/worker.py", line 549, in launch_builtin_model
    await model_ref.load()
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/xoscar/backends/context.py", line 227, in send
    return self._process_result_message(result)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/xoscar/backends/context.py", line 102, in _process_result_message
    raise message.as_instanceof_cause()
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/xoscar/backends/pool.py", line 657, in send
    result = await self._run_coro(message.message_id, coro)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/xoscar/backends/pool.py", line 368, in _run_coro
    return await coro
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/xoscar/api.py", line 384, in __on_receive__
    return await super().__on_receive__(message)  # type: ignore
  File "xoscar/core.pyx", line 558, in __on_receive__
    raise ex
  File "xoscar/core.pyx", line 520, in xoscar.core._BaseActor.__on_receive__
    async with self._lock:
  File "xoscar/core.pyx", line 521, in xoscar.core._BaseActor.__on_receive__
    with debug_async_timeout('actor_lock_timeout',
  File "xoscar/core.pyx", line 524, in xoscar.core._BaseActor.__on_receive__
    result = func(*args, **kwargs)
  File "/home/codingl2k1/inference/xinference/core/model.py", line 239, in load
    self._model.load()
  File "/home/codingl2k1/inference/xinference/model/llm/vllm/core.py", line 139, in load
    self._engine = AsyncLLMEngine.from_engine_args(engine_args)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/vllm/engine/async_llm_engine.py", line 625, in from_engine_args
    engine = cls(parallel_config.worker_use_ray,
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/vllm/engine/async_llm_engine.py", line 321, in __init__
    self.engine = self._init_engine(*args, **kwargs)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/vllm/engine/async_llm_engine.py", line 366, in _init_engine
    return engine_class(*args, **kwargs)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/vllm/engine/llm_engine.py", line 118, in __init__
    self._init_workers_ray(placement_group)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/vllm/engine/llm_engine.py", line 286, in _init_workers_ray
    self._run_workers("init_model", cupy_port=get_open_port())
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/vllm/engine/llm_engine.py", line 1014, in _run_workers
    driver_worker_output = getattr(self.driver_worker,
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/vllm/worker/worker.py", line 94, in init_model
    init_distributed_environment(self.parallel_config, self.rank,
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/vllm/worker/worker.py", line 275, in init_distributed_environment
    cupy_utils.init_process_group(
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/vllm/model_executor/parallel_utils/cupy_utils.py", line 90, in init_process_group
    _NCCL_BACKEND = NCCLBackendWithBFloat16(world_size, rank, host, port)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/cupyx/distributed/_nccl_comm.py", line 70, in __init__
    self._init_with_tcp_store(n_devices, rank, host, port)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/cupyx/distributed/_nccl_comm.py", line 88, in _init_with_tcp_store
    self._store.run(host, port)
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/site-packages/cupyx/distributed/_store.py", line 100, in run
    p.start()
  File "/home/codingl2k1/.pyenv/versions/3.9.18/lib/python3.9/multiprocessing/process.py", line 118, in start
    assert not _current_process._config.get('daemon'), \
AssertionError: [address=<IP_ADDRESS>:33063, pid=156010] daemonic processes are not allowed to have children

v0.3.0到v0.3.3都不行。


Add Empty option caption documentation for drop-down widgets

Ready for merge for 7.1.

@Adam-Dupaski we are not in time with the functionality described here for the 7.1.0. Will change it to the 7.2.0. Please don't merge.

Waiting for confirmation for 7.2.0.


Docs page on mobile renders poorly

This is a Bug Report
Update styles
Problem:

Proposed Solution:
Add media for this page
Page to Update:
https://kubernetes.io/docs/home/
/assign

@Arhell can I suggest another title tweak?
“Docs page on mobile renders poorly”

resolve
/close


Replace tabs with 4 spaces in code examples for clarity

GitHub's markdown viewers, especially for code blocks, exaggerate the tab-length thereby making it difficult to read and follow.

Thanks!


issues with iOS 16.6

Just a heads up.. this seems to have broken since 2.6.3
This library misbehave on iOS 15.7.3 iOS 16.6
It doesn't close on $isPresenter is toggled false.
It doesn't respond to close on tap outside.
Please we are using your library in production please ensure you test on real device properly before pushing new update.

Hey @adesun2k, please check out version 2.7.0, issue should be fixed there. Have a nice day

Hey @adesun2k, please check out version 2.7.0, issue should be fixed there. Have a nice day

Thanks alot. God bless.

Hey @adesun2k, please check out version 2.7.0, issue should be fixed there. Have a nice day

[!] CocoaPods could not find compatible versions for pod "ExytePopupView":
In Podfile:
ExytePopupView (= 2.7.0)
None of your spec sources contain a spec satisfying the dependency: ExytePopupView (= 2.7.0).
You have either:

mistyped the name or version.
not added the source repo that hosts the Podspec to your Podfile.


BigQuery: Add "managing datasets" snippets.

Add update ACLs sample. Add update dataset expiration sample. To be included in the docs at https://cloud.google.com/bigquery/docs/managing-datasets
P.S.
I had a little trouble with the javadoc snippets script not finding the method, so I added a little logic to detect possible duplicate definitions. In this case the script was catching a usage of the method rather than the definition.

Note: tests pass locally.
$ mvn -Dtest=ITDatasetInfoSnippets test
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for com.google.cloud:google-cloud-examples:jar:0.46.1-alpha-SNAPSHOT
[WARNING] Reporting configuration should be done in <reporting> section, not in maven-site-plugin <configuration> as reportPlugins parameter.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO] Inspecting build with total of 1 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 1 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Google Cloud Examples 0.46.1-alpha-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (enforce) @ google-cloud-examples ---
[INFO]
[INFO] --- maven-checkstyle-plugin:2.17:check (checkstyle) @ google-cloud-examples ---
[INFO] Starting audit...
Audit done.
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ google-cloud-examples ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/swast/src/google-cloud-java/google-cloud-examples/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ google-cloud-examples ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 70 source files to /Users/swast/src/google-cloud-java/google-cloud-examples/target/classes
[WARNING] bootstrap class path not set in conjunction with -source 1.7
[WARNING] /Users/swast/src/google-cloud-java/google-cloud-examples/src/main/java/com/google/cloud/examples/translate/TranslateExample.java:[187,21] setApiKey(java.lang.String) in com.google.cloud.translate.TranslateOptions.Builder has been deprecated
[WARNING] /Users/swast/src/google-cloud-java/google-cloud-examples/src/main/java/com/google/cloud/examples/storage/snippets/StorageSnippets.java:[157,24] create(com.google.cloud.storage.BlobInfo,java.io.InputStream,com.google.cloud.storage.Storage.BlobWriteOption...) in com.google.cloud.storage.Storage has been deprecated
[WARNING] /Users/swast/src/google-cloud-java/google-cloud-examples/src/main/java/com/google/cloud/examples/storage/snippets/StorageSnippets.java:[177,24] create(com.google.cloud.storage.BlobInfo,java.io.InputStream,com.google.cloud.storage.Storage.BlobWriteOption...) in com.google.cloud.storage.Storage has been deprecated
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ google-cloud-examples ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile) @ google-cloud-examples ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 20 source files to /Users/swast/src/google-cloud-java/google-cloud-examples/target/test-classes
[WARNING] bootstrap class path not set in conjunction with -source 1.7
[INFO]
[INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @ google-cloud-examples ---

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.google.cloud.examples.bigquery.snippets.ITDatasetInfoSnippets
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.427 sec - in com.google.cloud.examples.bigquery.snippets.ITDatasetInfoSnippets

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12.736 s
[INFO] Finished at: 2018-05-03T15:34:01-07:00
[INFO] Final Memory: 41M/535M
[INFO] ------------------------------------------------------------------------