[Bug 2031658] [NEW] Virtualized nvme-of test case for nvme-stas

[Mateus Rodrigues de Morais]

Public bug reported:

This task was recommended as a TODO during the nvme-stas MIR review
(https://pad.lv/2026591).

Original comment:

  We are currently in discussions to make it easier for software that needs
  special hardware to get into main. And this is IMHO such a case. Gladly it
  only provides usability sugar over what components that are already in main
  (kernel, libnvme, nvme-cli) already provide. But I've not heard about testing
  on actual nvme-of hardware. I'd like to ask you to read through [1][2] where
  we list some ideas how a case like that could be overcome.
  As often there are so many alone the lower transport nvmet-rdma or a real
  adapter loading qla2xxx adapter or nvme_tcp - but one would be better than
  none; Maybe you can even test this fully virtual - think of two qemu guests,
  one with emulated NVME which it provides via nvme_tcp and the other the client
  that does access it, test write/loads some and disconnects. Add the auto
  discovery of stafd/stacd on top and this might be great.
  To be clear - all that this package adds - is tested well, so this is only
  a recommended task but if possible would help to QA the whole stack regularly.

  [1]: https://github.com/canonical/ubuntu-mir/pull/31
  [2]: https://github.com/canonical/ubuntu-mir/issues/30

** Affects: nvme-stas (Ubuntu)
     Importance: Undecided
         Status: New

** Description changed:

  This task was recommended as a TODO during the nvme-stas MIR review:
  
  Original comment:
  
-   We are currently in discussions to make it easier for software that needs
-   special hardware to get into main. And this is IMHO such a case. Gladly it
-   only provides usability sugar over what components that are already in main
-   (kernel, libnvme, nvme-cli) already provide. But I've not heard about testing
-   on actual nvme-of hardware. I'd like to ask you to read through [1][2] where
-   we list some ideas how a case like that could be overcome.
-   As often there are so many alone the lower transport nvmet-rdma or a real
-   adapter loading qla2xxx adapter or nvme_tcp - but one would be better than
-   none; Maybe you can even test this fully virtual - think of two qemu guests,
-   one with emulated NVME which it provides via nvme_tcp and the other the client
-   that does access it, test write/loads some and disconnects. Add the auto
-   discovery of stafd/stacd on top and this might be great.
-   To be clear - all that this package adds - is tested well, so this is only
-   a recommended task but if possible would help to QA the whole stack regularly.
+   We are currently in discussions to make it easier for software that needs
+   special hardware to get into main. And this is IMHO such a case. Gladly it
+   only provides usability sugar over what components that are already in main
+   (kernel, libnvme, nvme-cli) already provide. But I've not heard about testing
+   on actual nvme-of hardware. I'd like to ask you to read through [1][2] where
+   we list some ideas how a case like that could be overcome.
+   As often there are so many alone the lower transport nvmet-rdma or a real
+   adapter loading qla2xxx adapter or nvme_tcp - but one would be better than
+   none; Maybe you can even test this fully virtual - think of two qemu guests,
+   one with emulated NVME which it provides via nvme_tcp and the other the client
+   that does access it, test write/loads some and disconnects. Add the auto
+   discovery of stafd/stacd on top and this might be great.
+   To be clear - all that this package adds - is tested well, so this is only
+   a recommended task but if possible would help to QA the whole stack regularly.
+ 
+   [1]: https://github.com/canonical/ubuntu-mir/pull/31
+   [2]: https://github.com/canonical/ubuntu-mir/issues/30

** Summary changed:

- Virtualized nvme-of test case for package
+ Virtualized nvme-of test case for nvme-stas

** Description changed:

- This task was recommended as a TODO during the nvme-stas MIR review:
+ This task was recommended as a TODO during the nvme-stas MIR review
+ (https://pad.lv/2026591):
  
  Original comment:
  
    We are currently in discussions to make it easier for software that needs
    special hardware to get into main. And this is IMHO such a case. Gladly it
    only provides usability sugar over what components that are already in main
    (kernel, libnvme, nvme-cli) already provide. But I've not heard about testing
    on actual nvme-of hardware. I'd like to ask you to read through [1][2] where
    we list some ideas how a case like that could be overcome.
    As often there are so many alone the lower transport nvmet-rdma or a real
    adapter loading qla2xxx adapter or nvme_tcp - but one would be better than
    none; Maybe you can even test this fully virtual - think of two qemu guests,
    one with emulated NVME which it provides via nvme_tcp and the other the client
    that does access it, test write/loads some and disconnects. Add the auto
    discovery of stafd/stacd on top and this might be great.
    To be clear - all that this package adds - is tested well, so this is only
    a recommended task but if possible would help to QA the whole stack regularly.
  
-   [1]: https://github.com/canonical/ubuntu-mir/pull/31
-   [2]: https://github.com/canonical/ubuntu-mir/issues/30
+   [1]: https://github.com/canonical/ubuntu-mir/pull/31
+   [2]: https://github.com/canonical/ubuntu-mir/issues/30

** Description changed:

  This task was recommended as a TODO during the nvme-stas MIR review
- (https://pad.lv/2026591):
+ (https://pad.lv/2026591).
  
  Original comment:
  
    We are currently in discussions to make it easier for software that needs
    special hardware to get into main. And this is IMHO such a case. Gladly it
    only provides usability sugar over what components that are already in main
    (kernel, libnvme, nvme-cli) already provide. But I've not heard about testing
    on actual nvme-of hardware. I'd like to ask you to read through [1][2] where
    we list some ideas how a case like that could be overcome.
    As often there are so many alone the lower transport nvmet-rdma or a real
    adapter loading qla2xxx adapter or nvme_tcp - but one would be better than
    none; Maybe you can even test this fully virtual - think of two qemu guests,
    one with emulated NVME which it provides via nvme_tcp and the other the client
    that does access it, test write/loads some and disconnects. Add the auto
    discovery of stafd/stacd on top and this might be great.
    To be clear - all that this package adds - is tested well, so this is only
    a recommended task but if possible would help to QA the whole stack regularly.
  
    [1]: https://github.com/canonical/ubuntu-mir/pull/31
    [2]: https://github.com/canonical/ubuntu-mir/issues/30

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nvme-stas in Ubuntu.
https://bugs.launchpad.net/bugs/2031658

Title:
  Virtualized nvme-of test case for nvme-stas

Status in nvme-stas package in Ubuntu:
  New

Bug description:
  This task was recommended as a TODO during the nvme-stas MIR review
  (https://pad.lv/2026591).

  Original comment:

    We are currently in discussions to make it easier for software that needs
    special hardware to get into main. And this is IMHO such a case. Gladly it
    only provides usability sugar over what components that are already in main
    (kernel, libnvme, nvme-cli) already provide. But I've not heard about testing
    on actual nvme-of hardware. I'd like to ask you to read through [1][2] where
    we list some ideas how a case like that could be overcome.
    As often there are so many alone the lower transport nvmet-rdma or a real
    adapter loading qla2xxx adapter or nvme_tcp - but one would be better than
    none; Maybe you can even test this fully virtual - think of two qemu guests,
    one with emulated NVME which it provides via nvme_tcp and the other the client
    that does access it, test write/loads some and disconnects. Add the auto
    discovery of stafd/stacd on top and this might be great.
    To be clear - all that this package adds - is tested well, so this is only
    a recommended task but if possible would help to QA the whole stack regularly.

    [1]: https://github.com/canonical/ubuntu-mir/pull/31
    [2]: https://github.com/canonical/ubuntu-mir/issues/30

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvme-stas/+bug/2031658/+subscriptions