Jump to: navigation, search

Difference between revisions of "Trove/MeetingAgendaHistory"

Line 1: Line 1:
 
= Trove Weekly Meeting Agenda History (2016)  =
 
= Trove Weekly Meeting Agenda History (2016)  =
 +
 +
== Trove Meeting, Jan 13, 2016 ==
 +
* [cp16net] Trove pulse update
 +
** http://bit.ly/1VQyg00
 +
* [peterstac] Use of TODO in the source code
 +
** I've noticed that we have a tendency to use the *TODO* marker in the code to remind ourselves of things that need to be done (usually out of scope of the current changeset).  While this is admirable, I believe that entering a bug in launchpad is a better solution.  I'd like to see how others feel about this.
 +
* [amrith] Recent "Spam of Patches"
 +
** See ML: http://openstack.markmail.org/thread/yx6hgouzu5wzrf5m
 +
** The term "Spam of Patches" is not something I came up with
 +
** These patches are taking a lot of bandwidth, from reviews, from the gate, and for merges that we really want to land into Mitaka
 +
** How do we want to handle these from now to Mitaka release date?
 +
* [amrith] HBase (again)
 +
** Last week, I posted a message to the ML as promised
 +
** See http://openstack.markmail.org/thread/yx6hgouzu5wzrf5m
 +
** Later reposted with [sahara] in subject, http://openstack.markmail.org/thread/x5uirwolkknlorr3
 +
** As expected, the feedback from several was that we should consider sahara for hbase full distributed mode
 +
** Which we plan to do, anyway. But that's not for this phase.
 +
** This phase is only standalone and pseudo-distributed, both of which are single node.
 +
* Open Discussion
  
 
== Trove Meeting, Jan 6, 2016 ==
 
== Trove Meeting, Jan 6, 2016 ==

Revision as of 19:08, 13 January 2016

Contents

Trove Weekly Meeting Agenda History (2016)

Trove Meeting, Jan 13, 2016

  • [cp16net] Trove pulse update
  • [peterstac] Use of TODO in the source code
    • I've noticed that we have a tendency to use the *TODO* marker in the code to remind ourselves of things that need to be done (usually out of scope of the current changeset). While this is admirable, I believe that entering a bug in launchpad is a better solution. I'd like to see how others feel about this.
  • [amrith] Recent "Spam of Patches"
    • See ML: http://openstack.markmail.org/thread/yx6hgouzu5wzrf5m
    • The term "Spam of Patches" is not something I came up with
    • These patches are taking a lot of bandwidth, from reviews, from the gate, and for merges that we really want to land into Mitaka
    • How do we want to handle these from now to Mitaka release date?
  • [amrith] HBase (again)
  • Open Discussion

Trove Meeting, Jan 6, 2016

  • [cp16net] Trove pulse update
  • trove-dashboard reporting bugs/bp
  • Announcements
  • Looking for comments (Trove meets HBase)
    • https://review.openstack.org/#/c/256079/
    • I am not looking for comments on the spec in the meeting. Rather there seems to be an issue about whether Trove should even go hear HBase or whether we should just say that's Sahara's turf. A question was raised in the spec review of whether this has been discussed on the ML. I'm happy to post the question on the ML but before I did that, I wanted to poll the team to see what people felt. It is my belief that HBase is a database and offering support for HBase through Trove, where Trove provisions and manages the instances independent of Sahara, is something of value. I realize that there are others who feel differently. The code is up there for review as well (see https://review.openstack.org/#/c/262048/ and https://review.openstack.org/#/c/262815).
  • Open Discussion

Trove Weekly Meeting Agenda History (2015)

Agenda for Jan 28th

  • Review #147908: Try to gain some consensus on how to resolve the issues itemized in final review comment.

Agenda for Jan 21st

  • Review #131610 : Security concerns, continued from the previous meeting + general review

Agenda for Feb 4th

  • Meeting canceled due to mid-cycle in Seattle

Agenda for February 18 2015

Agenda for February 25 2015

  • Trove pulse update:
  • [amrith] Need reviewers for 157140 [1]
    • Would like to have people look at this and consider it for merging quickly as there are other patch sets that will be impacted by it, especially the one reorganizing the guestagent code, anything that wants to add a new datastore, etc.,
    • There have been some comments (Simon, Ashleigh, Sushil) that I've tried to address in a reply but I would like some positive (or negative) reviews. Ok, I'd like some positive reviews ;)
  • [doug] Discuss 147908 [2]
    • There are a couple of options for how to proceed on this change and it would be good to get it into Kilo-3.
  • [schang] Discuss 136918 [3]
    • Discuss the comment thread at point #3 under the Guest Agent section. Need to decide what to do with the common code.
  • [amrith] Trove Liberty Mid Cycle Sprint -- Initial planning
  • [sushilkm] Needed reviewers for Vertica work
    • Looking forward for people to look at the Vertica work, the spec, trove-integration and trove patches.
    • The list of patchsets for the work is as follows:
  1. trove-specs: https://review.openstack.org/151126
  2. trove-integration: https://review.openstack.org/156149
  3. trove: https://review.openstack.org/156486

Agenda for March 4 2015

Trove Meeting, March 11, 2015

Trove Meeting, March 18, 2015

Trove Meeting, March 25, 2015

Trove Meeting, April 1, 2015


Trove Meeting, April 8, 2015

Trove Meeting, April 15, 2015 CANCELED

Trove Meeting, April 22, 2015

Trove Meeting, April 29, 2015 CANCELED

Trove Meeting, May 6, 2015

  • [SlickNik] Trove pulse update:
  • [schang]
    • We need to discuss this patchset, vote for an implementation option, and move forward: https://review.openstack.org/#/c/164640/9
    • Option 1: Define a default usage_timeout setting at the global level, the setting is optional at the datastore level, used only for the purpose of overriding the global default value.
    • Option 2: Define a mandatory usage_timeout option for each datastore.
    • These two options are mutually exclusive, meaning if we've already defined the option at the global level, and if the datastore is OK with the default value, it shouldn't be mandatory to re-specify the same default value at the datastore level.
    • The current patchset is implementing BOTH option 1 and 2.

Trove Meeting, May 27, 2015

  • [SlickNik] Trove pulse update:
  • [amrith] Do we need all these new hacking rules?
    • Changes have been proposed for inclusion of the following hacking rules [copied from commit message without validation]. E128, E265, E713, H238, E111, E122, E123, E128, E251, E265, E713, H105, H306, H404. (four changes, 3 in trove, one in trove-client)
    • When some hacking rule changes were proposed the last time (https://review.openstack.org/#/c/104616/ for example) the discussion at the Trove meeting was two-fold. First, that we didn't want to add all of these new hacking rules as they had limited upside. The second was that we'd consider reviewing them as a group before accepting changes. I'd like the group to consider all of these changes before we all spend time reviewing them. I would also like to have the ones for trove consolidated into one change to reduce the merge issues.
    • Personally, I find many of these hacking rules to have minimal benefit (if any). But I would rather we discuss them as a group before we all spend cycles reviewing them and then deciding (correctly) not to incorporate them as we have done in the past.
  • [amrith] Setting trove meeting agenda through git?
    • I saw this email on the ML this morning [4]
    • Does this change anything for us?
  • [peterstac] Switching blueprint ownership/details
  • [vkmc] Trove production deploy. Security concerns and how are we going to tackle those.
    • During the design sessions we talked about the security concern wrt RabbitMQ and the Trove instances living in public tenants.

There are several solutions proposed. Do we have a preference among those?

  • [vkmc] Trove multitenancy.
    • Has this came up in the past? What is the Trove community stand on that? Is it in our future plans?

Trove Meeting, June 3, 2015

Trove Meeting, June 10, 2015

Trove Meeting, July 01, 2015

Trove Meeting, July 08, 2015

  • [SlickNik] Trove pulse update:
  • [amrith] https://review.openstack.org/#/c/189837/
    • To get to the bottom of the new/existing security hole.
  • [amrith] Trove-compatible images creation automation
    • This was touched upon last week and some discussion ensued. I don't think a conclusion was reached so I'd like to see if we could reach some finality on this. Specifically, who's doing what? What is the proposed 'feature' or 'implementation', could we have a BP for this, or use the review process to discuss this, which we've found to be effective with BP's (when we moved away from the BP meeting), etc.,

Trove Meeting, July 15, 2015

Trove Meeting, July 22, 2015

Trove Meeting, July 29, 2015

[cp16net] thoughts here on datastore registration spec

  1. the api should be modeled around the objects so that it makes sense in a restful way
  2. if we need a way to make things even easier like this helper that does multiple calls from a single command this might call for a new api call
  3. calling multiple api call from a single cmd gets the job done but seems wrong

[SlickNik] I'm personally leaning towards having a unified API (create of datastore and datastore-version in a single call). Some of my thoughts on the matter:

  1. This aims for simplifying our API, not simplifying our python-client experience -- simplifying our APIs would implicitly lead to a simpler client experience across all clients -- not just the python-troveclient.
  2. Having a one-to-one mapping between our REST resources and our data-access CRUD objects is not a necessity. It might even be undesirable in this case since it pushes a lot of the logic to the clients and introduces a tighter coupling between the logic on the client and the data access objects on the server.
  3. I've gotten feedback from multiple folks saying that there is currently not much purpose to defining a datastore separate from a datastore version. The experience would be much better if you're just able to define this in a single call.
  4. Having a unified API (datastore, datastore-version in a single call) does not prevent us from, in the future, adding new datastore CRUD calls if we feel like it is an absolute necessity that we must extend properties / metadata at a datastore level.

Trove Meeting, Aug 5, 2015

  • [sushilkm] Datastore registration spec open questions, https://review.openstack.org/188072
    • We talked a little about this in last week but want to bring this around to close on it.
    • Question which need to be answered to move on this spec.
      • Should the api be simple CRUD operations on each object? (i.e. CRUD on datastores and versions separate) or make the API simplified where we really only care about the version when we update the image on an existing version or create a new version?
    • Thoughts from SlickNik and cp16net were there on last weeks agenda too, https://wiki.openstack.org/wiki/Trove/MeetingAgendaHistory#Trove_Meeting.2C_July_29.2C_2015,

Trove Meeting, Aug 19, 2015

Trove Meeting, Sept 2, 2015

Trove Meeting, Sept 9, 2015

Trove Meeting, Sept 23, 2015

Trove Meeting, Sept 30, 2015

Trove Meeting, Oct 7, 2015

  • Trove community and containers [mlowery]
    • Is there any plan to adopt containers (e.g. Docker) in any way in Trove within the community?
      • Example: Put the guest agent in a container. Upgrade it by replacing the container. (You no longer have to care about the current state of the guest (the existing bits)--just replace it.) The same approach could be taken with the datastore itself: put it in a container.
    • Is there any plan to adopt container orchestration (e.g. Kubernetes) in any way in Trove within the community?
      • Example: Kubernetes handles scheduling, updating, and scaling (including auto-healing). Some of these are Nova/Heat-like. Some of these (like auto-healing) don't exist. Is auto-healing in Trove's charter? Could Kubernetes or Magnum be a pluggable "orchestration driver" within Trove?
  • Is it time to merge https://review.openstack.org/#/c/220288/1 [amrith]
    • This change was made during the end of the last cycle to kick up the timeout for some jobs that were failing
    • Is it time to merge this change (revert the earlier one) and work on the timeout issue properly?

Trove Meeting, Oct 14, 2015

Trove Meeting, Oct 21, 2015

Trove Meeting, Oct 28, 2015

Skipped due to Summit

Trove Meeting, Nov 4, 2015

Trove Meeting, Nov 11, 2015

Trove Meeting, Nov 18, 2015

Trove Meeting, Dec 2, 2015

Trove Meeting, Dec 9, 2015

Trove Meeting, Dec 16, 2015

Trove Meeting, Dec 23, 2015

Skipped due to Holidays

Trove Meeting, Dec 30, 2015

Skipped due to Holidays

Trove Weekly Meeting Agenda History (2014)

Agenda for Mar. 19

Agenda for Mar. 26

Agenda for Apr. 2

  • Icehouse RC1 cut and Juno branch open
  • ATL Dev Summit topics
  • Open discussion

Agenda for Apr. 9

Agenda for Apr. 16

Agenda for Apr. 23

  • Juno Mid-cycle Meetup - discuss venue/timing proposal and confirm

Agenda for Apr. 30

  • Establish policy for disk image builder elements for datastores [mat-lowery]
    • Do we require elements for both Ubuntu and Fedora when a Gerrit change introduces a new datastore or version?
      • Cassandra and Couchbase are examples of datastores that don't currently have Fedora elements. https://review.openstack.org/77461 and https://review.openstack.org/79413 are examples of Gerrit changes that have been -1ed because of lack of Fedora elements.
      • Isn't one working element better than none? If both are required, is that inviting lower quality on the other element the user is required to code but never uses?
      • Are Fedora elements tested in an automated way as the Ubuntu elements are? Reasoning: Yes they were submitted with the Gerrit change, but do they work?
      • Is the policy that Trove requires both Fedora and Ubuntu support for each manager on day one? There is already a lack of parity across datastore managers--not all can do backup and restore (but ultimately I assume they will). Why can't Trove take distro support piecemeal just like it does the datastore operations?
      • mat-lowery (talk) Wed Apr 30 19:17:28 UTC 2014
        • Result: <SlickNik> Let's table this for now.
    • What about Package Install vs. Tarball Install vs. Source Install? Is there a requirement on how the bits are laid down?
      • If packages are required, what are the acceptable sources? (Example: Redis currently uses a PPA.)
      • Does the decision here have repercussions on datastore upgrades?
      • mat-lowery (talk) Wed Apr 30 19:17:28 UTC 2014
        • Result: <SlickNik> So allow [PPAs]. But let's make a best effort to follow this order: distro package, project maintainer PPA, some random PPA.
  • Open Items
    • Clarification on commit message style guidelines (slicknik): We've been having a lot of -1 reviews on commit message style and I wanted to clarify some of this so that we can reduce review churn caused by this. Goal: Have a clear understanding on when a commit message should be -1'ed.

Agenda for May 7

  • How do Gerrit changes get approved? [mat-lowery]
    • Goal: To clarify the Gerrit change approval process used by Trove core (for the benefit of core and non-core).
      • Core potentially benefits by establishing a process that all core follows (and possibly swap best practices).
        • What if all core used a prioritized queue such as ReviewDay? If you're not using a prioritized queue, how do you prevent starvation?
      • Non-core potentially benefits by making the process transparent and setting expectations.
        • "Hey core, please review <change>" is inefficient and unfair. The priority (such as that calculated by ReviewDay) should be the sole indicator of review/approval priority.
    • Goal: To reduce the time from submittal to approval and prevent Gerrit change starvation.
      • My first-ever Trove submittal is nearly three months old. Why is that?
      • Establish Gerrit "etiquette."
        • No leaving -1s and then disappearing. A reviewer that leaves a -1 has an obligation to respond to follow up questions.
        • No leaving -1s for nice-to-haves. That's what 0 is for.
        • No leaving -1s for questions about why something was done. Again, use a 0.
        • No leaving -1s for something minor when there are five +1s.
        • Leaving a -1 has the potential to cause the author to "reset the counter" (because he has to submit a new revision) on age-influenced priorities (such as ReviewDay). Think hard before you leave that -1.
    • More details on the mailing list.
  • Meetings cancelled next week since most folks will be at the ATL summit [slicknik]

May 14 meeting canceled

Agenda for May 21

Agenda for May 28

Agenda for Jun 4

Agenda for Jun 11

Agenda for Jun 25

  • Integration-tests update (SlickNik)
  • "Vertica Datastore patch review" why no reviews ? (SnowDust)

Agenda for July 2

Agenda for July 9

  • Scrub / Update Docs (SlickNik): The following need to be scrubbed. I'd like to get a few volunteers to take a look at each one of these, identify areas where they are deficient, and help fix them. Areas to update are tracked at https://etherpad.openstack.org/p/trove-doc-items.
    • Developer Docs
    • Deployment Guide
    • API Doc
    • Config Options help strings
    • Manual Trove Install Doc

Agenda for July 16

Agenda for July 23

Agenda for Aug 06

Agenda for Aug 13

Agenda for Aug 27

Agenda for Sep 3

Agenda for Sep 10

  • Clusters Migration and Downgrades (schang)
    • The new v32 clusters migration script creates a foreign key constraint between the clusters table and the database_versions table, but it's downgrade script do not cleanup the table and the foreign key constraint, causing the v16 downgrade to fail on dropping the database_versions table.
    • To ensure error free downgrades moving forward, we have these options:
      • All migration scripts' downgrade needs to cleanup tables and foreign key constraints:
        • Nobody currently do downgrade migrations on a production system. Shouldn't downgrade's purpose be allowing devs to perform hard resets on their test databases? If test data preservation is needed, the dev should manually backup and restore the table.
        • Establish version points at which downgrade is not permitted. e.g. Downgrade v32 -> v25 is allowed, but you can't downgrade from latest to anything pre v25.
      • Only test the upgrade path in the test script.
      • Remove all downgrade routines and don't support downgrade migrations at all.
    • Action Item: Discuss the above options and decide on an approach.
    • Review: https://review.openstack.org/#/c/117291/
    • Error log: http://logs.openstack.org/91/117291/3/check/gate-trove-python27/6074fb4/console.html.gz
    • Related IRC discussions: http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%23openstack-trove.2014-08-27.log

Agenda for Sep 17

Agenda for Sep 24

Agenda for Oct 8

Agenda for Oct 15th

  • Discuss the timing of trove-guestagent refactoring. This is a big change and it would help to reduce rebasing if this was fast tracked or put on hold until other patches land. (rmyers)

Agenda for Oct 29th

  • [denis_makogon]
    • https://review.openstack.org/#/c/102838/ - During bug discussion (using report comments) was made unformal decision to mark all running backups as FAILED if instance is being deleted. But this checkin was marked with -2 from Auston (for more info see checkin comments). I'd like to discuss it and find suitable way for all of us.
    • https://review.openstack.org/#/c/130519/ - As we are all know that incremental backup can silently be executed as full backup because there's no incremental strategy for given backup strategy. This fix aims to fix it. But Amrith keep voting with -1 because he thinks that fix can be shorter. More info you can find out checkin comments. My idea is to have common validation method that executes specific logic depending on operation type. So, i'd like to hear concrete feedback from other contributors and find suitable way to fix it.
    • https://gist.github.com/denismakogon/15561df6dc5ddc60ba74 - We need to find proper way to handle cluster extension procedure using CLI. Also, as it was discussed, once clustering is merged we might proceed with changing existing python-troveclient framework (for more information see GIST).
  • [amrith]
    • Since the meeting next monday (BP meeting) will likely be preempted by the summit in Paris, I'd like to get some focus on a blueprint to allow users to retrieve guest log files. Please review https://review.openstack.org/#/c/131610/. I have re-written this specification and (with her permission) listed Iccha as the mentor of the person who will be implementing this.

Agenda for Nov 19th

  • Looking for reviews to oslo-incubator changes
    • 129292, Obsolete oslo-incubator modules - unused modules
    • 129294, Obsolete oslo-incubator modules - timeutils
    • 129714, Obsolete oslo-incubator modules - gettextutils (now oslo.i18n)
    • 129664, Obsolete oslo-incubator modules - network_utils (now netutils)
    • 129654, Obsolete oslo-incubator modules - excutils
    • 129295, Obsolete oslo-incubator modules - lockutils
    • 129663, Obsolete oslo-incubator modules - strutils
    • 129378, Obsolete oslo-incubator modules - importutils
    • 129668, Obsolete oslo-incubator modules - jsonutils (now oslo.serialization)
    • 133068, Obsolete oslo-incubator modules - wsgi
    • 133051, Obsolete oslo-incubator modules - exception
  • Better documentation for Image building
    • Goal: This was identified as an area of confusion in the summit. Identify what the next steps here are and establish a timeline for fixing this.
  • Trove Mid Cycle Sprint in Seattle, WA
  • Trove Cross Project Liasons

Agenda for Nov 26th

  • Dates for Trove Kilo Mid-Cycle sprint
  • Trove BP meeting -- to bp or not to bp?

Agenda for Dec 3rd

  • [amrith] Discuss merge order for various OSLO related patches
  • [amrith] Discuss status of moving guest agent to its own repository patch set

Trove Blueprint Meeting Agenda History (2014)

For those interested, we have blueprint meetings in #openstack-trove weekly, Mondays at 18:00 UTC. Feel free to add items in the agenda below.

Agenda for Mar. 31

Networking related blueprints:

Others:

Agenda for Apr. 7

Agenda for Apr. 14

Agenda for Apr. 21

Agenda for April 28

Agenda for May 5

Meeting Cancelled May 12

Agenda for May 19

  • Trove client for cross-region-backup [esmute]
    • https://blueprints.launchpad.net/trove/+spec/cross-region-backup-availability
    • amcrn (talk) 18:24, 19 May 2014 (UTC): Meeting Minutes: this was originally scheduled due to concerns with introducing a new field called "region". at the time, there was no consensus as to whether namespacing should be used (arn-style), etc. during the summit, we reached a consensus (in the clustering talks) that a "region" field is the way to go, and therefore there's no action items here.
  • Add visibility filter to datastores [iccha]
    • https://blueprints.launchpad.net/trove/+spec/datastore-visibility
    • amcrn (talk) 18:24, 19 May 2014 (UTC): Meeting Minutes: consensus is that if is_active is 0, then only if the tenant-id is in a whitelist (new table?) will they be able to use and see the datastore-version. this is more aligned with how glance deals with images vs. what's proposed in the orginal spec here (a simple admin-only).
  • Database log files manipulations [denis_makogon]
    • https://blueprints.launchpad.net/trove/+spec/dbinstance-log
    • amcrn (talk) 18:54, 19 May 2014 (UTC): Meeting Minutes: the following modifications are required for approval (1) adding posix created/modified timestamp fields on the response so that a user knows when the log was last touched and/or rotated (2) use configuration-groups for configuration parameters (vs. introducing the mapping in the code) (3) fix a few bugs in the blueprint, including inconsistent usage of underscore vs. hyphen in naming, and datastore_log_files should be an array.


amcrn (talk) 19:04, 19 May 2014 (UTC): the items below by boden are being tabled at the moment (pending confirmation of sponsorship and a discussion surrounding the precedent this sets). amrith to send an email to boden to sync up.

Agenda for Jun 2

slicknik (talk) 21:22, 2 June 2014 (UTC) There were concerns around whether keystone trusts is fully done yet, and what other OpenStack projects are going to use this. We had a vote, and the unanimous result was to wait and watch for now.

slicknik (talk) 21:22, 2 June 2014 (UTC) Approved. There was one small concern about backward-compat with the GET /flavors api call which should be addressed.

slicknik (talk) 21:22, 2 June 2014 (UTC) Needs more detail as to what phase 2 will actually entail. Denis to update the bp with more details.

slicknik (talk) 21:22, 2 June 2014 (UTC) Approved

slicknik (talk) 21:22, 2 June 2014 (UTC) Approved

slicknik (talk) 21:22, 2 June 2014 (UTC) Needs more information regarding. Boden to update the BP.

slicknik (talk) 21:22, 2 June 2014 (UTC) Ran out of time and didn't get to this. Tabled for a later meeting.

Agenda for Jun 23

Agenda for Jul 14


Agenda for Jul 21


Agenda for Jul 28

Aug 18 Meeting Canceled

  • Most trove folks traveling for Trove Day + Midcycle event in Cambridge, MA

Agenda for Aug 25

  • [amrith]
    • What do we do about SUSE? There are bugs coming in at a steady clip fixing little things that don't work in SUSE but in some cases, no test cases are being proposed nor is there a clear plan to get SUSE on the supported platform list. How do we want to proceed? I raise this question because I don't want to use the review process as the place to discuss on a patch-by-patch basis whether a certain code change should be considered or not; rather raise it and address it as a larger issue of how we get to a supported SUSE platform including testing on an ongoing basis, etc.,

Sep 1 Meeting Canceled

  • Labor Day, so most folks are out

Agenda for Sep 8

Agenda for Sep 15

Agenda for Sep 22

Agenda for Oct 20


Agenda for Oct 22nd

Agenda for Oct 27

Agenda for Nov 3

Agenda for Nov 5

Meeting canceled

Agenda for Nov 12

Meeting canceled

Agenda for Nov 17

[grapex]

  • Example Snippet Generator - Tim Simpson

[Riddhi]

Agenda for Nov. 24

  • [flaper87, sgotliv, amrith] Switch Trove to use OSLO Messaging [5]
    • Since a spec in trove-specs is required for all projects related to blueprints that are intended for merge in Kilo, this spec has been submitted for review based on a document that was already in the old wiki format. A procedural approval similar to the ones granted to other specs [flavor id's and datastore versions] is requested for this.
  • [iccha, amrith] Allow users to retrieve guest log files [6]
  • [dougshelley66] Add instance name as parameter to various CLI commands [7]