[openstack-dev] PGP keysigning party for Mitaka summit in Tokyo?
Hello I see that https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Mitaka_Summit is empty and no email thread about the topic, will be any more or less formal keysigning party in Tokyo? is it too late? -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: http://keybase.io/gfa __ 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] [javascript] Linters
On 2015-06-06 03:26, Michael Krotscheck wrote: Right now, there are several JS linters in use in OpenStack: JSHint, JSCS, and Eslint. I really would like to only use one of them, so that I can figure out how to sanely share the configuration between projects. Can all those who have a strong opinion please stand up and state their opinions? what about https://bitbucket.org/dcs/jsmin/ it's license is free -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: http://keybase.io/gfa __ 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] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
On 2015-03-21 02:57, Assaf Muller wrote: Hello everyone, The use_namespaces option in the L3 and DHCP Neutron agents controls if you can create multiple routers and DHCP networks managed by a single L3/DHCP agent, or if the agent manages only a single resource. Are the setups out there *not* using the use_namespaces option? I'm curious as to why, and if it would be difficult to migrate such a setup to use namespaces. i'm using it in CI/test environment, where i need to connect to the vm and the control plane at the same time. (vm network is gre) I'm asking because use_namespaces complicates Neutron code for what I gather is an option that has not been relevant for years. I'd like to deprecate the option for Kilo and remove it in Liberty. in production i use namespaces, but only because is the default. we have many clouds and none of them share the same ip range. as other have said, i think is better to have less moving parts, namespaces had problems with kernel and iproute2 before and may have problems again -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 __ 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] [openstack-operators]flush expired tokens and moves deleted instance
On 01/28/2015 01:13 AM, Fischer, Matt wrote: > Our keystone database is clustered across regions, so we have this job > running on node1 in each site on alternating hours. I don’t think you’d > want a bunch of cron jobs firing off all at once to cleanup tokens on > multiple clustered nodes. That’s one reason I know not to put this in > the code. i prefer a cronjob to something on the code that i have to test, configure and possible troubleshot besides, i think is well documented. i don't see a problem there. maybe distributions could ship the script into /etc/cron.daily by default? i would remove it on my case but is a good default for simple openstack installs -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 __ 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] The future of the integrated release
On 08/22/2014 02:13 PM, Michael Chapman wrote: > > We try to target puppet module master at upstream OpenStack master, but > without CI/CD we fall behind. The missing piece is building packages and > creating a local repo before doing the puppet run, which I'm working on > slowly as I want a single system for both deb and rpm that doesn't make > my eyes bleed. fpm and pleaserun are the two key tools here. i have used fpm to package python apps, i would happy to help if you can provide pointers where to start -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree
i like your idea, as an operator, it gives me new features while keep my core running fine. only one think i didn't like it why all url,api, etc has to include the word 'preview'? i imagine that i would be consuming the new feature using heat, puppet, local scripts, custom horizon, whatever. Why do you make me to change all them when the feature moves out of preview? it could be a lot of rework (for consumers) without gain. I would totally support other big fat warnings everywhere (logs, documentation, startup log of neutron-server) but don't change the API if is not necessary thanks On 08/08/2014 05:21 PM, Robert Kukura wrote: > [Note - I understand there are ongoing discussion that may lead to a > proposal for an out-of-tree incubation process for new Neutron features. > This is a complementary proposal that describes how our existing > development process can be used to stabilize new features in-tree over > the time frame of a release cycle or two. We should fully consider both > proposals, and where each might apply. I hope something like the > approach I propose here will allow the implementations of Neutron BPs > with non-trivial APIs that have been targeted for the Juno release to be > included in that release, used by early adopters, and stabilized as > quickly as possible for general consumption.] > > According to our existing development process, once a blueprint and > associated specification for a new Neutron feature have been reviewed, > approved, and targeted to a release, development proceeds, resulting in > a series of patches to be reviewed and merged to the Neutron source > tree. This source tree is then the basis for milestone releases and the > final release for the cycle. > > Ideally, this development process would conclude successfully, well in > advance of the cycle's final release, and the resulting feature and its > API would be considered fully "stable" in that release. Stable features > are ready for widespread general deployment. Going forward, any further > modifications to a stable API must be backwards-compatible with > previously released versions. Upgrades must not lose any persistent > state associated with stable features. Upgrade processes and their > impact on a deployments (downtime, etc.) should be consistent for all > stable features. > > In reality, we developers are not perfect, and minor (or more > significant) changes may be identified as necessary or highly desirable > once early adopters of the new feature have had a chance to use it. > These changes may be difficult or impossible to do in a way that honors > the guarantees associated with stable features. > > For new features that effect the "core" Neutron API and therefore impact > all Neutron deployments, the stability requirement is strict. But for > features that do not effect the core API, such as services whose > deployment is optional, the stability requirement can be relaxed > initially, allowing time for feedback from early adopters to be > incorporated before declaring these APIs stable. The key in doing this > is to manage the expectations of developers, packagers, operators, and > end users regarding these new optional features while they stabilize. > > I therefore propose that we manage these expectations, while new > optional features in the source tree stabilize, by clearly labeling > these features with the term "preview" until they are declared stable, > and sufficiently isolating them so that they are not confused with > stable features. The proposed guidelines would apply during development > as the patches implementing the feature are first merged, in the initial > release containing the feature, and in any subsequent releases that are > necessary to fully stabilize the feature. > > Here are my initial not-fully-baked ideas for how our current process > can be adapted with a "preview feature" concept supporting in-tree > stabilization of optional features: > > * Preview features are implementations of blueprints that have been > reviewed, approved, and targeted for a Neutron release. The process is > intended for features for which there is a commitment to add the feature > to Neutron, not for experimentation where "failing fast" is an > acceptable outcome. > > * Preview features must be optional to deploy, such as by configuring a > service plugin or some set of drivers. Blueprint implementations whose > deployment is not optional are not eligible to be treated as preview > features. > > * Patches implementing a preview feature are merged to the the master > branch of the Neutron source tree. This makes them immediately available > to all direct consumers of the source tree, such as developers, > trunk-chasing operators, packagers, and evaluators or end-users that use > DevStack, maximizing the opportunity to get the feedback that is > essential to quickly stabilize the feature. > > * The process for reviewing, approving and merging patches implementing > preview features is
Re: [openstack-dev] [all] The future of the integrated release
On 08/06/2014 06:10 PM, Michael Still wrote: > > We also talked about tweaking the ratio of "tech debt" runways vs > 'feature" runways. So, perhaps every second release is focussed on > burning down tech debt and stability, whilst the others are focussed > on adding features. I would suggest if we do such a thing, Kilo should > be a "stability' release. As an operator i love this idea, i would really like openstack moving to a model more 'ubuntuish' lts, stability focused releases (K) for production, the other (L) release for pre-prod, trunk for labs ;) -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
