Allow blueapi to publish to multiple stomp message busses simultanously

[noemifrisina]

@callumforrester

Acceptance Criteria

• Specific criteria that will be used to judge if the issue is fixed

[noemifrisina]

@CoePaul tagging fyi

[callumforrester]

Per discussion with the rest of the core team, we need to decide if it's better to do this or to have two blueapis. I will schedule a chat.

[CoePaul]

Dear all, This has already been decided - i19 have a common optics hutch ( and other common hardware, not even in the optics hutch ) and that fact imposes an irresistible bias to the software pros / cons landscape. Any meeting next week isn't going to change the two basic facts a) that the hardware bias exists b) that a decision has already been made to recognise the hardware reality I fail to see why we should have a further meeting to either c) reach the same conclusion or d) undo the correct conclusion and replace it with an alternative which ignores the imposed landscape dictated by the hardware Option c) would seem to only serve to educate people who won't work on i19. If there is a phenomenally compelling reason to ignore point a) - one which inevitably concludes in point d) then a meeting is justified. I look forward to learning whether or not such a compelling case for d) exists. If it does not I suggest You can the meeting Regards Paul

…

________________________________ From: Callum Forrester ***@***.***> Sent: 23 January 2025 09:54 To: DiamondLightSource/blueapi ***@***.***> Cc: Coe, Paul (DLSLtd,RAL,LSCI) ***@***.***>; Mention ***@***.***> Subject: Re: [DiamondLightSource/blueapi] Allow blueapi to publish to multiple stomp message busses simultanously (Issue #791) Per discussion with the rest of the core team, we need to decide if it's better to do this or to have two blueapis. I will schedule a chat. — Reply to this email directly, view it on GitHub<#791 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A4POBDAL2EKUL6XYGEL7L2D2MC34LAVCNFSM6AAAAABVS3FSECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBZGM3DANJTHA>. You are receiving this because you were mentioned.Message ID: ***@***.***> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom.

[DiamondJoseph]

Option c) would seem to only serve to educate people who won't work on i19

Education is important. I've got some questions about why 2 message busses would be necessary if blueapi is a single instance. What is being done with the messages coming off of the bus? Is this for passing information back to GDA or processing or...? I'm not sure why we couldn't use appropriate routing keys and wildcards to pass messages to specific/either/both sets of consumers?

[DiamondJoseph]

RE: physical reality of hardware, I'd like to mock up what I think is a solution that gives you two instances of blueapi- I think parallel running plans should be limited in use, scope and explicit to prevent pitfalls of synchronisation: having one hutch that is able to operate on all its devices, using the entire bluesky plans/stubs/Msg vocabulary, and still running a subset of plans in another hutch to me seems a different use case, one already provided by two instances of bluesky and conditional dodal devices:

We're already seeing this behaviour emerging in the i24 attenuator, which is Readonly and extended and made Movable, so I've used it as an example

BL = get_beamline_name("i19-1")


def allow_moves() -> bool:
    ....

@device_factory()
def attenuator() -> ReadOnlyAttenuator:  # blueapi will still see this as a BinaryFilterAttenuator/Movable when it is so
    prefix = f"{PREFIX.beamline_prefix}-ATT:"
    return BinaryFilterAttenuator(prefix) if allow_moves() else ReadOnlyAttenuator(prefix)

And then you have a series of plans:

def testing_plan(attenuator: ReadOnlyAttenuator) -> MsgGenerator:
    ...


def data_collection(attenuator: BinaryFilterAttenuator) -> MsgGenerator:
    ...

blueapi would then only instantiate read-only devices when the beamline is not able to collect data, and would not be able to run plans using those devices if the plans required moving those devices.