Re: [openstack-dev] [tc] [all] TC Report 18
gs accumulate in a massive
> pile.)
>
> [^2]: <https://review.openstack.org/#/c/460946/>
>
> ## Change the target for this goal to uWSGI not Apache mod_wsgi[^3]
>
> General agreement about doing this change, not a big deal, but some
> concern about changing a cycle goal in the middle of the cycle
> ("moving the goal posts"). Agreement was that changing details of
> implementation are not the same thing as changing the goal
> (especially when it is a simplification) so it is okay as long as
> the change is reflected in the doc, not just the git history.
>
> [^3]: <https://review.openstack.org/#/c/460951/>
>
> ## More on maintenance-mode
>
> There's a newish tag called status:maintenance-mode which means that
> a project is receiving limited attention for a period of time.
> There's a proposal[^4] that the TC should become core on such a
> project to make sure there are people to handle urgent matters. The
> question is whether this is necessary since:
>
> * the TC can get those privileges at any time on any project when
> there is an urgent matter
> * being in maintenance-mode is supposed to mean there is sufficient
> attention from project team members for urgent matters, if not
> the project is abandoned
>
> This turned out more contentious and confused than expected and it
> too was punted to the review[^4].
>
> [^4]: <https://review.openstack.org/#/c/460963/>
>
> ## Open Discussion
>
> The above filled pretty much the whole hour, suggesting that perhaps
> we all have a lot more to say to one another than a single hour
> allows. That was acknowledged and suggestions were made that we
> really need to use email more and better, even though it can be
> challenging. That is, we need to level up our email skills.
>
> To help ensure more talking to one another and do a bit of near-term
> planning, a TC gathering will happen in Boston late next week.
> Evidently I will be spit-balling, and no one will be sitting near
> me.
>
> # Dropped Stuff
>
> _A section of reminders of things we said we'd talk about more but
> haven't yet._
>
> ## OpenStack moving too fast and too slow
>
> At last week's meeting, while discussing the findings from the user
> survey there was discussion[^t] of
>
>> the complicated problem of OpenStack moving both
>> too fast and too slow at the same time, depending on who was
>> looking. And the difficulty with lack of centralized control over
>> the technical direction of OpenStack and (probably most importantly)
>> the application of resources.
>
> that was supposed to move the mailing list[^m]. As far as I can see
> it did not. dfisher have you got the cycles to pick that up again
> here on the list? Or if not you, maybe mordred, fungi or dhellman?
> If it was already discussed, my apologies for losing it, can someone
> point it out to me?
>
> [^t]:
> <http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-177>
> [^m]:
> <http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-259>
>
> # Colophon
>
> This is an opinionated overview of Technical Committee activity from
> my perspective. As such it is subjective and potentially wrong
> enough to cause disagreements. That's a good thing if it leads to
> discussions that make things better or more correct.
>
>
>
> __
> 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
--
Best Regards,
Maish Saidel-Keesing
__
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
Re: [openstack-dev] [nova] Reflections on the pike-1 milestone
Perfect explanation and very clear - Thanks Matt!! On 20/04/17 21:18, Matt Riedemann wrote: > On 4/20/2017 2:01 AM, Maish Saidel-Keesing wrote: >> Just as a matter of interest - from the numbers above you say 62 >> blueprints approved - was this only for this cycle - or *up until* this >> cycle. >> >> When you mention several up for review - can you elaborate on exact >> numbers? >> >> I am not looking to 'monitor' activity - but for me it would be >> interesting to understand - what the workload is actually like. If the >> ratio of 'incoming work' (blueprints) vs. completed/in-review is 62:3 >> then to me - this seems to be something that needs to be addressed. >> >> Or am I misunderstanding the comment above? > > That means 62 blueprints approved for Pike (this cycle). This does not > mean the code is merged and the blueprint is completed. It means we > agreed on the design proposal and can move forward with code for the > blueprint. > > Several up for review means there are approved blueprints with code > ready for review (they have started, or are more than just a POC). > These numbers are probably low right now, but all blueprints targeted > for Pike [1] with Delivery status of "Needs Code Review" is what I'm > referring to here, which is currently 38. > > As for incoming work, and the ratio you point out, is not unusual in > the first milestone before we do our spec freeze, where we then stop > accepting new blueprint proposals for the release so we can focus on > implementing and reviewing what we've already planned to do. > > If you want a much more detailed explanation of the numbers and > trends, I provided that after the Ocata release [2]. > > [1] https://blueprints.launchpad.net/nova/pike > [2] > http://lists.openstack.org/pipermail/openstack-dev/2017-February/111639.html > -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [nova] Reflections on the pike-1 milestone
gress on > implementation by the end of the milestone. > - Get more of the versioned notifications work done. > - Now that the /traits API is available, we need to make progress on > adding support for modeling shared storage pools in Placement. > - Have a multi-cell CI job running which tests the conductor fleet > deployment model and API, including move (migrate) operations within a > cell. > - Continue adding support for the new Cinder attachment APIs. We > should have the code in place to create new-style attachments by the > end of pike-2, and testing it with the grenade upgrade CI job. This is > needed for supporting volume multi-attach. > - Get some of the PowerVM driver patches landed, at least through > spawn/destroy, but ideally to the point of supporting a console. > > Current focus: > > - We have the summit coming up in less than three weeks. People are > working on presentations and planning for the Forum sessions. > - With the recent loss of the OSIC developer resources, we're going to > need to evaluate which efforts were owned by the OSIC team and figure > out who can take over those blueprints. I'll be working on this and > sending something to the mailing list to ask for volunteers. > > Overall I think we made good progress in pike-1 and have the stage set > for big changes to land in pike-2 if we can stay focused. > > [1] > https://www.openstack.org/summit/boston-2017/summit-schedule/events/18727/cellsv2-operatordevelopercommunity-coordination > [2] https://docs.openstack.org/developer/nova/sample_policy.html > [3] > https://www.openstack.org/summit/boston-2017/summit-schedule/events/18738/using-cinder-for-nova-ephemeral-storage-backend > [4] https://review.openstack.org/#/c/438134/ > [5] > https://www.openstack.org/summit/boston-2017/summit-schedule/events/18739/using-searchlight-to-list-instances-across-cells-in-nova-api > [6] > https://www.openstack.org/summit/boston-2017/summit-schedule/events/18723/moving-resource-claims-from-nova-compute-to-nova-scheduler > -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?
Please see inline. On 17/01/17 9:36, Tim Bell wrote: > >> On 17 Jan 2017, at 01:19, Brandon B. Jozsa <bjo...@jinkit.com >> <mailto:bjo...@jinkit.com>> wrote: >> >> Inline >> >> On January 16, 2017 at 7:04:00 PM, Fox, Kevin M (kevin@pnnl.gov >> <mailto:kevin@pnnl.gov>) wrote: >> >>> >>> I'm not stating that the big tent should be abolished and we go back >>> to the way things were. But I also know the status quo is not >>> working either. How do we fix this? Anyone have any thoughts? >>> >> >> Are we really talking about Barbican or has the conversation drifted >> towards Big Tent concerns? >> >> Perhaps we can flip this thread on it’s head and more positively >> discuss what can be done to improve Barbican, or ways that we can >> collaboratively address any issues. I’m almost wondering if some >> opinions about Barbican are even coming from its heavy users, or >> users who’ve placed much time into developing/improving Barbican? If >> not, let’s collectively change that. >> > > When we started deploying Magnum, there was a pre-req for Barbican to > store the container engine secrets. We were not so enthusiastic since > there was no puppet configuration or RPM packaging. However, with a > few upstream contributions, these are now all resolved. > > the operator documentation has improved, HA deployment is working and > the unified openstack client support is now available in the latest > versions. Tim - where exactly is this documentation? > > These extra parts may not be a direct deliverable of the code > contributions itself but they make a major difference on deployability > which Barbican now satisfies. Big tent projects should aim to cover > these areas also if they wish to thrive in the community. > > Tim > >> >>> Thanks, >>> Kevin >> >> Brandon B. Jozsa >> -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all][elections] Results of the TC Election
I would also like to add my deepest gratitude for all your hard work that goes into this process every six months. Thank you, all of you for all the hard work that goes on behind the scenes to make this possible Congratulations to all the re-elected and newly elected members of the TC. -- Best Regards, Maish Saidel-Keesing On 10/10/16 02:49, Tony Breeds wrote: > Please join me in congratulating the 6 newly elected members of the TC. > > Doug Hellmann (dhellmann) > Emilien Macchi (emilienm) > Jeremy Stanley (fungi) > Monty Taylor (mordred) > Sean Dague (sdague) > Steve Martinelli (stevemar) > > > Full results: > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010 > > Thank you to all candidates who stood for election, having a good group of > candidates helps engage the community in our democratic process. > > Thank you to all who voted and who encouraged others to vote. We need to > ensure > your voice is heard. > > Thank you for another great round. > > Here's to Ocata! > > Yours Tony. > __ 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
Re: [openstack-dev] Seeking Mobile Beta Testers
Hi Jimmy Both Android and iOS Thanks! On 02/09/16 20:57, Jimmy McArthur wrote: > We're looking for a handful of community members to test our updated > OpenStack Summit mobile Apps. If you're interested, shoot me a note, > along with iOS/Android preference, and we'll get you set up. > > Thank you, > Jimmy McArthur > > > __ > > 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 -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [neutron]: Neutron naming legal issues
On 04/01/16 12:38, Ihar Hrachyshka wrote: > Alexander Kostrikov <akostri...@mirantis.com> wrote: > >> What about Netrone? > > That could be a good one but it may also be a violation: > http://www.infomoby.et/en/profile/netrone_networks_plc/64213 > > One idea I had in my mind for a while is using some alternative > alphabet for project naming. Ideally for some language that is not so > popular as English. In case of Neutron, a name like ‘Нетронь’ could be > a good fit and would even better reflect maturity the project achieved > throughout all those years, iykwim. I can almost guarantee that if you use Hebrew letters then it will be a safe bet. ניוטרון But on the other hand - no-one would know how to read/pronounce it :) > > Ihar > > __ > > 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 -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [magnum] High Availability
Forgive me for the top post and also for asking the obvious (with my Operator hat on) Relying on an external service for certificate store - is the best option - assuming of course that the certificate store is actually also highly available. Is that the case today with Barbican? According to the architecture docs [1] I see that they are using a relational database. MySQL? PostgreSQL? Does that now mean we have an additional database to maintain, backup, provide HA for as an Operator? The only real reference I can see to anything remotely HA is this [2] and this [3] An overall solution is highly available *only* if all of the parts it relies are also highly available as well. [1] http://docs.openstack.org/developer/barbican/contribute/architecture.html#overall-architecture [2] https://github.com/cloudkeep-ops/barbican-vagrant-zero [3] http://lists.openstack.org/pipermail/openstack/2014-March/006100.html Some food for thought -- Best Regards, Maish Saidel-Keesing On 03/18/16 17:18, Hongbin Lu wrote: > Douglas, > > I am not opposed to adopt Barbican in Magnum (In fact, we already adopted > Barbican). What I am opposed to is a Barbican lock-in, which already has a > negative impact on Magnum adoption based on our feedback. I also want to see > an increase of Barbican adoption in the future, and all our users have > Barbican installed in their clouds. If that happens, I have no problem to > have a hard dependency on Barbican. > > Best regards, > Hongbin > > -Original Message- > From: Douglas Mendizábal [mailto:douglas.mendiza...@rackspace.com] > Sent: March-18-16 9:45 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [magnum] High Availability > > Hongbin, > > I think Adrian makes some excellent points regarding the adoption of > Barbican. As the PTL for Barbican, it's frustrating to me to constantly hear > from other projects that securing their sensitive data is a requirement but > then turn around and say that deploying Barbican is a problem. > > I guess I'm having a hard time understanding the operator persona that is > willing to deploy new services with security features but unwilling to also > deploy the service that is meant to secure sensitive data across all of > OpenStack. > > I understand one barrier to entry for Barbican is the high cost of Hardware > Security Modules, which we recommend as the best option for the Storage and > Crypto backends for Barbican. But there are also other options for securing > Barbican using open source software like DogTag or SoftHSM. > > I also expect Barbican adoption to increase in the future, and I was hoping > that Magnum would help drive that adoption. There are also other projects > that are actively developing security features like Swift Encryption, and > DNSSEC support in Desginate. Eventually these features will also require > Barbican, so I agree with Adrian that we as a community should be encouraging > deployers to adopt the best security practices. > > Regarding the Keystone solution, I'd like to hear the Keystone team's > feadback on that. It definitely sounds to me like you're trying to put a > square peg in a round hole. > > - Doug > > On 3/17/16 8:45 PM, Hongbin Lu wrote: >> Thanks Adrian, >> >> >> >> I think the Keystone approach will work. For others, please speak up >> if it doesn't work for you. >> >> >> >> Best regards, >> >> Hongbin >> >> >> >> *From:*Adrian Otto [mailto:adrian.o...@rackspace.com] >> *Sent:* March-17-16 9:28 PM >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* Re: [openstack-dev] [magnum] High Availability >> >> >> >> Hongbin, >> >> >> >> I tweaked the blueprint in accordance with this approach, and approved >> it for Newton: >> >> https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-sto >> re >> >> >> >> I think this is something we can all agree on as a middle ground, If >> not, I'm open to revisiting the discussion. >> >> >> >> Thanks, >> >> >> >> Adrian >> >> >> >> On Mar 17, 2016, at 6:13 PM, Adrian Otto <adrian.o...@rackspace.com >> <mailto:adrian.o...@rackspace.com>> wrote: >> >> >> >> Hongbin, >> >> One alternative we could discuss as an option for operators that >> have a good reason not to use Barbican, is to use Keystone. >> >> Keystone credentials store: >> >> http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-
Re: [openstack-dev] [all] A proposal to separate the design summit
On 02/22/16 17:31, Monty Taylor wrote: > On 02/22/2016 07:24 AM, Russell Bryant wrote: >> >> >> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez <thie...@openstack.org >> <mailto:thie...@openstack.org>> wrote: >> >> Hi everyone, >> >> TL;DR: Let's split the events, starting after Barcelona. >> >> >> This proposal sounds fantastic. Thank you very much to those that help >> put it together. > > Totally agree. I think it's an excellent way to address the concerns > and balance all of the diverse needs we have. > > Thank you very much! > > I think that this is great and well thought out proposal. Thanks! -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] Encouraging first-time contributors through bug tags/reviews
This is an awesome idea!!! On 11/25/15 16:15, Shamail Tahir wrote: Hi everyone, Andrew Mitry recently shared a medium post[1] by Kent C. Dobbs which discusses how one open-source project is encouraging contributions by new open-source contributors through a combination of a special tag (which is associated with work that is needed but can only be completed by someone who is a first-time contributor) and helpful comments in the review phase to ensure the contribution(s) eventually get merged. While reading the article, I immediately thought about our low-hanging-fruit bug tag which is used for a very similar purpose in "bug fixing" section of the "how to contribute" page[2]. The low-hanging-fruit tag is used to identify items that are generally suitable for first-time or beginner contributors but, in reality, anyone can pick them up. I wanted to propose a new tag (or even changing the, existing, low-hanging fruit tag) that would identify items that we are reserving for first-time OpenStack contributors (e.g. a patch-set for the item submitted by someone who is not a first time contributor would be rejected)... The same article that Andrew shared mentions using an "up-for-grabs" tag which also populates the items at up-for-grabs[3] (a site where people looking to start working on open-source projects see entry-level items from multiple projects). If we move forward with an exclusive tag for first-timers then it would be nice if we could use the up-for-grabs tag so that OpenStack also shows up on the list too. Please let me know if this change should be proposed elsewhere, the tags are maintained in launchpad and the wiki I found related to bug tags[4] didn't indicate a procedure for submitting a change proposal. Tyler Britten also suggested maybe even having a pool of reviewers who could monitor items being worked on that fall in this "first-timer" category who could further help the new contributors by helpful review comments and answering questions if the contributors get stuck on some part of the process. Could this be the same people who helped make the upstream training[5] successful? I look forward to thoughts on this matter. [1] https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.707dal290 [2] https://wiki.openstack.org/wiki/How_To_Contribute#Bug_fixing <https://wiki.openstack.org/wiki/How_To_Contribute#Bug_fixing> [3] http://up-for-grabs.net/ [4] https://wiki.openstack.org/wiki/Bug_Tags [5] http://docs.openstack.org/upstream-training/ -- Thanks, Shamail Tahir t: @ShamailXD tz: Eastern Time __ 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 -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit
On 11/05/15 23:18, Fox, Kevin M wrote: Your assuming there are only 2 choices, zk or db+rabbit. I'm claiming both hare suboptimal at present. a 3rd might be needed. Though even with its flaws, the db+rabbit choice has a few benefits too. You also seem to assert that to support large clouds, the default must be something that can scale that large. While that would be nice, I don't think its a requirement if its overly burdensome on deployers of non huge clouds. I don't have metrics, but I would be surprised if most deployments today (production + other) used 3 controllers with a full ha setup. I would guess that the majority are single controller setups. With those, the I think it would be safe to assume - that any kind of production cloud - or any operator that considers their OpenStack environment something that is close to production ready - would not be daft enough to deploy their whole environment based on a single controller - which is a whopper of a single point of failure. Most Fuel (mirantis) deployments are multiple controllers. RHOS also recommends doing multiple controllers. I don't think that we as a community can afford to assume that 1 controller will suffice. This does not say that maintaining zk will be any easier though. overhead of maintaining a whole dlm like zk seems like overkill. If db+rabbit would work for that one case, that would be one less thing to have to setup for an op. They already have to setup db+rabbit. Or even a clm plugin of some sort, that won't scale, but would be very easy to deploy, and change out later when needed would be very useful. etcd is starting to show up in a lot of other projects, and so it may be at sites already. being able to support it may be less of a burden to operators then zk in some cases. If your cloud grows to the point where the dlm choice really matters for scalability/correctness, then you probably have enough staff members to deal with adding in zk, and that's probably the right choice. You can have multiple suggested things in addition to one default. Default to the thing that makes the most sense in the common most deployments, and make specific recommendations for certain scenarios. like, "if greater then 100 nodes, we strongly recommend using zk" or something to that effect. Thanks, Kevin From: Clint Byrum [cl...@fewbar.com] Sent: Thursday, November 05, 2015 11:44 AM To: openstack-dev Subject: Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit Excerpts from Fox, Kevin M's message of 2015-11-04 14:32:42 -0800: To clarify that statement a little more, Speaking only for myself as an op, I don't want to support yet one more snowflake in a sea of snowflakes, that works differently then all the rest, without a very good reason. Java has its own set of issues associated with the JVM. Care, and feeding sorts of things. If we are to invest time/money/people in learning how to properly maintain it, its easier to justify if its not just a one off for just DLM, So I wouldn't go so far as to say we're vehemently opposed to java, just that DLM on its own is probably not a strong enough feature all on its own to justify requiring pulling in java. Its been only a very recent thing that you could convince folks that DLM was needed at all. So either make java optional, or find some other use cases that needs java badly enough that you can make java a required component. I suspect some day searchlight might be compelling enough for that, but not today. As for the default, the default should be good reference. if most sites would run with etc or something else since java isn't needed, then don't default zookeeper on. There are a number of reasons, but the most important are: * Resilience in the face of failures - The current database+MQ based solutions are all custom made and have unknown characteristics when there are network partitions and node failures. * Scalability - The current database+MQ solutions rely on polling the database and/or sending lots of heartbeat messages or even using the database to store heartbeat transactions. This scales fine for tiny clusters, but when every new node adds more churn to the MQ and database, this will (and has been observed to) be intractable. * Tech debt - OpenStack is inventing lock solutions and then maintaining them. And service discovery solutions, and then maintaining them. Wouldn't you rather have better upgrade stories, more stability, more scale, and more featuers? If those aren't compelling enough reasons to deploy a mature java service like Zookeeper, I don't know what would be. But I do think using the abstraction layer of tooz will at least allow us to move forward without having to convince everybody everywhere that this is actually just the path of least resistance. -- Best Regards, Maish Said
Re: [openstack-dev] Scheduler proposal
Forgive the top-post. Cross-posting to openstack-operators for their feedback as well. Ed the work seems very promising, and I am interested to see how this evolves. With my operator hat on I have one piece of feedback. By adding in a new Database solution (Cassandra) we are now up to three different database solutions in use in OpenStack MySQL (practically everything) MongoDB (Ceilometer) Cassandra. Not to mention two different message queues Kafka (Monasca) RabbitMQ (everything else) Operational overhead has a cost - maintaining 3 different database tools, backing them up, providing HA, etc. has operational cost. This is not to say that this cannot be overseen, but it should be taken into consideration. And *if* they can be consolidated into an agreed solution across the whole of OpenStack - that would be highly beneficial (IMHO). -- Best Regards, Maish Saidel-Keesing On 10/08/15 03:24, Ed Leafe wrote: On Oct 7, 2015, at 2:28 PM, Zane Bitter <zbit...@redhat.com> wrote: It seems to me (disclaimer: not a Nova dev) that which database to use is completely irrelevant to your proposal, Well, not entirely. The difference is that what Cassandra offers that separates it from other DBs is exactly the feature that we need. The solution to the scheduler isn't to simply "use a database". which is really about moving the scheduling from a distributed collection of Python processes with ad-hoc (or sometimes completely missing) synchronisation into the database to take advantage of its well-defined semantics. But you've framed it in such a way as to guarantee that this never gets discussed, because everyone will be too busy arguing about whether or not Cassandra is better than Galera. Understood - all one has to do is review the original thread from back in July to see this happening. But the reason that I framed it then as an experiment in which we would come up with measures of success we could all agree on up-front was so that if someone else thought that Product Foo would be even better, we could set up a similar test bed and try it out. IOW, instead of bikeshedding, if you want a different color, you build another shed and we can all have a look. -- Ed Leafe __ 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
[openstack-dev] [Election] [TC] TC Candidacy
Hello to you all. I would like to propose myself as a candidate for the Technical Committee for the upcoming term. The reasons for running in the last election [1] are still relevant for this election of the TC. Since the last election my involvement in OpenStack has increased with a spotlight on the Operators aspect of the community: - Focusing on the ops-tags-team[2] helping to create tags with the intent of creating information relevant to Operators. - Helping to vet and review submissions to the OpenStack Planet[3] and contributing as a core in openstack-planet-core. - Participating in the Item Writing Committee of the first Foundation initiative for the inaugural OpenStack Certification Exam Program. As an OpenStack community we have made some huge steps in the right direction, and are bringing more and more of the Operator and User community into our midst. Operators and Users should also be represented in the Technical Committee. It is my hope that the electorate accept that there is a huge benefit, and also a clear need, to have representation from all aspects of OpenStack, not only from the developer community. When this happens - the disconnect (and sometimes tension) that we have between these different parts will cease to be an issue and we as a community will continue to thrive and grow. In order to finally bridge this gap, it is time to open the ranks, bring an Operator into the TC and to become truly inclusive. I humbly ask for your selection so that I may represent Operators in the Technical Committee for the next term. Thank you for your consideration. Some more information about me: OpenStack profile: https://www.openstack.org/community/members/profile/15265 Reviews: https://review.openstack.org/#/q/reviewer:%22Maish+Saidel-Keesing%22,n,z IRC: maishsk Blog: http://technodrone.blogspot.com [1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/062372.html [2] https://review.openstack.org/#/q/status:open+project:stackforge/ops-tags-team,n,z [3] https://wiki.openstack.org/wiki/AddingYourBlog -- Best Regards, Maish Saidel-Keesing __ 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
[openstack-dev] [glance] [nova] Verification of glance images before boot
How can I know that the image that a new instance is spawned from - is actually the image that was originally registered in glance - and has not been maliciously tampered with in some way? Is there some kind of verification that is performed against the md5sum of the registered image in glance before a new instance is spawned? Is that done by Nova? Glance? Both? Neither? The reason I ask is some 'paranoid' security (that is their job I suppose) people have raised these questions. I know there is a glance BP already merged for L [1] - but I would like to understand the actual flow in a bit more detail. Thanks. [1] https://blueprints.launchpad.net/glance/+spec/image-signing-and-verification-support -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [Neutron] Allowing DNS suffix to be set per subnet (at least per tenant)
On 09/03/15 20:51, Gal Sagie wrote:
I am not sure if this address what you need specifically, but it would
be worth checking these
two approved liberty specs:
1)
https://github.com/openstack/neutron-specs/blob/master/specs/liberty/internal-dns-resolution.rst
2)
https://github.com/openstack/neutron-specs/blob/master/specs/liberty/external-dns-resolution.rst
Thanks Gal,
So I see that from the bp [1] the fqdn will be configurable for each and
every port ?
I think that this does open up a number of interesting possibilities,
but I would also think that it would be sufficient to do this on a
subnet level?
We do already have the option of setting nameservers per subnet - I
assume the data model is already implemented - which is interesting -
because I don't see that as part of the information that is sent by
dnsmasq so it must be coming from neutron somewhere.
The domain suffix - definitely is handled by dnsmasq.
On Thu, Sep 3, 2015 at 8:37 PM, Steve Wormley <openst...@wormley.com
<mailto:openst...@wormley.com>> wrote:
As far as I am aware it is not presently built-in to Openstack.
You'll need to add a dnsmasq_config_file option to your dhcp agent
configurations and then populate the file with:
domain=DOMAIN_NAME,CIDR for each network
i.e.
domain=example.com <http://example.com>,10.11.22.0/24
<http://10.11.22.0/24>
...
-Steve
On Thu, Sep 3, 2015 at 1:04 AM, Maish Saidel-Keesing
<mais...@maishsk.com <mailto:mais...@maishsk.com>> wrote:
Hello all (cross-posting to openstack-operators as well)
Today the setting of the dns suffix that is provided to the
instance is passed through dhcp_agent.
There is the option of setting different DNS servers per
subnet (and and therefore tenant) but the domain suffix is
something that stays the same throughout the whole system is
the domain suffix.
I see that this is not a current neutron feature.
Is this on the roadmap? Are there ways to achieve this today?
If so I would be very interested in hearing how.
Thanks
--
Best Regards,
Maish Saidel-Keesing
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Best Regards ,
The G.
--
Best Regards,
Maish Saidel-Keesing
__
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
[openstack-dev] [Neutron] Allowing DNS suffix to be set per subnet (at least per tenant)
Hello all (cross-posting to openstack-operators as well) Today the setting of the dns suffix that is provided to the instance is passed through dhcp_agent. There is the option of setting different DNS servers per subnet (and and therefore tenant) but the domain suffix is something that stays the same throughout the whole system is the domain suffix. I see that this is not a current neutron feature. Is this on the roadmap? Are there ways to achieve this today? If so I would be very interested in hearing how. Thanks -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [Neutron] Allowing DNS suffix to be set per subnet (at least per tenant)
On 09/03/15 20:37, Steve Wormley wrote: As far as I am aware it is not presently built-in to Openstack. You'll need to add a dnsmasq_config_file option to your dhcp agent configurations and then populate the file with: domain=DOMAIN_NAME,CIDR for each network i.e. domain=example.com <http://example.com>,10.11.22.0/24 <http://10.11.22.0/24> ... -Steve Thanks Steve, I am aware of that 'hack' which has a substantial number of downsides. The biggest one being that it per subnet - and I afraid to find out what would happen if more than one tenant configures the same subnet - this could cause all sorts of problems. And all of this has to be done with appropriate shell permissions to the neutron node. In other words, it could work, but only for a very certain use case. On Thu, Sep 3, 2015 at 1:04 AM, Maish Saidel-Keesing <mais...@maishsk.com <mailto:mais...@maishsk.com>> wrote: Hello all (cross-posting to openstack-operators as well) Today the setting of the dns suffix that is provided to the instance is passed through dhcp_agent. There is the option of setting different DNS servers per subnet (and and therefore tenant) but the domain suffix is something that stays the same throughout the whole system is the domain suffix. I see that this is not a current neutron feature. Is this on the roadmap? Are there ways to achieve this today? If so I would be very interested in hearing how. Thanks -- Best Regards, Maish Saidel-Keesing -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] PTL/TC candidate workflow proposal for next elections
+1 To what Joshua said. I would also like to understand what is the goal we are trying to accomplish by moving this to a repo and submitting a CR and what does this solve or improve on the current way we are doing things? Will it reduce noise? marginally (IMHO). Maish On 08/22/15 06:02, Joshua Hesketh wrote: I'm struggling to think of a way this might help enable discussions between nominees and voters about their platforms. Since the tooling will send out the nomination announcements the only real noise that is reduced is the nomination confirmed type emails. While I think this sounds really neat, I'm not convinced that it'll actually reduce noise on the mailing list if that was the goal. I realise the primary goal is to help the election officials, but perhaps we can achieve both of these by a separate mailing list for both nomination announcements and also platform discussions? This could be a first step and then once we have the tooling to confirm a nominees validity we could automate that first announcement email still. Just a thought anyway. Cheers, Josh On Sat, Aug 22, 2015 at 5:44 AM, Anita Kuno ante...@anteaya.info mailto:ante...@anteaya.info wrote: On 08/21/2015 03:37 PM, Jeremy Stanley wrote: On 2015-08-21 14:32:50 -0400 (-0400), Anita Kuno wrote: Personally I would recommend that the election officials have verification permissions on the proposed repo and the automation step is skipped to begin with as a way of expediting the repo creation. Getting the workflow in place in enough time that potential candidates can familiarize themselves with the change, is of primary importance I feel. Automation can happen after the workflow is in place. Agreed, I'm just curious what our options actually are for automating the confirmation research currently performed. It's certainly not a prerequisite for using the new repo/workflow in a manually-driven capacity in the meantime. Fair enough. I don't want to answer the question myself as I feel it's best for the response to come from current election officials. Thanks Jeremy, Anita. __ 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
[openstack-dev] [Heat] creating a stack with a config_drive
I have been looking for a working example to create Heat stack with a config_drive attached. I know it is possible to deploy a nova instance with the CLI [1] I see that OS::Nova::Server has a config_drive property that is a Boolean value [2] What I cannot find is how this can be used. Where is the path defined for the config file? Or am I completely missing what and how this should be used? Anyone with more info on this - I would be highly grateful. Thanks. [1] http://docs.openstack.org/user-guide/cli_config_drive.html [2] http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [Heat] creating a stack with a config_drive
On 08/07/15 16:22, Randall Burt wrote: config_drive: true just tells the instance to mount the drive. You pass data via the user_data property. Thanks Randall that is what I was thinking. But I am confused. When booting an instance with nova boot, I can configure a local file/directory to be mounted as a config drive on the instance upon boot. I can also provide information and commands regularly through the user_data Through Heat I can provide configuration through user_data. And I can also mount a config_drive. Where do I define what that config_drive contains? Original message From: Maish Saidel-Keesing Date:08/07/2015 8:08 AM (GMT-06:00) To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Heat] creating a stack with a config_drive I have been looking for a working example to create Heat stack with a config_drive attached. I know it is possible to deploy a nova instance with the CLI [1] I see that OS::Nova::Server has a config_drive property that is a Boolean value [2] What I cannot find is how this can be used. Where is the path defined for the config file? Or am I completely missing what and how this should be used? Anyone with more info on this - I would be highly grateful. Thanks. [1] http://docs.openstack.org/user-guide/cli_config_drive.html [2] http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server -- Best Regards, Maish Saidel-Keesing __ 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 -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [nova] Proposal for an Experiment
also asking that you refrain from talking about why this can't work for now. I know it'll be difficult to do that, since nobody likes ranting about stuff more than I do, but right now it won't be helpful. There will be plenty of time for that later, assuming that this experiment yields anything worthwhile. Instead, think of the current pain points in the scheduler design, and what sort of improvement you would have to see in order to seriously consider undertaking this change to Nova. I've gotten the OK from my management to pursue this, and several people in the community have expressed support for both the approach and the experiment, even though most don't have spare cycles to contribute. I'd love to have anyone who is interested become involved. I hope that this will be a positive discussion at the Nova mid-cycle next week. I know it will be a lively one. :) [1] http://cassandra.apache.org/ [2] http://www.datastax.com/ __ 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 -- Best Regards, Maish Saidel-Keesing __ 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
[openstack-dev] [tags] ops:ha tag request for feedback
I would appreciate if you could all leave your comments and thoughts on the following patch [1]. Please be advised this is an initial version and your feedback is very much appreciated. [1] https://review.openstack.org/#/c/200128/1 -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [nova][ceilometer] proposal to send bulk hypervisor stats data in periodic notifications
On 06/22/15 20:10, Daniel P. Berrange wrote: On Mon, Jun 22, 2015 at 11:10:40AM -0500, Kevin L. Mitchell wrote: On Sat, 2015-06-20 at 21:35 +0100, Daniel P. Berrange wrote: In general I would say that is an unsupported deployment scenario to have other random virt guests running on a nova compute node. On the other hand, this is exactly how compute nodes themselves are often deployed—a random guest on the hypervisor node… In a devstack env maybe, but in production we expect the hypervisor to be exclusively used by Nova, or things Nova uses. Regards, Daniel +1 to that!! I think it would be safe to say that in any production environment I would run, Nova would control the instances exclusively. -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [Openstack-operators] [ops][tags][packaging] [tc] ops:packaging tag - a little common sense, please
. But please don't call these things tags, because they aren't. Before I move on to other issues, I'd like to point out that the more you go down the route of adding more and more attributes, most of which would be optional, to these structured documents, the more you will run into a problem of having stale and misleading data contained in these JSON files. And that will lead to a worse user experience for operators than the current wiki, which, like all wikis, is notoriously out-of-date in many places. A tag should mean one thing, and one thing only, to encourage clarity. The definition of the tag should be decisive regarding why a particular project has been tagged with that tag. = Operators should not be curating packaging tags = *Packagers* should be curating tags that correspond to whether or not packages exist for particular projects in OpenStack. Operators consume these packages, for sure, but the packagers in the upstream operating system communities are the ones that know the most accurate information about the state of packaging for a particular project and a particular release. I strongly believe that these ops:packaged tags should really just be tags in the openstack/governance repository (i.e. regular TC tags) and be curated by the packaging community, which means they would not have the ops: prefix on them. = Remove value component from the tag = The current proposal for both ops:packaged and ops:production-use [3] tag definitions include a value component. For example, the ops:packaged tags must include one of the following values: - good - beginning - warning - no With each of the above values attempting to indicate to the audience that the packages for a particular project are in varying states of repair and bug-freeness. There are a number of problems with including this value in the tag: 1) This value judgement about the packaging quality is ripe for getting out-of-date VERY quickly. Who is going to continually update the value parts for the different projects? Things change very quickly in packaging-land. Bugs are fixed, new packages built and published. Who in the ops community is going to track this? Please see point above about Operators should not be curating packaging tags. 2) All software, including packages, has bugs. This is something that the Ops community just needs to accept and get over. Quabbling with each other about what constitutes a major bug in packaging and how many major bugs bugs constitute a warning value is less than useful to the audience here. Instead, the ops community should focus on providing useful documentation and links to the audience, in the form of long-form release notes or opinions about packages and documentation on the OpenStack wiki. = Packaging tags should be release-specific, or they will be wrong = For these packaging tags, the release must be part of the tag itself, otherwise the information it denotes would be indeterminate. As an example, suppose you have a tag that looks like this: ops:packaged:centos:good And in the tag definition you say that the tag is applied to projects that have CentOS RPM packages available within the last 6 months. Well, as you all know, packages are published for a *particular release of OpenStack*. So, if Nova is tagged with ops:packaged:centos:good in, say, August 2015, the tag would ostensibly be saying that packages exist for Nova in Kilo. However, once November rolls around, and packages for Liberty don't (yet) exist, are you going to remove this ops:packaged:centos:good tag from Nova or (worse) change it to ops:pacakged:centos:no? Instead, have the tag be specific to a release of OpenStack: packaged:centos:kilo = In summary = In short, I would love it if the Ops Tags team would stick with binary tag definitions -- a tag should mean one thing and one thing only. I don't believe the Ops Tags team should be curating the packaging tags -- the packaging community should do that, and do that under the main openstack/governance repository. Packagers, I would love it if you would curate a set of tags that looks kind of like this: - packaged:centos:kilo - packaged:ubuntu:liberty - packaged:sles:juno I will be proposing the above tag definition to the openstack/governance repository this week. Thanks for listening, -jay [1] http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2015-06-09.log.html#t2015-06-09T20:18:00 [2] https://review.openstack.org/#/c/186633 [3] https://review.openstack.org/#/c/189168 -- Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] [stable] No longer doing stable point releases
On 06/01/15 03:20, Steve Gordon wrote: - Original Message - From: Maish Saidel-Keesing mais...@maishsk.com To: openstack-dev@lists.openstack.org On 05/29/15 18:25, Matthew Thode wrote: On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote: What about release notes? How can we now communicate some changes that require operator consideration or action? Ihar On 05/29/2015 03:41 PM, Thierry Carrez wrote: Hi everyone, TL;DR: - We propose to stop tagging coordinated point releases (like 2015.1.1) - We continue maintaining stable branches as a trusted source of stable updates for all projects though Long version: At the stable branch session in Vancouver we discussed recent evolutions in the stable team processes and how to further adapt the work of the team in a big tent world. One of the key questions there was whether we should continue doing stable point releases. Those were basically tags with the same version number (2015.1.1) that we would periodically push to the stable branches for all projects. Those create three problems. (1) Projects do not all follow the same versioning, so some projects (like Swift) were not part of the stable point releases. More and more projects are considering issuing intermediary releases (like Swift does), like Ironic. That would result in a variety of version numbers, and ultimately less and less projects being able to have a common 2015.1.1-like version. (2) Producing those costs a non-trivial amount of effort on a very small team of volunteers, especially with projects caring about stable branches in various amounts. We were constantly missing the pre-announced dates on those ones. Looks like that effort could be better spent improving the stable branches themselves and keeping them working. (3) The resulting stable point releases are mostly useless. Stable branches are supposed to be always usable, and the released version did not undergo significantly more testing. Issuing them actually discourages people from taking whatever point in stable branches makes the most sense for them, testing and deploying that. The suggestion we made during that session (and which was approved by the session participants) is therefore to just get rid of the stable point release concept altogether for non-libraries. That said: - we'd still do individual point releases for libraries (for critical bugs and security issues), so that you can still depend on a specific version there - we'd still very much maintain stable branches (and actually focus our efforts on that work) to ensure they are a continuous source of safe upgrades for users of a given series Now we realize that the cross-section of our community which was present in that session might not fully represent the consumers of those artifacts, which is why we expand the discussion on this mailing-list (and soon on the operators ML). If you were a consumer of those and will miss them, please explain why. In particular, please let us know how consuming that version (which was only made available every n months) is significantly better than picking your preferred time and get all the current stable branch HEADs at that time. Thanks in advance for your feedback, [1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch __ 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 for release notes just do git log between commit hashes? Do you really think that is what an Operator will do? I do not think is a realistic expectation or something that will work. -- Best Regards, Maish Saidel-Keesing While I agree most operators probably don't want to necessarily dig this out of git themselves and it would need to be collated/exposed in a nicer way it seems like it would actually be more accurate than the current release notes for all the non-security bug fixes in stable which basically amount to a list of launchpad bug queries per project. You then have to sift through each bug to work out if the description reflects what was actually done etc: https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.3 -Steve I agree - and if this could be automated in some way to make is presentable - that would be ideal -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] [stable] No longer doing stable point releases
On 05/29/15 18:25, Matthew Thode wrote: On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote: What about release notes? How can we now communicate some changes that require operator consideration or action? Ihar On 05/29/2015 03:41 PM, Thierry Carrez wrote: Hi everyone, TL;DR: - We propose to stop tagging coordinated point releases (like 2015.1.1) - We continue maintaining stable branches as a trusted source of stable updates for all projects though Long version: At the stable branch session in Vancouver we discussed recent evolutions in the stable team processes and how to further adapt the work of the team in a big tent world. One of the key questions there was whether we should continue doing stable point releases. Those were basically tags with the same version number (2015.1.1) that we would periodically push to the stable branches for all projects. Those create three problems. (1) Projects do not all follow the same versioning, so some projects (like Swift) were not part of the stable point releases. More and more projects are considering issuing intermediary releases (like Swift does), like Ironic. That would result in a variety of version numbers, and ultimately less and less projects being able to have a common 2015.1.1-like version. (2) Producing those costs a non-trivial amount of effort on a very small team of volunteers, especially with projects caring about stable branches in various amounts. We were constantly missing the pre-announced dates on those ones. Looks like that effort could be better spent improving the stable branches themselves and keeping them working. (3) The resulting stable point releases are mostly useless. Stable branches are supposed to be always usable, and the released version did not undergo significantly more testing. Issuing them actually discourages people from taking whatever point in stable branches makes the most sense for them, testing and deploying that. The suggestion we made during that session (and which was approved by the session participants) is therefore to just get rid of the stable point release concept altogether for non-libraries. That said: - we'd still do individual point releases for libraries (for critical bugs and security issues), so that you can still depend on a specific version there - we'd still very much maintain stable branches (and actually focus our efforts on that work) to ensure they are a continuous source of safe upgrades for users of a given series Now we realize that the cross-section of our community which was present in that session might not fully represent the consumers of those artifacts, which is why we expand the discussion on this mailing-list (and soon on the operators ML). If you were a consumer of those and will miss them, please explain why. In particular, please let us know how consuming that version (which was only made available every n months) is significantly better than picking your preferred time and get all the current stable branch HEADs at that time. Thanks in advance for your feedback, [1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch __ 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 for release notes just do git log between commit hashes? Do you really think that is what an Operator will do? I do not think is a realistic expectation or something that will work. -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions
Thanks Brandon On 05/20/15 22:58, Brandon Logan wrote: Just to add a few things, Barbican is not yet implemented in Octavia, though the code is there, we just need to spend a few hours hooking it all up and testing it out. Also, the security groups are used by octavia right now so that only the ports on the listener are accessible. Basically if a loadbalancer has listeners on ports 80 and 443, the vip ports will only allow traffic on those ports. It shouldn't allow other traffic. That is great to hear. I assume that if we are using security groups we will also be able to define rules regarding which networks the listeners are allowed to accept traffic from? Is that assumption correct? Thanks, Brandon *From:* Doug Wiegley doug...@parksidesoftware.com *Sent:* Thursday, May 21, 2015 12:49 AM *To:* maishsk+openst...@maishsk.com; OpenStack Development Mailing List (not for usage questions); Maish Saidel-Keesing *Subject:* Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions Hi Maish, Thanks for the feedback, some answers below. Please also be aware of the lbaas use cases session tomorrow at 9am (yuck, I know), https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing mais...@maishsk.com mailto:mais...@maishsk.com wrote: Hello all, Going over today's presentation Load Balancing as a Service, Kilo and Beyond[1] (great presentation!!) - there are a few questions I have regarding the future release: For Octavia 1.0: 1. Can someone explain to me how the flow would work for spinning up a a new Amphora with regards to interaction between Neutron, LBaaS and Barbican? Same question as well regarding how the standby is created and its relationship with Barbican. The lbaas API runs inside neutron-server. The general flow is: - User interacts with neutron CLI/API or horizon (in liberty), and creates an LB. - Lbaas plugin in neutron creates logical models, fetches cert data from barbican, and calls the backend lbaas driver. - The backend driver does what it needs to to instantiate the LB. Today this is a synchronous call that waits for the nova boot, but by Liberty, it will likely be an async call to the octavia controller to finish the job. Once Octavia has control, it is doing: - Get REST calls for objects, - Talk to nova, spin up an amphora image, - Talk to neutron, plumb in the networks, - Send the amphora its config. 2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is released or only further down the line? If not what would you suggest be the way to orchestrate LBaaS until this is ready? We need to talk to the Heat folks and coordinate this, which we are planning to do soon. 3. Is there some kind of hook into Security groups also planned for the Amphora to also protect the Load Balancer? Not at present, but I recorded this in the feature list on the etherpad above. I think that based on the answers to these questions above - additional questions will follow. Thanks [1] https://www.youtube.com/watch?v=-eAKur8lErU -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions
Thanks Doug! PSB my comments within. On 05/20/15 22:49, Doug Wiegley wrote: Hi Maish, Thanks for the feedback, some answers below. Please also be aware of the lbaas use cases session tomorrow at 9am (yuck, I know), https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases Sorry but I will not be able to attend - I will be on a plane. I will look monitor the etherpad and pass my comments on. On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing mais...@maishsk.com mailto:mais...@maishsk.com wrote: Hello all, Going over today's presentation Load Balancing as a Service, Kilo and Beyond[1] (great presentation!!) - there are a few questions I have regarding the future release: For Octavia 1.0: 1. Can someone explain to me how the flow would work for spinning up a new Amphora with regards to interaction between Neutron, LBaaS and Barbican? Same question as well regarding how the standby is created and its relationship with Barbican. The lbaas API runs inside neutron-server. The general flow is: - User interacts with neutron CLI/API or horizon (in liberty), and creates an LB. - Lbaas plugin in neutron creates logical models, fetches cert data from barbican, and calls the backend lbaas driver. From this I gather that there is a dependency on Barbican. From what I found - this thread looks like the HA modelling for barbican [1]. Seems to me to be quite solid. There was one detail that aroused my attention. Barbican is using PostgreSQL as the backend database [2]. Is there any specific reason why PostgreSQL and not MySQL like the rest of OpenStack? Is there any tehnical limitation that specifically requires PostgreSQL? *From an operators perspective inducing a new database technology (yet again) this will is not ideal to say the least.* - The backend driver does what it needs to to instantiate the LB. Today this is a synchronous call that waits for the nova boot, but by Liberty, it will likely be an async call to the octavia controller to finish the job. Once Octavia has control, it is doing: - Get REST calls for objects, - Talk to nova, spin up an amphora image, - Talk to neutron, plumb in the networks, - Send the amphora its config. 2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is released or only further down the line? If not what would you suggest be the way to orchestrate LBaaS until this is ready? We need to talk to the Heat folks and coordinate this, which we are planning to do soon. Great! It would be ideal that this is available from Day 1, otherwise there will be no real to utilize this in production use cases. 3. Is there some kind of hook into Security groups also planned for the Amphora to also protect the Load Balancer? Not at present, but I recorded this in the feature list on the etherpad above. Much obliged - this is a basic security requirement that should be in place to protect/shield the load balancers from unwanted traffic. [1] http://lists.openstack.org/pipermail/openstack/2014-March/006102.html [2] https://github.com/cloudkeep/barbican/wiki/Architecture -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] rating talks (and keynotes) at the OpenStack summit
On 05/20/15 11:42, Steve Gordon wrote: - Original Message - From: Amrith Kumar amr...@tesora.com To: openst...@lists.openstack.org, OpenStack Development Mailing List (not for usage questions) I attended a talk by Mark Baker today (http://sched.co/2qbJ) entitled The OpenStack Summit Talk Selection Process is Broken and I think it was an informative session. The statistics presented indicated that just under a third of the talks submitted got accepted at this summit and that is a very healthy ratio and that's a great thing. One thing that was brought up at the talk was that there was no formal feedback mechanism about talks and keynotes at Summit. Is there any way in which we can get a feedback mechanism for the talks and sessions at this summit up and running? It would be a valuable piece of information if we could get it. Any thoughts on how this can be done? There were 296 sessions; we obviously know the names of the sessions and the speakers. Does our scheduling mechanism have a 'ratings module' that can be turned on? Is there some other quick and dirty mechanism we can use? For Red Hat Summit we have something like this built into the official app and speakers are encouraged to remind people to use it to submit feedback at the end. Users have the choice of just leaving a rating in a couple of categories or also entering written comments. I have found the feedback quite useful in the past for helping me to better target the presentations I do at that particular event and think it would be great if there was something like this for OpenStack summit. Thanks, Steve I would highly recommend that we start accepting the input from the participants with regards to their experience - during the sessions, Keynote speakers, food, venue everything. This feedback can be used by the foundation to evaluate what was amazing, what was wrong, and in addition also help the track leads during the session selection process. -- Best Regards, Maish Saidel-Keesing __ 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
[openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions
Hello all, Going over today's presentation Load Balancing as a Service, Kilo and Beyond[1] (great presentation!!) - there are a few questions I have regarding the future release: For Octavia 1.0: 1. Can someone explain to me how the flow would work for spinning up a a new Amphora with regards to interaction between Neutron, LBaaS and Barbican? Same question as well regarding how the standby is created and its relationship with Barbican. 2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is released or only further down the line? If not what would you suggest be the way to orchestrate LBaaS until this is ready? 3. Is there some kind of hook into Security groups also planned for the Amphora to also protect the Load Balancer? I think that based on the answers to these questions above - additional questions will follow. Thanks [1] https://www.youtube.com/watch?v=-eAKur8lErU -- Best Regards, Maish Saidel-Keesing __ 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
[openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests
I just saw an email on the Operators list [1] that I think would allow a much simpler process for the non-developer community to submit a feature request. I understand that this was raised once upon a time [2] - at least in part a while back. Rally have have the option to submit a feature request (a.k.a. backlog) - which I think is straight forward and simple. I think this will be a good way for those who are not familiar with the way a spec should be written, and honestly would not know how to write such a spec for any of the projects, but have identified a missing feature or a need for an improvement in one of the Projects. They only need to specify 3 small things (a sentence / two for each) 1. Use Case 2. Problem description 3. Possible solution I am not saying that each feature request should be implemented - or that each possible solution is the best and only way to solve the problem. That should be up to each and every project how this will be (or even if it should be) implemented. How important it will be for them to implement this feature and what priority this should receive. A developer then picks up the request and turns it into a proper blueprint with proper actionable items. Of course this has to be valid feature request, and not just someone looking for support - how exactly this should be vetted, I have not thought this through till the end. But I was looking to hear some feedback on the idea of making this a way for all of the OpenStack projects to allow them to collect actual feedback in a simple way. Your thoughts and feedback would be appreciated. [1] http://lists.openstack.org/pipermail/openstack-operators/2015-May/006982.html [2] http://lists.openstack.org/pipermail/openstack-dev/2014-August/044057.html -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] [tc] A way for Operators/Users to submit feature requests
On 05/14/15 23:34, Jay Pipes wrote: On 05/14/2015 03:48 PM, Maish Saidel-Keesing wrote: I just saw an email on the Operators list [1] that I think would allow a much simpler process for the non-developer community to submit a feature request. I understand that this was raised once upon a time [2] - at least in part a while back. Rally have have the option to submit a feature request (a.k.a. backlog) - which I think is straight forward and simple. I think this will be a good way for those who are not familiar with the way a spec should be written, and honestly would not know how to write such a spec for any of the projects, but have identified a missing feature or a need for an improvement in one of the Projects. They only need to specify 3 small things (a sentence / two for each) 1. Use Case 2. Problem description 3. Possible solution I am not saying that each feature request should be implemented - or that each possible solution is the best and only way to solve the problem. That should be up to each and every project how this will be (or even if it should be) implemented. How important it will be for them to implement this feature and what priority this should receive. A developer then picks up the request and turns it into a proper blueprint with proper actionable items. Of course this has to be valid feature request, and not just someone looking for support - how exactly this should be vetted, I have not thought this through till the end. But I was looking to hear some feedback on the idea of making this a way for all of the OpenStack projects to allow them to collect actual feedback in a simple way. Hi Maish, I would support this kind of thing for projects that wish to do it, but at the same time, I wouldn't want the TC to mandate all projects use this method of collecting feedback. Projects, IMHO, should be free to self-organize as they wish, including developing processes that make the most sense for the project team. Best, -jay Thanks for the feedback Jay. There is a line between projects self organizing and providing a standard way that OpenStack does things. The TC (and the community as a whole) has decided on several guidelines for projects to be part of OpenStack. The way we gate, testing, security guidelines, naming conventions, etc.. These are mandated. A standard way of accepting feature requests will be a good thing in my opinion. -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments
On 05/12/15 20:48, Jay Pipes wrote: For operators: * Nagios * Icinga * Zabbix installed on baremetal machines deployed with the OpenStack and other infrastructure services. For tenants: * Nagios * Icinga * Zabbix installed on their VMs. Why are we re-inventing excellent open-source implementations of monitoring systems that have been around for over a decade? Because that is what we love to do here in the OpenStack Community?? (Sorry I could not resist... :) ) But seriously though - do we have a set of tools that can do this - in a simple - consolidated way? Best, -jay p.s. Sorry for top-posting. On 05/12/2015 01:20 PM, Vinod Pandarinathan (vpandari) wrote: Hello, I'm pleased to announce the development of a new project called CloudPulse. CloudPulse provides Openstack health-checking services to both operators, tenants, and applications. This project will begin as a StackForge project based upon an empty cookiecutter[1] repo. The repos to work in are: Server: https://github.com/stackforge/cloudpulse Client: https://github.com/stackforge/python-cloudpulseclient Please join us via iRC on #openstack-cloudpulse on freenode. I am holding a doodle poll to select times for our first meeting the week after summit. This doodle poll will close May 24th and meeting times will be announced on the mailing list at that time. At our first IRC meeting, we will draft additional core team members, so if your interested in joining a fresh new development effort, please attend our first meeting. Please take a moment if your interested in CloudPulse to fill out the doodle poll here: https://doodle.com/kcpvzy8kfrxe6rvb The initial core team is composed of Ajay Kalambur, Behzad Dastur, Ian Wells, Pradeep chandrasekhar, Steven DakeandVinod Pandarinathan. I expect more members to join during our initial meeting. A little bit about CloudPulse: Cloud operators need notification of OpenStack failures before a customer reports the failure. Cloud operators can then take timely corrective actions with minimal disruption to applications. Many cloud applications, including those I am interested in (NFV) have very stringent service level agreements. Loss of service can trigger contractual costs associated with the service. Application high availability requires an operational OpenStack Cloud, and the reality is that occascionally OpenStack clouds fail in some mysterious ways. This project intends to identify when those failures occur so corrective actions may be taken by operators, tenants, and the applications themselves. OpenStack is considered healthy when OpenStack API services respond appropriately. Further OpenStack is healthy when network traffic can be sent between the tenant networks and can access the Internet. Finally OpenStack is healthy when all infrastructure cluster elements are in an operational state. For information about blueprints check out: https://blueprints.launchpad.net/cloudpulse https://blueprints.launchpad.net/python-cloudpulseclient For more details, check out our Wiki: https://wiki.openstack.org/wiki/Cloudpulse Plase join the CloudPulse team in designing and implementing a world-class Carrier Grade system for checking the health of OpenStack clouds. We look forward to seeing you on IRC on #openstack-cloudpulse. Regards, Vinod Pandarinathan [1] https://github.com/openstack-dev/cookiecutter -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] TC Communications planning
On 05/06/15 16:13, Anne Gentle wrote: Hi all, In the interest of communicating sooner rather than later, I wanted to write a new thread to say that Flavio Percoco and I are going to work on a TC communications plan as co-chairs of a TC communications working group. I think we can find a happy medium amongst meeting minutes, gerrit reviews, and irregular blog entries by applying some comms planning, so that Flavio and I can dive in. Please answer these questions on the list if you're interested in shaping the communications plan: Audience considerations: Is the primary audience current OpenStack contributors or those in consumer roles? I would think Consumer Roles, most contributors are already in the know and on the mailing lists and meetings. What percentage of the audience are fairly new contributors? Fairly new to OpenStack itself? Is the audience more likely to be an outsider looking in to OpenStack governance? I would think so. The 'insider' already knows where and how to find the information. Is the audience wanting to click links to learn more, or do they just want the summary? Both would be great. There will be those who only want a summary, but sometimes would also like a bit more detail on a specific subject Does the audience always want an action to take, or is simply getting information their goal? I would leave that up to the audience. But if this is a communication channel - we should decide if it should be one-way or both ways. Channel considerations: Is this audience with their goals more likely to use blogs, RSS, and Twitter or subscribe to mailing lists? If we are talking about the non-contributor - a definite no to mailing and a huge yes to the first part of the list. Depending on the channels chosen, is cross-posting to multiple channels a huge error, or are we leaning towards a wide net rather than laser targeting? Cross posting should be fine since it will mostly be a link pointing to the main source of content - which will be a blog post of some sorts. Is there another channel we haven't considered that is widely consumed? FaceBook? But I personally don't go near it. Does the cadence have to be weekly, even if not much happened with the TC is the activity rate for the week? I do no think it has to be weekly, because perhaps that would become quite boring - if nothing really happened. I would say it should according to the need - but a minimum of once a month (even if there was nothing exciting). Thanks all for participating and giving input. Anne and Flavio __ 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 -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/05/15 18:10, Adam Lawson wrote: I think the ATC thing came up as one avenue to explore when folks were trying to figure out ways to quantify Operator involvement for the purpose of identifying who are actively contributing to OpenStack versus those who are fans/users of OpenStack but don't have time right now to contribute more formally. ATC, BTC, CTC, DTC... there are several great ideas that were brought up as possibilities as well as some take-aways for further discussion at the Vancouver Summit and the talking points for the User Committee. I'm really crossing my fingers this translates into something noticeably unique starting with the next election. In my perfect world anyway. ; ) I am all for OTC (OpenStack / Operational Technical Contributor) :) -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/05/15 16:01, Doug Hellmann wrote: Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700: So Thierry I agree. Developers are required to make it happen. I would say however that acknowledging the importance of developer contributions and selecting leadership from the development community is really half the battle as it's pretty rare to see project teams led and governed by only developers. I think addressing the inclusion of architects/operators/admins within this committee is a hugely positive development. The community of contributors is led by members, not all of whom are developers -- some are writers, translators, designers, or fill other important roles. The characteristic that cuts across all of those roles is that they are *contributors*. If architects/operators/admins or anyone else want to become contributors, there is already a path to accomplish that by interacting with the existing teams, and their insight and input would be very welcome. But there is no shortcut to becoming a leader in this community. Everyone has to earn their stripes. I've asked a couple of times in this thread what benefit you see in having someone from outside of the contributor community on the TC, but I haven't seen an answer. Is there something specific we could be addressing beyond the question of representation? Hi Doug. It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? Were bugs raised? Were blueprints submitted to make changes to accommodate any of these requests? Address any of them? Please don't tell me that you are waiting for the Operations people to submit all of these - because it is not going to happen. Most of them do not know how. So here is a process that breaks down. The info is there, but that information is not being followed through upon. Whose responsibility is this? The TC? The Foundation? The PTL's? Here we have proper feedback from those using the products, fighting with (not against) the products and trying to get it working. If even 10% of the items mentioned in these etherpads were addressed (or have a documented plan to be addressed in the future) then I will be very surprised. It comes down to this. OpenStack developers have a way of doing things. Operators also have a way of doing things - which is quite different to the way OpenStack does things. If each of these groups continue down the paths they are currently going - never shall the twain meet. They need to come towards each other. The OpenStack community needs be more receptive to the way Operators need things done. Operators need to be more receptive to the way things are done in OpenStack. Yes we have made progress. Yes we will continue to make progress. But until the Operators/users (and you can interchange users with Operators throughout my whole email - I was lazy) are accepted to be part of the decision process in OpenStack (and I think that you can agree - that if that actually happens today - it is way after the fact - or extremely late in the process) then this disconnect is going to continue. There is a feeling (at least that is my perception) that code is developed in a vacuum today. Without actually going into the field and asking what is needed - what is being used - what could be made better - before deciding what to write and fix. If you build it they will come[2] was a great idea in Hollywood, but I am not sure it will work as well for us - for OpenStack. Any ideas on how this could be solved - would be highly appreciated. [1] https://etherpad.openstack.org/p/PHL-ops-meetup [2] http://en.wikipedia.org/wiki/Field_of_Dreams -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/05/15 19:14, Sylvain Bauza wrote: Le 05/05/2015 18:00, Thierry Carrez a écrit : Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. Could we please stop to consider Ops and Devs as distinct groups of people ? Some Ops are also contributing to bugfixing or documentation, and some devs are also internal ops for their own company cloud. We're far from a world where people are not speaking the same language. They do, and OpenStack is so big that by some extend, Ops need to understand code and Devs need to understand Ops. Completely Agree!! At least one good opportunity for seeing how things are is just to attend an Upstream Training course and see the audience. And perhaps it could also be a good idea to have developers deploy and operate a highly available geographically dispersed OpenStack implementation trying to adhere to a defined SLA? It should go both ways. In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. __ 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 -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
I think that this will be my last say on this matter, because it seems to be getting out of hand. Us vs. them. Dev vs. Ops. It could be perceived that I am trying to wage a 'war' on the OpenStack development process, on the Developers, but that is not the case. But I do think there are valid points from both sides that need to be addressed. There are two sides of this story and in the end I do think that OpenStack as a community does need to accommodate and cater to the needs of of the colors of the rainbow. I hope that this discussion does open some doors, opens some minds and creates acceptance for those who are not like us. Believe me I have been dealing with this all my life. I would like to thank you all for your contribution and thoughts in this thread, I hope it was useful for you all as it was for me. -- Best Regards, Maish Saidel-Keesing On 05/04/15 20:11, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-05-04 17:46:21 +0300: On 05/04/15 17:07, Anita Kuno wrote: I'd like to go back to the beginning to clarify something. On 04/29/2015 02:34 PM, Adam Lawson wrote: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community In my statements I talked about acknowledging the operator community not representing them. When I speak, I represent myself and my best understanding of a certain situation, if others find value in the position I hold, they will let me know. In my view of what comprises OpenStack, the TC is one point of a triangle and the operators are an entirely different point. Trying to get two points of a triangle to be the same thing compromises the integrity of the structure. Each needs to play its part, not try to be something it is not. A three point triangle. I like the idea! Anita I assume that you are talking about the TC[3], the board [1] and the user committee [2]. I honestly do not see this at the moment as an equally weighted triangle. Should they be? Perhaps not, maybe yes. It could be that my view of things is skew, but here it is. The way to get something into OpenStack is through code. Who submits the code? Developers. Who approves code? Reviewers and core On top of that you have the PTL Above the PTL - you have the TC. They decide what is added into OpenStack and (are supposed) drive overall direction. These are the people that have actionable influence into what goes into the products. AFAIK neither the Foundation - nor the User committee have any actionable influence into what goes into the products, what items are prioritized and what is dropped. If each of the three point of the triangle had proper (actionable) influence and (actionable) say in what goes on and happens within the OpenStack then that would be ideal. Does the representation have to be equal? I don't think so. But it should be there somehow. One of the points of the User Committee mission is: Consolidate user requirements and present these to the management board and technical committee There is no mention that I could find on any of the other missions[3][1] that says that the TC or the board have to do anything with user requirements presented to them. I do not know if this has ever been addressed before, but it should be defined. A process with where the TC and collects requirements from the User Committee or Board and with a defined process this trickles down into the teams and projects. You're describing these relationships in a much more hierarchical manner than I think reflects their reality. Decisions about the future of OpenStack are made by the people who show up and contribute. We try to identify common goals and priorities, and where there's little overlap we support each other in ways that we perceive improve the project. That process uses input from many sources, including product managers from contributing companies and operator/user feedback. As Thierry pointed out, there's no community group dictating what anyone works on or what the priorities are. Again, I'm curious about the specific issues driving this discussion. Are there bugs or blueprints that you feel need more attention? Doug __ 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 __ 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
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/05/15 19:00, Thierry Carrez wrote: Maish Saidel-Keesing wrote: It is not only the representation - it is also action on the feedback. There was an OPS summit not so long ago in Philadelphia [1]. Two full days. I personally did not participate but from what I heard it was a good two days of discussions. It was. I was there. So were other TC members and PTLs. There are at least 10 etherpads (Yay!! The OpenStack way of doing things!) that summarized the thoughts and concerns of the participants. I think it would be fair to ask - how many actionable items came out of the this meeting that were implemented in any of the projects? If anyone has answers - they would be highly appreciated. Did the TC follow up on these items? Did the PTL's? (I know some of the PTL's were present there at the summit) Actually, we did. For example we talked about tags, and ops clearly expressed (1) the need for a kernel/compute base tag and (2) the intention to form a workgroup to define tags around operational maturity. For (1) the tag was just proposed, and for (2) an Ops workgroup has been created. As far as implemented in any of the projects go, I think you have a weird idea of the timeframe involved. The PHL meetup was in March, after the Kilo feature freeze. Way past time to implement anything in any project. Now you might say - that is not their job, but I do think that it should be. The developer teams are asking for feedback the whole time. Saying that Operators are not sending it back their way. Here they are. What was done with all of this? It's also interesting to note that in most of those sessions, we ended up with actions on the corresponding ops workgroup side to define the problem space and push the issue further, not actions on developers to pick up the etherpad and derive actions from it. I am not sure we live in the Ops vs. Dev world you seem to live in. There were Ops, there were Devs (and other contributors) present in that meetup and I didn't feel any of that us vs. them attitude there. Quite the contrary - I do not live in a Ops vs. Dev world. What I am trying to do here is help both sides understand each other. Because there should be no us vs. them thing here. It should be an us thing. But an ALL of us thing. In Vancouver we completely integrated Ops as one of the Design Sumit tracks, further acknowledging that Ops feedback is part of the Design. I for one am curious to see what will get out of it. +1 here! -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
and ceilometer performance improvements) are already under way as long-term changes, but some of them are going to need more time to solve. https://etherpad.openstack.org/p/PHL-ops-rabbit-queue I know the session on Rabbit was very helpful to the Oslo team, and we will have some discussions about what to do with the messaging library and alternative drivers. The Oslo team also prioritized the heartbeat bug in part as a result of these discussions. https://etherpad.openstack.org/p/PHL-ops-tags I've started seeing some new tags proposed to the governance repo. Are those a result of the tagging conversation? It comes down to this. OpenStack developers have a way of doing things. Operators also have a way of doing things - which is quite different to the way OpenStack does things. If each of these groups continue down the paths they are currently going - never shall the twain meet. They need to come towards each other. The OpenStack community needs be more receptive to the way Operators need things done. Operators need to be more receptive to the way things are done in OpenStack. Yes we have made progress. Yes we will continue to make progress. But until the Operators/users (and you can interchange users with Operators throughout my whole email - I was lazy) are accepted to be part of the decision process in OpenStack (and I think that you can agree - that if that actually happens today - it is way after the fact - or extremely late in the process) then this disconnect is going to continue. Yes, I think we all want operator and user input to be included much earlier in the process. It remains to be seen if the TC is the right group to address those concerns directly, since we tend to deal with issues that affect all projects rather than individual projects. That said, there is certainly still a gap in expectations for how feedback should be handled, and there's work to do to collect it and make sure the right audience sees it, and helping to develop the process to facilitate that communication may be something for the TC to take on. So how do we bridge this gap and get the feedback added earlier in the development cycle? And of course the obvious question - with whom does this responsibility lie? There is a feeling (at least that is my perception) that code is developed in a vacuum today. Without actually going into the field and asking what is needed - what is being used - what could be made better - before deciding what to write and fix. That's an unfortunate impression, and I know it is not always true. Many contributors are employed by companies who distribute OpenStack, and their work is informed by the feedback they have from their customers. Similarly, many contributors are employed by companies where they run OpenStack themselves, so they have first-hand experience. I'm not personally aware of any contributor who doesn't fall into one of those two categories, but there may well be some. Either way, those collective experiences may be different, but I think very little is happening in a total vacuum. Doug __ 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 -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 05/04/15 17:07, Anita Kuno wrote: I'd like to go back to the beginning to clarify something. On 04/29/2015 02:34 PM, Adam Lawson wrote: So I started replying to Doug's email in a different thread but didn't want to hi-jack that so I figured I'd present my question as a more general question about how voting is handled for the TC. Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community In my statements I talked about acknowledging the operator community not representing them. When I speak, I represent myself and my best understanding of a certain situation, if others find value in the position I hold, they will let me know. In my view of what comprises OpenStack, the TC is one point of a triangle and the operators are an entirely different point. Trying to get two points of a triangle to be the same thing compromises the integrity of the structure. Each needs to play its part, not try to be something it is not. A three point triangle. I like the idea! Anita I assume that you are talking about the TC[3], the board [1] and the user committee [2]. I honestly do not see this at the moment as an equally weighted triangle. Should they be? Perhaps not, maybe yes. It could be that my view of things is skew, but here it is. The way to get something into OpenStack is through code. Who submits the code? Developers. Who approves code? Reviewers and core On top of that you have the PTL Above the PTL - you have the TC. They decide what is added into OpenStack and (are supposed) drive overall direction. These are the people that have actionable influence into what goes into the products. AFAIK neither the Foundation - nor the User committee have any actionable influence into what goes into the products, what items are prioritized and what is dropped. If each of the three point of the triangle had proper (actionable) influence and (actionable) say in what goes on and happens within the OpenStack then that would be ideal. Does the representation have to be equal? I don't think so. But it should be there somehow. One of the points of the User Committee mission is: Consolidate user requirements and present these to the management board and technical committee There is no mention that I could find on any of the other missions[3][1] that says that the TC or the board have to do anything with user requirements presented to them. I do not know if this has ever been addressed before, but it should be defined. A process with where the TC and collects requirements from the User Committee or Board and with a defined process this trickles down into the teams and projects. My 0.02 Shekels. There have been many helpful comments on how those operators who wish to contribute to reviews, patches and specs as well as receive ATC status may do so, for those operators who wish to be acknowledged as contributors as well as being operators. Operators have a very useful, very valuable, very necessary perspective that is not a developer's perspective that needs to be heard and communicated. Thierry has made the suggestion that a strong User Committee representing the voice of the operator would be a good direction here. I support this suggestion. Tim Bell is working on an etherpad here: https://etherpad.openstack.org/p/YVR-ops-user-committee Thank you Adam, Anita. who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) Is it be feasible to start allowing the operator community to also cast votes for TC candidates? Is the TC *only* addressing technical concerns that are relevant to the development community? Since the TC candidates are embracing the idea of representing more than just the developer community, it would /seem/ the voters electing the TC members should include the communities being represented. If the TC only addresses developer concerns, it would seem they become at risk of losing touch with the operator/architecture/user concerns because the operator community voice is never heard in the voting booth. Perhaps this bumps into how it used to be versus how it should be. I don't know. Just struck me as incongruent with the platform of almost every candidate - broadening representation while the current rules prohibit that level of co-participation. Thoughts? *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 [1] https://wiki.openstack.org/wiki/Governance/Foundation/Mission [2] https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee [3] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee -- Best Regards, Maish Saidel-Keesing
Re: [openstack-dev] Congrats (I think) to the new TC
On 04/30/15 16:40, Jay Pipes wrote: On 04/30/2015 09:26 AM, David Medberry wrote: Hey guys, Congrats to the new TC leaders. http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688 Please reach out to me (and openstack-operat...@lists.openstack.org mailto:openstack-operat...@lists.openstack.org) if you ever need operator input (that you aren't already getting.) And many thanks for volunteering so much of your time this go round I *most* certainly will be reaching out to you, David. First up on the operator-related docket for me will be tags that represent production-level maturity. I have always maintained the the TC should help create the tag definition with the help of the operator community and rely on the operator community to determine which projects can get the tag applied to them. I hope you will be an instrument in achieving that collaboration. All the best, -jay A huge congratulations from me as well. I would also like to offer my help from an operator perspective and perhaps I can also help with the tasks that were discussed regarding finding a way to get the information out there to those who are not 'OpenStack savvy' or 'strong with the OpenStack force' . I have learned a lot from this election, the process, the candidates, the active members of the community, and also from the results. I definitely think we are on the right path. Rome was not built in a day, peace in the middle east will not come for another 1000 years and changes take time. -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [tc] Who is allowed to vote for TC candidates
On 04/30/15 10:15, Thierry Carrez wrote: Doug Hellmann wrote: Anyway, I find it curious that the TC is elected by those within the developer community but TC candidates talk about representing the operator community who are not allowed to vote. Operators meaning Admins, Architects, etc. It sounds like this is something most TC candidates want which most would agree is a good thing. At least I think so. ; ) I'm going to nitpick on terminology a bit. The TC is elected by *technical contributors*, not developers, as described in the charter: http://governance.openstack.org/reference/charter.html#voters-for-tc-seats-atc +1 I think there is a key misconception in this thread that the TC is supposed to represent (or talk about representing) more than just the technical contributors that produce OpenStack. When the OpenStack Foundation was set up, three bodies of governance were established: - the Board of Directors (representing the community as a whole) - the Technical Committee (representing technical contributors) - the User Committee (representing users and ops of OpenStack) The Technical Committee mandate is therefore not to represent the users and Ops of OpenStack in that setup, it's the role of the User committee. If we did include Ops, we would be clearly overstepping our mandate. Thierry, essentially I agree with you. I do think though that the disconnect between Dev Ops is an unhealthy situation. Two separate bodies working in two different ways with two different agendas is actually very much against the current way that most development organizations are aspire towards. The TC charter [1] states. The Technical Committee (“TC”) is tasked with providing the technical leadership for OpenStack as a whole (all official projects, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple projects, forms an ultimate appeals board for technical decisions, and generally has technical oversight over all of OpenStack. IMHO, the spirit of the original question that was raised was - how can all of OpenStack only be those who write the code, and not those that use and operate it on a day to day basis? Rather than asking that Ops should be able to elect the TC, you should probably start discussing how to improve on the User committee election process and visibility. It would be great to understand how exactly this was done, what their charter is and how much influence they have on technical decisions within the larger OpenStack as a whole [2] [1] http://governance.openstack.org/reference/charter.html [2] https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [Elections] TC Election analysis
On 04/30/15 21:48, Joe Gordon wrote: As others have done for past elections, here is a brief breakdown of the TC election ballot data. analysis: http://paste.openstack.org/show/213831 source code: http://paste.openstack.org/show/213830 Some highlights are: * 3 people voted but ranked everyone as #19 * 16% of the ballots voted for 3 or fewer candidates * Theirry and Jay did much better then everyone else. * Most winning candidates were ranked #19 over 1/3 of the time. * No one voted for only James while 6 people only voted for Flavio (min and max) Thanks Joe for the analysis. It is quite interesting. Another thing that I find interesting is the low participation rate. Out of 2169 eligible voters, 548 participated - that is 25.26%. Comparing to previous elections Oct. 2014 - 1893 eligible voters, 506 participated - 26.73% Apr. 2014 - 1510 eligible voters, 408 participated - 29.66% I am wondering why the participation level is so low. This is really one of the few opportunities a contributor has to define the direction of OpenStack as a whole. And yet it goes down each election. I can think of perhaps two reasons for low participation. 1. People do not see find that they need interaction with the TC, they are focused on the work going on in their project and at most - have interaction they need with the PTL, they do not really care that much about - or have any dealings with the TC and it members - so they do not find it important enough to participate. 2. Could it be that OpenStack has contributors that are producing code - mainly because that is what their job is - they are hired by a vendor, a company that has made it a priority to get code into the products - and therefore they produce code, and evidently it is a sizable number of people like this - but do not really participate in the community? Thoughts? -- Best Regards, Maish Saidel-Keesing __ 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
[openstack-dev] [all] Question for the TC candidates
like to laud his efforts in pursuit of write it down which he has mentioned many times) pointed out the existing situation there were, effectively, bugs: * disconnected taxonomy in the presentation of the blogs * misconceptions about the frequency of postings If we can clear up those preconceptions then we can find the stable state from which improvements can be made. I fully agree! It is true that I have dissatisfaction about the visibility of the TC and I think a lot of the candidates have made it clear that they are concerned with that issue too. That's great! / It is detrimental to our overall electoral process if folks cloak / / personal points of disagreement in the guise of open discussion. / I would think that disagreements are in fact exactly the reason for having open discussion and such discussion is one of the best ways to know where people stand. I didn't, however, have that in mind when I responded to clarify things with Doug. I for one would welcome as much open discussion as possible. Of course without any personal attacks. Apparently my efforts to be lighthearted about that didn't quite play as I planned, and for that I apologize. As I was looking for blog postings I found so _few_ that I assumed any statements of there's 3 here and 4 over there[1] (covering the last greater than a year) were similarly lighthearted. I guess my expectations are way off? / I do continue to hope that candidate statements and responses are / / helpful to the electorate and that they cast their ballot without / / feeling that doing so is an indication about their feelings regarding a / / secondary issue. / I can't let this go without making yet another comment. I feel like I should just leave it alone because apparently I'm in deep water but: In what fashion is the effectiveness of TC communication a secondary issue? No, we're not going to solve it immediately and really we don't need to hash over the policies and procedures of the past. We might, however, like to make it better for the future. I sincerely hope that this will be possible. -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] Question for the TC candidates
. Yes, I don't think anyone is arguing against that point. The question remains, though: How? Is a blog post a useful medium, or should we be doing something else? Excerpts from Jeremy Stanley's message of 2015-04-28 16:21:17 +: / On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: // [...] // What's important to avoid is the blog postings being only reporting of // conclusions. They also need to be invitations to participate in the // discussions. Yes, the mailing list, gerrit and meeting logs have some // of the ongoing discussions but often, without a nudge, people won't // know. // [...] // // Perhaps better visibility for the meeting agenda would help? As in // these are the major topics we're planning to cover in the upcoming // meeting, everyone is encouraged to attend sort of messaging? // Blogging that might be a bit obnoxious, not really sure (I'm one of // those luddites who prefer mailing lists to blogs so tend not to // follow the latter anyway). / I am not sure that you want people chiming in every single TC meeting - that will become quite chaotic. We regularly have non-TC members attend and participate in the meetings. Excerpts from Chris Dent's message of Tue Apr 28 15:30:21 UTC 2015 I'm not trying to suggest that the TC is trying to keep people in the dark, rather that it always takes more effort than anyone would like to make sure things are lit. I don't think that anyone is implying that you are saying that the TC is keeping it to themselves. I for one would also like to see more communication coming out of the TC. And yes it does take effort. Taking as given that we should be open and communicate more, I would like to ask a concrete question. It seems like there is a general sense of concern about communication, but I want to make sure it's not related to ongoing discussions. Is there something specific that happened over the last year that was a surprise, or that was not communicated well? Something we could address in the short term with a blog post or email discussion? How about the fact that the definition of an ATC was changed [1] for a free Summit pass? [2] Excerpts from Chris Dent's message of Tue Apr 28 18:11:44 UTC 2015 I wouldn't have joined the commentary on the blogging issue if there hadn't already been a fair bit of talk about how fixing the feedback loop was one of the roads to improving. Also, critically, when Doug (who I can see is just trying to point out the current picture of reality so I'm not criticizing him, in fact I'd like to laud his efforts in pursuit of write it down which he has mentioned many times) pointed out the existing situation there were, effectively, bugs: * disconnected taxonomy in the presentation of the blogs * misconceptions about the frequency of postings If we can clear up those preconceptions then we can find the stable state from which improvements can be made. I fully agree! It is true that I have dissatisfaction about the visibility of the TC and I think a lot of the candidates have made it clear that they are concerned with that issue too. That's great! / It is detrimental to our overall electoral process if folks cloak / / personal points of disagreement in the guise of open discussion. / I would think that disagreements are in fact exactly the reason for having open discussion and such discussion is one of the best ways to know where people stand. I didn't, however, have that in mind when I responded to clarify things with Doug. For what it's worth, I'm not reading this discussion as us disagreeing in any way. We made some reasonable starts at publicizing our ongoing work, but it's clear we can do better from a technical standpoint (tagging posts) and from a volume standpoint (publishing more often). I'm interested in having more input into how best to improve communication, so I keep asking questions and I'm glad you're all still answering. :-) Apparently my efforts to be lighthearted about that didn't quite play as I planned, and for that I apologize. As I was looking for blog postings I found so _few_ that I assumed any statements of there's 3 here and 4 over there[1] (covering the last greater than a year) were similarly lighthearted. I guess my expectations are way off? Er, yeah, if the 3 or 4 part was meant somewhat jokingly I missed that in my reading of your email because it was pretty close to the actual count and *I* was surprised. I thought we had done more. Doug __ 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 [1] https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/ [2] https://www.mail-archive.com/openstack-infra@lists.openstack.org/msg01430.html -- Best Regards, Maish Saidel-Keesing
Re: [openstack-dev] [all] Question for the TC candidates
On 04/29/15 21:59, Stefano Maffulli wrote: On Wed, 2015-04-29 at 18:28 +0300, Maish Saidel-Keesing wrote: How about the fact that the definition of an ATC was changed [1] for a free Summit pass? [2] This was not a decision of the TC, it was a decision of the Foundation staff. The definition of ATC has *not* changed, that's embedded in the bylaws. I stand corrected. (more than once :) ) Thanks for the clarification Stefano, Doug and Jeremy. And who gets the pass hasn't changed much either: people who are *actively* committing code and documentation to OpenStack have received an invite. Previously we have considered *actively* committing code and docs == ATC. For this cycle the Foundation staff started considering better ways to identify those that actually contribute to the design discussions. The details of who gets a free invite may change again in the future because we want to keep the Open promises, without compromising the event. HTH stef -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Hello Chris, and thank you for posting this question. First I must apologize since I was not able to answer this thread earlier - due to a problem with me receiving the emails from the list. I had to ask the election committee how to add my answer to the thread, I hope this attempt works forgive me if the formatting in this answer comes out a bit weird. There are lots of different ways to categorize the various stakeholders in the OpenStack community, no list is complete. For the sake of this question the people I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. I think that there is a basic misconception here - and that is one of the reasons I decided to run. You mentioned the stakeholders - developers, end-users, and operators. Yes they all have a direct interaction with the community and the products being written, but I think it is safe to say that they all interact on a very different level. Their is a very clear hierarchy here - even if it has not been explicitly defined. These stakeholders are not equal. I am not saying that they should be equal but I do think that the current balance is nowhere near the way it should be - so that it is beneficial for each of these groups. What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? A solution is only as good as those who use it. Those who use it will only do so it if it useful to them. They will use it when it can solve a problem they have. They will use it when they know there is someone one the other side who is receptive to their questions, their suggestions and their input. I think that the TC in the upcoming terms should find a way to help each of the teams and their PTL's prioritize what should be done in the next two cycles (because that is what the election term is for). This should be based on the aspirations of each of the teams, but it also must consider the feedback from both the users and the operators as to what features they would like to see implemented and what things need to be fixed. As for me personally, if elected, I would like to invest my efforts in finding a way to get that feedback back into the TC and further down into each of the products. we have several initiatives running in parallel today, and I hope that I can find a way to allow this information to flow back in a more streamlined manner in order to improve the quality of each of the projects and help them meet the needs of the people who are actually going to be using it. In addition to the above, I do believe the quality of the product will improve if we become more receptive to input from those who are not writing the code. Today that is a substantial hurdle for most end-users and operators, something that I would like to try and make accessible - without lowering the quality of the code and our products. It is fine balance - yet one that I think it is all of our best interests to find, hard as it may be. -- Best Regards, Maish Saidel-Keesing __ 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
[openstack-dev] TC Candidacy
I would like to announce my candidacy for the OpenStack Technical Committee Many of you many not know me, because I am not a very active contributor. First a bit about myself. I am a Platform Architect working for Cisco in Israel and have been involved with OpenStack for the past two years. I was and (and still am a very active member of the virtualization community [1] and have been for a good number of years. I was honored to contribute and participate in the OpenStack Architecture Design Guide [2]. I am not new to writing but this was a new experience for me. One that I thoroughly enjoyed and would love to do again, if presented with the opportunity. These are the following reasons I think I can make a difference as part of the TC #1 Diversity The vast majority of the TC members are all long standing and well known members of the OpenStack community. Many of them have been core-developers, PTL's, reviewers. All of them have one thing in common they are developers and people who take pride and joy in contributing code to the OpenStack projects. I too have contributed code to the OpenStack projects - but not on the scale that any of the other candidates have. nowhere near close. And I am not ashamed of that fact. I am not a developer. Yes, I dabble in code (not as much as I would like), but I am deep down in my heart, an Operations guy. I like to get things to work, but not only that they work, but that they are stable, robust, and will provide a sound infrastructure (so that I do not get paged at 03.00 every night because something fell over and died). When all of the members of a committee are from a single 'stream' then it is natural to look at things in a certain way. But that is not the only way to look at things, there are other perspectives that need to be considered and that perspective (in my humble opinion) is missing. #2 Focus There has been a lengthy discussion over the past few months about what OpenStack is and what it is not. What should be part of OpenStack and again what should not. I cannot say that I fully agree with all the decisions that have been made, although I do fully agree with the direction in which OpenStack is going and how the TC has been driving that. I feel that the as part of the TC I will help the community focus on building a tightly integrated suite of software (there is no way you can call OpenStack a product) that will work, and work well [3]. #3 Acceptance of others It is no secret that i think that I have spoken my mind[4], more than once on how I find it extremely hard for someone who is not a developer to help and make OpenStack better. I have tried to lower that hurdle in a number of ways [5] to make it easier for 'non-dev's' to starting 'chipping in'. But it seems that I was not successful. Even with regards to myself. We are all members of the community. But there are several levels. Even in this election only ''Individual Members who committed a change to a repository under ’any’ of the official OpenStack Project Teams (as defined above) over the last two 6-month release cycles are automatically considered ATC'' and they are the only ones that can vote. There are other ways to contribute. People that report bugs contribute. People that write blog posts contribute. People that evangelize in User groups and speak at conferences, meetings etc. - they also contribute. It is not all about code. Yes it is hard to quantify. Yes it is hard to measure. But that does not mean it should not be considered. If elected to serve as part of the TC - this is something I would like pursue - something that can make the OpenStack community not only a developer community - but a community of all those who care about it. I would like to leave you with one last thought. I thought long and hard about putting up myself as a candidate. I do think that I have a fresh perspective to bring to the table, a different way of looking at things and a lot of passion that can help OpenStack achieve what it set out to do. ``Our goal is to produce the ubiquitous Open Source cloud computing platform that will meet the needs of public and private cloud providers regardless of size, by being simple to implement and massively scalable.`` I would like to wish all the candidates the best of luck. -- Best Regards, Maish Saidel-Keesing [1] http://vsphere-land.com/news/top-vblog-2015-full-results.html [2] http://technodrone.blogspot.com/2014/08/the-openstack-architecture-design-guide.html [3] http://technodrone.blogspot.com/2014/08/to-innovate-or-to-stabilize-that-is.html [4] http://technodrone.blogspot.com/2014/09/an-open-letter-to-openstack-foundation.html [5] http://technodrone.blogspot.com/2014/11/start-contributing-to-openstack-easy.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ
[openstack-dev] [Infra] Use of heat for CI of OpenStack
I was wondering.. Is the OpenStack CI/CD Infra using Heat in any way? Do the commits trigger a new build of DevStack/OpenStack that is based on a Heat Template or just the provisioning of a regular instance and then deployment of code on top of that? -- Best Regards, Maish Saidel-Keesing __ 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
[openstack-dev] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested
Is Ceilometer ready for prime time? I would be interested in hearing from people who have deployed OpenStack clouds with Ceilometer, and their experience. Some of the topics I am looking for feedback on are: - Database Size - MongoDB management, Sharding, replica sets etc. - Replication strategies - Database backup/restore - Overall useability - Gripes, pains and problems (things to look out for) - Possible replacements for Ceilometer that you have used instead If you are willing to share - I am sure it will be beneficial to the whole community. Thanks in Advance With best regards, Maish Saidel-Keesing Platform Architect Cisco __ 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
[openstack-dev] [All] Start Contributing to OpenStack - The Easy Way with a docker container
I would like to share with a small tool that should make things a lot easier to start getting involved in contributing code into Openstack. The OpenStack-git-env docker[1] container. Simple. docker pull maishsk/openstack-git-env More details can be found on this blog post[2]. [1] https://registry.hub.docker.com/u/maishsk/openstack-git-env/ [2] http://technodrone.blogspot.com/2014/11/start-contributing-to-openstack-easy.html Feedback is always welcome -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Order of machines to be terminated during scale down
In which order are machines terminated during a scale down action in an auto scaling group For example instance 1 2 were deployed in a stack. Instances 3 4 were created as a result of load. When the load is reduced and the instances are scaled back down, which ones will be removed? And in which order? From old to new (1-4) or new to old (4 - 1) ? Thanks -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Order of machines to be terminated during scale down
On 26/11/2014 14:50, Jay Lau wrote: The current behavior is not flexible to customer, I see that we have a blueprint want to enhance this behavior. https://blueprints.launchpad.net/heat/+spec/autoscaling-api-resources https://wiki.openstack.org/wiki/Heat/AutoScaling In Use Case section, we have the following: == Use Cases 1. Users want to use AutoScale without using Heat templates. 2. Users want to use AutoScale *with* Heat templates. 3. Users want to scale arbitrary resources, not just instances. 4. Users want their autoscaled resources to be associated with shared resources such as load balancers, cluster managers, configuration servers, and so on. 5. TODO: Administrators or automated processes want to add or remove *specific* instances from a scaling group. (one node was compromised or had some critical error?) 6. TODO: Users want to specify a general policy about which resources to delete when scaling down, either newest or oldest 7. TODO: A hook needs to be provided to allow completion or cancelling of the auto scaling down of a resource. For example, a MongoDB shard may need draining to other nodes before it can be safely deleted. Or another example, replica's may need time to resync before another is deleted. The check would ensure the resync is done. 8. *TODO: Another hook should be provided to allow selection of node to scale down. MongoDB example again, select the node with the least amount of data that will need to migrate to other hosts.* === Item 8 is enabling customer can customize the instance to scale down. Thanks Jay - I know that it is not available today. What I would like to know is - what is the order that is used today? Thanks Maish Thanks! 2014-11-26 18:30 GMT+08:00 Pavlo Shchelokovskyy pshchelokovs...@mirantis.com mailto:pshchelokovs...@mirantis.com: Maish, by default they are deleted in in the same order they were created, FIFO style. Best regards, Pavlo Shchelokovskyy. On Wed, Nov 26, 2014 at 12:24 PM, Maish Saidel-Keesing maishsk+openst...@maishsk.com mailto:maishsk+openst...@maishsk.com wrote: In which order are machines terminated during a scale down action in an auto scaling group For example instance 1 2 were deployed in a stack. Instances 3 4 were created as a result of load. When the load is reduced and the instances are scaled back down, which ones will be removed? And in which order? From old to new (1-4) or new to old (4 - 1) ? Thanks -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com http://www.mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Order of machines to be terminated during scale down
Thanks Pavlo. Is there any reason why FIFO was chosen? Maish On 26/11/2014 12:30, Pavlo Shchelokovskyy wrote: Maish, by default they are deleted in in the same order they were created, FIFO style. Best regards, Pavlo Shchelokovskyy. On Wed, Nov 26, 2014 at 12:24 PM, Maish Saidel-Keesing maishsk+openst...@maishsk.com mailto:maishsk+openst...@maishsk.com wrote: In which order are machines terminated during a scale down action in an auto scaling group For example instance 1 2 were deployed in a stack. Instances 3 4 were created as a result of load. When the load is reduced and the instances are scaled back down, which ones will be removed? And in which order? From old to new (1-4) or new to old (4 - 1) ? Thanks -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com http://www.mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [All] [Openstack-docs] High Availability Guide Update - RFI
Hello All. We kicked off our first meeting yesterday the review of the HA guide.[1] We need to get the *current* HA model for each of the core components. It would be great if either the PTL of each project - (or someone else that has a definitive answer) could add their feedback to this query so we could start the ball rolling and collect the information. ** Just to clarify - this would be only for the OpenStack components and depending software (i.e. Databases and message queues etc..) not the underlying instances ** The requested information is: - Project Name - Active/Active or Active/Passive or both or other? - Suggested method of implementation - Additional info that you feel is relevant to add. [1] https://etherpad.openstack.org/p/openstack-haguide-update Thanks -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On 30/10/2014 11:22, Angus Salkeld wrote: On Thu, Oct 30, 2014 at 5:48 PM, Eoghan Glynn egl...@redhat.com mailto:egl...@redhat.com wrote: IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two elections prior to this one filtered out. Well, the base electorate for the TC are active contributors with patches landed to official projects within the past year, so these are devs getting their code merged but not interested in voting. This is somewhat different from (though potentially related to) the dead weight foundation membership on the rolls for board elections. Also, foundation members who have not voted in two board elections are being removed from the membership now, from what I understand (we just needed to get to the point where we had two years worth of board elections in the first place). Thanks, I lost my mind here and confused the board with the TC. So then my next question is, of those who did not vote, how many are from under-represented companies? A higher percentage there might point to disenfranchisement. Well, that we don't know, because the ballots are anonymized. So we can only make a stab at detecting partisan voting patterns, in the form a strict preference for candidates from one company over all others, but we've no way of knowing whether voters from those same companies actually cast the ballots in question. I'd love to see a rule that says you can't vote for people from your own company. That would turn things around :-) -A I think that hell would freeze over before that happens... Maish ... i.e. from these data, the conclusion that the preferred pairs of candidates were just more popular across-the-board would be equally valid. Conversely, we've no way of knowing if the voters employed by those under-represented companies you mention had a higher or lower turnout than the average. If there is a concern about balanced representation, then the biggest single change we could make to address this, IMO, would be to contest all TC seats at all elections. Staggered terms optimize for continuity, but by amplifying the majority voice (if such a thing exists in our case), they tend to pessimize for balanced representation. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Travels tips for the Paris summit
Thanks for creating the page. I have added a section to it with information about Kosher restaurants as well. Well done and thank you for the invaluable information Maish On 14/10/2014 20:02, Anita Kuno wrote: On 10/14/2014 12:40 PM, Sylvain Bauza wrote: Le 14/10/2014 18:29, Anita Kuno a écrit : On 10/14/2014 11:35 AM, Adrien Cunin wrote: Hi everyone, Inspired by the travels tips published for the HK summit, the French OpenStack user group wrote a similar wiki page for Paris: https://wiki.openstack.org/wiki/Summit/Kilo/Travel_Tips Also note that if you want some local informations or want to talk about user groups during the summit we will have a booth in the market place expo hall (location: E47). Adrien, On behalf of OpenStack-fr ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev This is awesome, thanks Adrien. I have a request. Is there any way to expand the Food section to include how to find vegetarian restaurants? Any help here appreciated. Well, this is a tough question. We usually make use of TripAdvisor or other French noting websites for finding good places to eat, but some small restaurant don't provide this kind of information. There is no official requirement to provide these details for example. What I can suggest is when looking at the menu (this is mandatory to put it outside of the restaurant) and check for the word 'Végétarien'. Will amend the wiki tho with these details. -Sylvain Thanks Sylvain, I appreciate the pointers. Will wander around and look at menus outside restaurants. Not hard to do since I love wandering around the streets of Paris, so easy to walk, nice wide sidewalks. I'll also check back on the wikipage after you have edited. Thank you! Anita. Thanks so much for creating this wikipage, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][docs][tc] How to scale Documentation
On 05/10/2014 06:00, Jay Pipes wrote: On 10/03/2014 09:18 PM, Zane Bitter wrote: The prospect of a much larger tent with many more projects in OpenStack-proper shines a spotlight on the scalability of the Docs team, and in particular how they decide which projects are important to work on directly. I don't believe that a ticket to live under the OpenStack tent should come with the expectation that the Docs team is required to write documentation for the project. IMHO, it should be up to the project itself to provide the resources to work *under the guidance* of the Docs team to write developer, end user and operator documentation. The Docs team members should be able to play an advisory role for new projects, helping them understand the automated doc processes, the way that common doc infrastructure works, and techniques for writing useful documentation consistent with other projects. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev A huge +1 on this! You cannot expect the Docs team to understand and document a project - on the project team knows the ins and outs of the code, what it can do, and how to use it. This does not mean it should be a free for all. Work *with* the the Docs team to make the documentation standard and consistent across all of OpenStack. -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
This looks great - but I am afraid that something might be missing. As part of the Design summit in Atlanta there was an Ops Meetup track. [1] I do not see where this fits into the current planning process that has been posted. I would like to assume that part of the purpose of the summit is to also collect feedback from Enterprise Operators and also from smaller ones as well. If that is so then I would kindly request that there be some other way of allowing that part of the community to voice their concerns, and provide feedback. Perhaps a track that is not only Operator centric - but also an End-user focused one as well (mixing the two would be fine as well) Most of them are not on the openstack-dev list and they do not participate in the IRC team meetings, simply because they have no idea that these exist or maybe do not feel comfortable there. So they will not have any exposure to the process. My 0.02 Shekels. [1] - http://junodesignsummit.sched.org/overview/type/ops+meetup On 12/09/2014 18:42, Thierry Carrez wrote: Eoghan Glynn wrote: If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. +1 on a collaborative scheduling process within each project. That's pretty much what we did within the ceilometer core group for the Juno summit, except that we used a googledocs spreadsheet instead of an etherpad. So I don't think we need to necessarily mandate usage of an etherpad, just let every project decide whatever shared document format they want to use. FTR the benefit of a googledocs spreadsheet in my view would include the ease of totalling votes sessions slots, color-coding candidate sessions for merging etc. Good point. I've replaced the wording in the wiki page -- just use whatever suits you best, as long as it's a public document and you can link to it. -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
On 17/09/2014 23:12, Anita Kuno wrote: On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote: This looks great - but I am afraid that something might be missing. As part of the Design summit in Atlanta there was an Ops Meetup track. [1] I do not see where this fits into the current planning process that has been posted. I would like to assume that part of the purpose of the summit is to also collect feedback from Enterprise Operators and also from smaller ones as well. If that is so then I would kindly request that there be some other way of allowing that part of the community to voice their concerns, and provide feedback. Perhaps a track that is not only Operator centric - but also an End-user focused one as well (mixing the two would be fine as well) Most of them are not on the openstack-dev list and they do not participate in the IRC team meetings, simply because they have no idea that these exist or maybe do not feel comfortable there. So they will not have any exposure to the process. My 0.02 Shekels. [1] - http://junodesignsummit.sched.org/overview/type/ops+meetup Hi Maish: This thread is about the Design Summit, the Operators Track is a different thing. In Atlanta the Operators Track was organized by Tom Fifield and I have every confidence he is working hard to ensure the operators have a voice in Paris and that those interested can participate. Last summit the Operators Track ran on the Monday and the Friday giving folks who usually spend most of the time at the Design summit to participate and hear the operator's voices. I know I did and I found it highly educational. Thanks, Anita. Thanks for the clarification Anita :) Maish On 12/09/2014 18:42, Thierry Carrez wrote: Eoghan Glynn wrote: If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. +1 on a collaborative scheduling process within each project. That's pretty much what we did within the ceilometer core group for the Juno summit, except that we used a googledocs spreadsheet instead of an etherpad. So I don't think we need to necessarily mandate usage of an etherpad, just let every project decide whatever shared document format they want to use. FTR the benefit of a googledocs spreadsheet in my view would include the ease of totalling votes sessions slots, color-coding candidate sessions for merging etc. Good point. I've replaced the wording in the wiki page -- just use whatever suits you best, as long as it's a public document and you can link to it. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] [LBaaS] Packet flow between instances using a load balancer
I am trying to find out how traffic currently flows went sent to an instance through a LB. Say I have the following scenario: RHA1 LB_A -- - LB_B --- RHB1 | | RHA2 ---| |- RHB2 A packet is sent from RHA1 to LB_B (with a final destination of course being either RHB1 or RHB2) I have a few questions about the flow. 1. When the packet is received by RHB1 - what is the source and destination address? Is the source RHA1 or LB_B? Is the destination LB_B or RHB_1? 2. When is the packet modified (if it is)? And how? 3. Traffic in the opposite direction. RHB1 - RHA1. What is the path that will be taken? The catalyst of this question was how to control traffic that is coming into instances through a LoadBalancer with security groups. At the moment you can either define a source IP/range or a security group. There is no way to add a LB to a security group (at least not that I know of). If the source IP that the packet is identified with - is the Load balancer (and I suspect it is) then there is no way to enforce the traffic flow. How would you all deal with this scenario and controlling the traffic flow? Any help / thoughts is appreciated! -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Plugin Mechanism for Openstack Components to provide HA
I was wondering if any work has been done on developing a standard plugin mechanism to provide HA to the OpenStack components Let me try and explain what I mean. Today there is a certain degree of how the components can be made to work in either an active/active or active/passive fashion. But they differ by component. Galera for Mysql for example, RabbitMQ is already multi-node. The rest of the components are usually put behind HAproxy. But with every new component added (for example Heat, Ceilometer, Trove and many more to come), ideally (for me at least) the best way would be the same way you install the package through yum/apt part of this package could have a plugin to a central HA component with all the information needed to make this component highly available. Am I barking up the wrong tree? With best regards, Maish Saidel-Keesing Platform Architect SPVSS msaid...@cisco.commailto:msaid...@cisco.com Phone: +972-2-5886103 Mobile: +972542206103 [http://www.cisco.com/web/europe/images/email/signature/logo02.jpg]http://www.cisco.com/global/IL/ [http://www.cisco.com/assets/social_media_icons/twitter-16x16.png]http://twitter.com/maishsk [http://www.cisco.com/assets/social_media_icons/google-16x16.png] http://vexpert.me/maishsk [http://www.cisco.com/assets/social_media_icons/linkedin-16x16.png] http://il.linkedin.com/in/maish/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
