Hi Richard, looks good. Just did an
update network_offerings set service_offering_id = <new service offering id> where id = <id of network_offering to change> and restarted one of the networks from this offering with cleanup. Comes up nicely and new tags are taken into account. Do you use this procedure in production to change tags and parameters like cpus, ram? Could gain lots of flexibility if this is safely possible. Greetings, Melanie Am Montag, den 04.11.2019, 15:45 +0000 schrieb Richard Lawley: > There's nothing in the API or the UI. We just change it in the DB. > > On Mon, 4 Nov 2019 at 13:48, Melanie Desaive > <m.desa...@heinlein-support.de> wrote: > > Hi Richard, > > > > thank you for this hint. > > > > I had a look in the database, and yes, all Network Offeringns in > > the > > table network_offerings still reference the old System/Disk > > offering > > IDs from disk_offering/system_offering. > > > > Is there an intended way to change > > "network_offerings.service_offering_id" for an existing network > > offering? Would it be ok to update the database? Is there an API > > call? > > I did not find anything in the documentation. > > > > Kind regards, > > > > Melanie > > > > > > > > Am Freitag, den 01.11.2019, 09:25 +0000 schrieb Richard Lawley: > > > Melanie, > > > > > > > Maybe the procedure for resetting the System Offering for > > > > Virtual > > > > Routers differs from that for SSVM and CP and I missed some > > > > point? > > > > > > The System Offering for Virtual Routers is not taken from the > > > same > > > place as SSVM/CP - it's set on the Network Offering instead, so > > > you > > > can have different network offerings with different system > > > offerings. > > > > > > Regards, > > > > > > Richard > > > > > > On Fri, 1 Nov 2019 at 08:33, Melanie Desaive > > > <m.desa...@heinlein-support.de> wrote: > > > > Good morning Andrija, > > > > > > > > yes, I did restart mgmt. Documentation states that. > > > > > > > > Interestingly the documentation in > > > > http://docs.cloudstack.apache.org/en/4.11.1.0/adminguide/service_offerings.html#changing-the-default-system-offering-for-system-vms > > > > only mentions only resetting the unique_names for Secondary > > > > Storage > > > > VM > > > > and Console Proxy VM not for the Virtual Routers in the > > > > database. > > > > > > > > Maybe the procedure for resetting the System Offering for > > > > Virtual > > > > Routers differs from that for SSVM and CP and I missed some > > > > point? > > > > > > > > Greetings, > > > > > > > > Melanie > > > > > > > > Am Donnerstag, den 31.10.2019, 17:19 +0100 schrieb Andrija > > > > Panic: > > > > > tried restarting mgmt after tag change? Usually not required > > > > > but > > > > > might be > > > > > for systemVMs. > > > > > > > > > > On Thu, 31 Oct 2019, 15:21 Melanie Desaive, < > > > > > m.desa...@mailbox.org> > > > > > wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > I just tried to set up storage tags for System VMs, but the > > > > > > behaviour > > > > > > is not as expected. The deployment planner does not seem to > > > > > > take > > > > > > the > > > > > > storage tag into account when deciding over the storage. > > > > > > > > > > > > -- > > > > > > > > > > > > The only storage with the tag "SYSTEMV" ist "ACS-LUN-SAS- > > > > > > 01' > > > > > > with > > > > > > id=10 > > > > > > > > > > > > mysql> select id,name,tag from storage_pool_view where > > > > > > cluster_name > > > > > > = > > > > > > 'cluster2' and status = 'Up' and tag = 'SYSTEMVM' order by > > > > > > name,tag; > > > > > > +----+----------------+----------+ > > > > > > > id | name | tag | > > > > > > +----+----------------+----------+ > > > > > > > 10 | ACS-LUN-SAS-01 | SYSTEMVM | > > > > > > +----+----------------+----------+ > > > > > > 1 row in set (0,00 sec) > > > > > > > > > > > > -- > > > > > > > > > > > > I definied the tag "SYSTEVM" for the System Offering for > > > > > > the > > > > > > Virtual > > > > > > Routers: > > > > > > > > > > > > mysql> select id,name,unique_name,type,state,tags from > > > > > > disk_offering > > > > > > where type='Service' and state='Active' and unique_name > > > > > > like > > > > > > 'Cloud.Com-SoftwareRouter' order by unique_name \G > > > > > > *************************** 1. row > > > > > > *************************** > > > > > > id: 281 > > > > > > name: System Offering For Software Router - With > > > > > > Tags > > > > > > unique_name: Cloud.Com-SoftwareRouter > > > > > > type: Service > > > > > > state: Active > > > > > > tags: SYSTEMVM > > > > > > 1 row in set (0,00 sec) > > > > > > > > > > > > -- > > > > > > > > > > > > But when I redeploy a virtual Router the deployment planner > > > > > > takes > > > > > > all > > > > > > storages into account. :( > > > > > > > > > > > > The log saies explicitely "Pools matching tags..." and > > > > > > lists > > > > > > several > > > > > > other pools. > > > > > > What do I miss? > > > > > > > > > > > > -- > > > > > > ClusterScopeStoragePoolAllocator looking for storage pool > > > > > > Looking for pools in dc: 1 pod:1 cluster:3. Disabled > > > > > > pools > > > > > > will > > > > > > be > > > > > > ignored. > > > > > > Found pools matching tags: [Pool[7|PreSetup], > > > > > > Pool[9|PreSetup], > > > > > > Pool[10|PreSetup], Pool[18|PreSetup]] > > > > > > ClusterScopeStoragePoolAllocator returning 3 suitable > > > > > > storage > > > > > > pools > > > > > > ClusterScopeStoragePoolAllocator looking for storage pool > > > > > > Looking for pools in dc: 1 pod:1 cluster:3. Disabled > > > > > > pools > > > > > > will > > > > > > be > > > > > > ignored. > > > > > > Found pools matching tags: [Pool[7|PreSetup], > > > > > > Pool[9|PreSetup], > > > > > > Pool[10|PreSetup], Pool[18|PreSetup]] > > > > > > ClusterScopeStoragePoolAllocator returning 3 suitable > > > > > > storage > > > > > > pools > > > > > > -- > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > Melanie > > > > > >
