[Openstack-operators] Reminder: UC Meeting Monday 1400UTC
Hey everyone, Please see https://wiki.openstack.org/wiki/Governance/ Foundation/UserCommittee for UC meeting info and add additional agenda items if needed. -- Kind regards, Melvin Hillsman mrhills...@gmail.com mobile: (832) 264-2646 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26
> Some ideas that have been discussed so far include: FYI, these are already in my order of preference. > A) Selecting a new, higher maximum that still yields reasonable > performance on a single compute host (64 or 128, for example). Pros: > helps prevent the potential for poor performance on a compute host > from attaching too many volumes. Cons: doesn't let anyone opt-in to a > higher maximum if their environment can handle it. I prefer this because I think it can be done per virt driver, for whatever actually makes sense there. If powervm can handle 500 volumes in a meaningful way on one instance, then that's cool. I think libvirt's limit should likely be 64ish. > B) Creating a config option to let operators choose how many volumes > allowed to attach to a single instance. Pros: lets operators opt-in to > a maximum that works in their environment. Cons: it's not discoverable > for those calling the API. This is a fine compromise, IMHO, as it lets operators tune it per compute node based on the virt driver and the hardware. If one compute is using nothing but iSCSI over a single 10g link, then they may need to clamp that down to something more sane. Like the per virt driver restriction above, it's not discoverable via the API, but if it varies based on compute node and other factors in a single deployment, then making it discoverable isn't going to be very easy anyway. > C) Create a configurable API limit for maximum number of volumes to > attach to a single instance that is either a quota or similar to a > quota. Pros: lets operators opt-in to a maximum that works in their > environment. Cons: it's yet another quota? Do we have any other quota limits that are per-instance like this would be? If not, then this would likely be weird, but if so, then this would also be an option, IMHO. However, it's too much work for what is really not a hugely important problem, IMHO, and both of the above are lighter-weight ways to solve this and move on. --Dan ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [TC] Stein Goal Selection
Matt Riedemann 於 2018年6月8日 週五 上午6:49寫道： > I haven't used it much, but it would be really nice if someone could > record a modern 'how to storyboard' video for just basic usage/flows > since most people are used to launchpad by now so dealing with an > entirely new task tracker is not trivial (or at least, not something I > want to spend a lot of time figuring out). > > I found: > > https://www.youtube.com/watch?v=b2vJ9G5pNb4 > > https://www.youtube.com/watch?v=n_PaKuN4Skk > > But those are a bit old. > I create an Etherpad to collect Q&A on Migrate from Launchpad to StoryBoard for Heat (most information were general). Hope this helps https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info > -- > > Thanks, > > Matt > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [TC] Stein Goal Selection
Kendall Nelson 於 2018年6月8日 週五 上午4:26寫道： > > I think that these two goals definitely fit the criteria we discussed in Vancouver during the S Release Goal Forum Session. I know Storyboard Migration was also mentioned after I had to dip out to another session so I wanted to follow up on that. > +1. To migrate to StoryBoard do seems like a good way to go. Heat just moved to StoryBoard, so there is no much long-term running experiences to share about, but it does look like a good way to target the piece which we been missing of. A workflow to connect users, ops, and developers (within Launchpad, we only care about bugs, and what generate that bug? well...we don't care). With Story + Task-oriented things can change (To me this is shiny). For migrate experience, the migration is quick, so if there is no project really really only can survive with Launchpad, I think there is no blocker for this goal. Also, it's quite convenient to target your story with your old bug, since your story id is your bug id. Since it might be difficult for all project directly migrated to it, IMO we should at least have a potential goal for T release (or a long-term goal for Stein?). Or we can directly set this as a Stein goal as well. Why? Because of the very first Story ID actually started from 200(and as I mentioned, after migrating, your story id is exactly your bug id ). So once we generate bug with ID 200, things will become interesting (and hard to migrate). Current is 1775759, so one or two years I guess? To interpreted `might be difficult` above, The overall experience is great, some small things should get improve: - I can't tell if current story is already reported or not. There is no way to filter stories and checking conflict if there is. - Things going slow if we try to use Board in StoryBoard to filter out a great number of stories (like when I need to see all `High Priority` tagged stories) - Needs better documentation, In Heat we create an Etherpad to describe and collect Q&A on how people can better adopt StoryBoard. It will be great if teams can directly get this information. Overall, I think this is a nice goal, and it's actually painless to migrate. -- May The Force of OpenStack Be With You, Rico Lin irc: ricolin ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
