Product Blocks
Defining a Product Block
Warning
You should only have one root Product Block on your domain model!
A Product Block is a reusable collection of product attributes that lives under a Product Type (which we covered in the Product Types section of these docs). A Product Block allows you to define the bulk of the attributes that you want to assign to your Product definition. At it's most basic, you will have a root product block that is stored on your Product Type, as shown in the Product Types documentation. Building off of that example, let's examine a basic product block by examining the NodeBlock
product block from the example workflow orchestrator:
# Copyright 2019-2023 SURF.
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
from orchestrator.domain.base import ProductBlockModel
from orchestrator.types import SubscriptionLifecycle
from pydantic import computed_field
class NodeBlockInactive(ProductBlockModel, product_block_name="Node"):
role_id: int | None = None
type_id: int | None = None
site_id: int | None = None
node_status: str | None = None # should be NodeStatus, but strEnum is not supported (yet?)
node_name: str | None = None
node_description: str | None = None
ims_id: int | None = None
nrm_id: int | None = None
ipv4_ipam_id: int | None = None
ipv6_ipam_id: int | None = None
class NodeBlockProvisioning(NodeBlockInactive, lifecycle=[SubscriptionLifecycle.PROVISIONING]):
role_id: int
type_id: int
site_id: int
node_status: str # should be NodeStatus, but strEnum is not supported (yet?)
node_name: str
node_description: str | None = None
ims_id: int | None = None
nrm_id: int | None = None
ipv4_ipam_id: int | None = None
ipv6_ipam_id: int | None = None
@computed_field # type: ignore[misc]
@property
def title(self) -> str:
return f"node {self.node_name} status {self.node_status}"
class NodeBlock(NodeBlockProvisioning, lifecycle=[SubscriptionLifecycle.ACTIVE]):
role_id: int
type_id: int
site_id: int
node_status: str # should be NodeStatus, but strEnum is not supported (yet?)
node_name: str
node_description: str | None = None
ims_id: int
nrm_id: int
ipv4_ipam_id: int
ipv6_ipam_id: int
Breaking this product block down a bit more, we see 3 classes, NodeBlockInactive
, NodeBlockProvisioning
, and finally NodeBlock
. These three classes are built off of each-other, with the lowest level class (NodeBlockInactive
) based off of the ProductBlockModel
base class. These classes have a number of attributes, referred to as "Resource Types", which you can read more about here. Looking at this ProductBlockModel
base class tells us a lot about how to use it in our workflows:
orchestrator.domain.base.ProductBlockModel
Bases: orchestrator.domain.base.DomainModel
This is the base class for all product block models.
This class should have been called SubscriptionInstanceModel.
ProductTable Blocks are represented as dataclasses with pydantic runtime validation.
Different stages of a subscription lifecycle could require different product block definition.Mainly to support mandatory fields when a subscription is active. To support this a lifecycle specific product block definition can be created by subclassing the generic product block with keyword argument 'lifecycle' and overriding its fields.
All product blocks are related to a database ProductBlockTable object through the product_block_name
that is given as class keyword argument.
Define a product block:
>>> class BlockInactive(ProductBlockModel, product_block_name="Virtual Circuit"):
... int_field: Optional[int] = None
... str_field: Optional[str] = None
>>> class Block(BlockInactive, lifecycle=[SubscriptionLifecycle.ACTIVE]):
... int_field: int
... str_field: str
This example defines a product_block with two different contraints based on lifecycle. Block
is valid only for ACTIVE
And BlockInactive
for all other states.
product_block_name
must be defined on the base class and need not to be defined on the others
Create a new empty product block:
>>> example1 = BlockInactive() # doctest: +SKIP
Create a new instance based on a dict in the state:
>>> example2 = BlockInactive(**state) # doctest:+SKIP
To retrieve a ProductBlockModel from the database:
>>> BlockInactive.from_db(subscription_instance_id) # doctest:+SKIP
Source code in orchestrator/domain/base.py
477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 |
|
depends_on
property
depends_on: list[orchestrator.db.SubscriptionInstanceTable]
This provides a list of product blocks that this product block depends on.
in_use_by
property
in_use_by: list[orchestrator.db.SubscriptionInstanceTable]
This provides a list of product blocks that depend on this product block.
diff_product_block_in_database
classmethod
diff_product_block_in_database() -> dict[str, set[str]]
Return any differences between the attrs defined on the domain model and those on product blocks in the database.
This is only needed to check if the domain model and database models match which would be done during testing...
Source code in orchestrator/domain/base.py
582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 |
|
from_db
classmethod
from_db(
subscription_instance_id: UUID | None = None,
subscription_instance: SubscriptionInstanceTable | None = None,
status: SubscriptionLifecycle | None = None,
) -> B
Create a product block based on a subscription instance from the database.
This function is similar to from_subscription()
>>> subscription_instance_id = KNOWN_UUID_IN_DB # doctest:+SKIP
>>> si_from_db = db.SubscriptionInstanceTable.query.get(subscription_instance_id) # doctest:+SKIP
>>> example3 = ProductBlockModel.from_db(subscription_instance=si_from_db) # doctest:+SKIP
>>> example4 = ProductBlockModel.from_db(subscription_instance_id=subscription_instance_id) # doctest:+SKIP
Source code in orchestrator/domain/base.py
740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 |
|
new
classmethod
new(subscription_id: UUID, **kwargs: Any) -> B
Create a new empty product block.
We need to use this instead of the normal constructor because that assumes you pass in all required values. That is cumbersome since that means creating a tree of product blocks.
This is similar to from_product_id()
Source code in orchestrator/domain/base.py
646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 |
|
save
save(
*, subscription_id: UUID, status: SubscriptionLifecycle
) -> tuple[list[SubscriptionInstanceTable], SubscriptionInstanceTable]
Save the current model instance to the database.
This means saving the whole tree of subscription instances and separately saving all instance values for this instance. This is called automatically when you return a subscription to the state in a workflow step.
Parameters:
-
status
(orchestrator.types.SubscriptionLifecycle
) –current SubscriptionLifecycle to check if all constraints match
-
subscription_id
(uuid.UUID
) –Optional subscription id needed if this is a new model
Returns:
-
tuple[list[orchestrator.db.SubscriptionInstanceTable], orchestrator.db.SubscriptionInstanceTable]
–List of saved instances
Source code in orchestrator/domain/base.py
883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 |
|
Nesting Product Blocks
When building a more complicated product, you will likely want to start nesting layers of product blocks. Some of these might just be used by one product, but some of these will be a reference to a product block in use by multiple product types. For an example of this, let's look at the CorePortBlock
product block from the example workflow orchestrator:
Example: example-orchestrator/products/product_blocks/core_port.py
# Copyright 2019-2023 SURF.
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
from orchestrator.domain.base import ProductBlockModel
from orchestrator.types import SubscriptionLifecycle
from pydantic import computed_field
from products.product_blocks.node import NodeBlock, NodeBlockInactive, NodeBlockProvisioning
class CorePortBlockInactive(ProductBlockModel, product_block_name="CorePort"):
port_name: str | None = None
enabled: bool | None = True
ims_id: int | None = None
nrm_id: int | None = None
node: NodeBlockInactive | None = None
ipv6_ipam_id: int | None = None
class CorePortBlockProvisioning(CorePortBlockInactive, lifecycle=[SubscriptionLifecycle.PROVISIONING]):
port_name: str | None = None
enabled: bool
ims_id: int | None = None
nrm_id: int | None = None
node: NodeBlockProvisioning
ipv6_ipam_id: int | None = None
@computed_field # type: ignore[misc]
@property
def title(self) -> str:
return f"core port {self.port_name} on {self.node.node_name}"
class CorePortBlock(CorePortBlockProvisioning, lifecycle=[SubscriptionLifecycle.ACTIVE]):
port_name: str | None = None
enabled: bool
ims_id: int
nrm_id: int
node: NodeBlock
ipv6_ipam_id: int
Note in this example how the attribute node
is type-hinted with NodeBlockInactive
. This tells the WFO to bring in the entire tree of product blocks that are referenced, in this case, NodeBlockInactive
when you load the CorePortBlockInactive
into your workflow step. To read more on this concept, read through the Product Modelling page in the architecture section of the docs.
Creating Database Migrations
Just like Product types, you'll need to create a database migration to properly wire-up the product block in the orchestrator's database. A migration file for this example NodeBlock model looks like this:
Example: example-orchestrator/migrations/versions/schema/2023-10-27_a84ca2e5e4db_add_node.py
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 |
|
Thankfully, you don't have to write these database migrations by hand, you can simply use the main.py db migrate-domain-models
command that is part of the orchestrator CLI, documented here.
Automatically Generating Product Types
If all of this seems like too much work, then good news, as all clever engineers before us have done, we've fixed that with YAML! Using the WFO CLI, you can generate your product types directly from a YAML. For more information on how to do that, check out the CLI generate
command documentation.