Re: [openstack-dev] [Designate] Core reviewer update
On 02/12/2015 08:51 AM, Hayes, Graham wrote: On 12/02/15 15:50, Kiall Mac Innes wrote: +1 - Tim has been giving good reviews over the last few months and will make a good addition.. Thanks, Kiall On 12/02/15 15:40, Vinod Mangalpally wrote: Hello Designate folks, Betsy Luzader (betsy) resigned from her core reviewer position on Designate. In order to keep the momentum of reviews in Designate going, I'd like to propose adding Tim Simmons (timsim) to designate-core. For context on Designate reviews and who has been active, please see http://stackalytics.com/report/contribution/designate-group/30 Designate members, please reply with your vote on the proposed change. Thanks vinod +1 - I think Tim will make a great addition :) +1 __ 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 __ 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] Lets keep our community open, lets fight for it
I think there's a place for private conversation (eg. discussing a security issue that corresponds to a CVE... CVE's are a special exception and I'd even argue on the need of private conversations there. Discussing CVEs in private came up few times but I'm not sure IRC is secure enough for that. IMHO discussion about embargoed issues must be kept in private Launchpad bugs but I'd like to hear from VMT team. Cheers, Alan __ 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] The API WG mission statement
On 02/10/2015 08:01 AM, Everett Toews wrote: On Feb 9, 2015, at 9:28 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 02/02/2015 02:51 PM, Stefano Maffulli wrote: On Fri, 2015-01-30 at 23:05 +, Everett Toews wrote: To converge the OpenStack APIs to a consistent and pragmatic RESTful design by creating guidelines that the projects should follow. The intent is not to create backwards incompatible changes in existing APIs, but to have new APIs and future versions of existing APIs converge. It's looking good already. I think it would be good also to mention the end-recipients of the consistent and pragmatic RESTful design so that whoever reads the mission is reminded why that's important. Something like: To improve developer experience converging the OpenStack API to a consistent and pragmatic RESTful design. The working group creates guidelines that all OpenStack projects should follow, avoids introducing backwards incompatible changes in existing APIs and promotes convergence of new APIs and future versions of existing APIs. After reading all the mails in this thread, I've decided that Stef's suggested mission statement above is the one I think best represents what we're trying to do. That said, I think it should begin To improve developer experience *by* converging ... :) +1 I think we could be even more explicit about the audience. To improve developer experience *of API consumers by* converging the OpenStack API to a consistent and pragmatic RESTful design. The working group creates guidelines that all OpenStack projects should follow, avoids introducing backwards incompatible changes in existing APIs, and promotes convergence of new APIs and future versions of existing APIs. I’m not crazy about the term API consumer and could bike shed a bit on it. The problem being that alternative terms for API consumer have been taken in OpenStack land. “developer” is used for contributor developers building OpenStack itself, “user” is used for operators deploying OpenStack, and “end user” has too many meanings. “API consumer” makes it clear what side of the API the working group audience falls on. I wouldn't mind API user, I think it conveys intent but doesn't sound as stilted as API consumer. I also like dtroyer’s idea of a Tweetable mantra but I think we need to distill that mantra _from_ a longer mission statement. If we constrained the mission statement to = 140 chars at the outset, we’d be losing valuable information that’s vital in communicating our intent. And if we can’t fully communicate our intent in a mission statement then it doesn’t have as much value. Thanks, Everett __ 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 -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ 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] [glance] Metadef-tags create api change request.
On 2/11/15, 11:10, Okuma, Wayne wayne.ok...@hp.com wrote: Hello, I would like to change the metadef-tags create API which was checked into Kilo (cycle 1). The python-glanceclient that would support metadef-tags has not been released yet and I would like to make this change before doing so. The details are here: https://review.openstack.org/#/c/154229/ Thanks and Regards, Wayne Hey Wayne, Thanks for bringing this to the Mailing List for discussion. Since this was added in K-1, and those milestones are effectively alpha/beta releases I don’t think anyone can have a serious expectation that a feature added after Juno and before Kilo will be stable (and supported) until Kilo is released. This is a clear mistake in the implementation of the spec so it should be fixed before it is too late to fix it. It’s a backwards incompatible change, but it’s only incompatible with an alpha version of the code. There shouldn’t ever be a guarantee of backwards compatibility between K-1 and K-3 (or any of the intermediate milestones). This isn’t to say we should go around breaking features added in one of them while we still can, just that we shouldn’t be so hesitant to fix something that was implemented incorrectly. Cheers, Ian __ 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] Question about force_host skip filters
On 02/12/2015 10:10 AM, Chris Friesen wrote: On 02/12/2015 03:44 AM, Sylvain Bauza wrote: Any action done by the operator is always more important than what the Scheduler could decide. So, in an emergency situation, the operator wants to force a migration to an host, we need to accept it and do it, even if it doesn't match what the Scheduler could decide (and could violate any policy) That's a *force* action, so please leave the operator decide. Are we suggesting that the operator would/should only ever specify a specific host if the situation is an emergency? If not, then perhaps it would make sense to have it go through the scheduler filters even if a host is specified. We could then have a --force flag that would proceed anyways even if the filters don't match. There are some cases (provider networks or PCI passthrough for example) where it really makes no sense to try and run an instance on a compute node that wouldn't pass the scheduler filters. Maybe it would make the most sense to specify a list of which filters to override while still using the others. FWIW, I completely agree with you, Chris. The force_hosts functionality is antithetical to cloud provisioning, (IMO it's a relic of managed hosting operations thinking) and should be removed from the Nova scheduler's feature list. Best, -jay __ 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] Ask for help with devstack error
Hi,
Take a look at this commit, it broke a number of Trove tests last night:
https://review.openstack.org/#/c/154391
Not sure if it’s related, but it seems similar (try manually backing out the
change for cinder and see if it fixes your problem).
Good luck!
Peter
From: liuxinguo [mailto:liuxin...@huawei.com]
Sent: February-12-15 6:57 AM
To: openstack-dev@lists.openstack.org; openstack-in...@lists.openstack.org
Cc: Zhangli (ISSP); Fanyaohong; Chenzongliang
Subject: [openstack-dev] [all] Ask for help with devstack error
Our CI failed when building devstack, the error is about “Unauthorized”.
Following is the segment of the devstacklog:
2015-02-12 11:16:14.639 | + is_service_enabled c-api
2015-02-12 11:16:14.646 | + return 0
2015-02-12 11:16:14.646 | + is_service_enabled tls-proxy
2015-02-12 11:16:14.646 | + _run_process c-vol '/usr/local/bin/cinder-volume
--config-file /etc/cinder/cinder.conf' ''
2015-02-12 11:16:14.647 | + local service=c-vol
2015-02-12 11:16:14.647 | + local 'command=/usr/local/bin/cinder-volume
--config-file /etc/cinder/cinder.conf'
2015-02-12 11:16:14.647 | + local group=
2015-02-12 11:16:14.647 | + exec
2015-02-12 11:16:14.647 | + exec
2015-02-12 11:16:14.658 | + return 1
2015-02-12 11:16:14.658 | + create_volume_types
2015-02-12 11:16:14.659 | + is_service_enabled c-api
2015-02-12 11:16:14.687 | + return 0
2015-02-12 11:16:14.688 | + [[ -n lvm:default ]]
2015-02-12 11:16:14.688 | + local be be_name be_type
2015-02-12 11:16:14.688 | + for be in '${CINDER_ENABLED_BACKENDS//,/ }'
2015-02-12 11:16:14.688 | + be_type=lvm
2015-02-12 11:16:14.688 | + be_name=default
2015-02-12 11:16:14.689 | + cinder type-create default
2015-02-12 11:16:22.734 | ERROR: Unauthorized (HTTP 401) (Request-ID:
req-33c9392a-046f-4894-b22a-1a119eacec62)
In c-api.log, I find the error with “auth_token”:
2015-02-12 03:16:19.722 19912 WARNING keystonemiddleware.auth_token [-]
Retrying on HTTP connection exception: SSL exception connecting to
https://127.0.0.1:35357/
2015-02-12 03:16:20.723 19912 DEBUG keystoneclient.session [-] REQ: curl -g -i
--cacert /opt/stack/data/ca-bundle.pem -X GET https://127.0.0.1:35357/ -H
Accept: application/json -H User-Agent: python-keystoneclient
_http_log_request
/opt/stack/new/python-keystoneclient/keystoneclient/session.py:190
2015-02-12 03:16:20.724 19912 DEBUG urllib3.util.retry [-] Converted retries
value: 0 - Retry(total=0, connect=None, read=None, redirect=0) from_int
/usr/local/lib/python2.7/dist-packages/urllib3/util/retry.py:155
2015-02-12 03:16:22.730 19912 ERROR keystonemiddleware.auth_token [-] HTTP
connection exception: SSL exception connecting to https://127.0.0.1:35357/
2015-02-12 03:16:22.731 19912 WARNING keystonemiddleware.auth_token [-]
Authorization failed for token
Any one can give me some help?
Thanks!
__
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][API] Filtering by metadata values
On 02/10/2015 10:03 PM, Angus Salkeld wrote: On Wed, Feb 11, 2015 at 8:20 AM, Miguel Grinberg miguel.grinb...@gmail.com mailto:miguel.grinb...@gmail.com wrote: Hi, We had a discussion yesterday on the Heat channel regarding patterns for searching or filtering entities by its metadata values. This is in relation to a feature that is currently being implemented in Heat called “Stack Tags”. The idea is that Heat stack lists can be filtered by these tags, so for example, any stacks that you don’t want to see you can tag as “hidden”, then when you request a stack list you can specify that you only want stacks that do not have the “hidden” tag. Some background, the author initially just asked for a field hidden. But it seemed like there were many more use cases that could be fulfilled by having a generic tags on the stack REST resource. This is really nice feature from UI perspective. Tagging would be incredibly useful for larger heat deployments. We were trying to find other similar usages of tags and/or metadata within OpenStack projects, where these are not only stored as data, but are also used in database queries for filtering. A quick search revealed nothing, which is surprising. I have spotted nova's instance tags that look like the kinda beast we are after: - https://blueprints.launchpad.net/nova/+spec/tag-instances - https://review.openstack.org/#/q/topic:bp/tag-instances,n,z Is there anything I may have missed? I would like to know if there anything even remotely similar, so that we don’t build a new wheel if one already exists for this. So we wanted to bring this up as there is a API WG and the concept of tags and filtering should be consistent and we don't want to run off and do something that the WG really doesn't like. I'll bring up this thread in the API-WG meeting, which happens to be in 20 minutes (11AM EST) if anyone sees this soon enough to also attend. But it looks like this needs a bit more fleshing out: http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering Should we just follow nova's instance tags, given the lack of definition in api-wg? Regards Angus Thanks, Miguel __ 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ 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] [Murano] Environment status
Initiall my interest to that problem was caused by the bug [1] due to whose once environment was deployed with failure it stays forever with that status even if it have been deployed sucessfully later. For now status determination happens in three stages: - If at least one of all sessions of env, regardless of version, is in DEPLOYING/DELETING or DEPLOY_FAILURE/DELETE_FAILURE states - state of that session taken as state of environment. Sessions prioritized by version and midification date. - If there is no such sessions, but at least one is in OPENED state - environment state will be PENDING. - Otherwise environment will have READY status. Accordingly to that - once session was deployed with failure - it stays in that status even if it was deployed successfully later. In UI statuses are taken directly from API except another calculated status NEW. Environment matches status NEW if it has version = 0 and it has apps with status 'pending' [2]. After discussion inside Mirantis Murano team we came to these thoughts: - We need to remove statuses that does not related to deployment (PENDING). - Introduce NEVER_DEPLOYED (or NEW) status. - Change READY to DEPLOYED. - Possibly we need to keep state in Environment table in DB and no calculate it queriyng session every time. PENDING status was needed to indicate that another user do something with the environment. But it was decided, that this information must be placed somwhere else, to not be in coflict with deployment status. Another proposal was to additionaly show if environment has some dirty/not-deployed changes in it. First of all let's discuss quick fix of the alghorithm of Environment status matching [3]. I propose to take status of last modified session as status of an environment. At second let's discuss overall situation and more extensive changes that we might want introduce. [1] https://bugs.launchpad.net/murano/+bug/1413260 [2] https://github.com/stackforge/murano-dashboard/blob/master/muranodashboard/environments/api.py#L140-140 [3] https://github.com/stackforge/murano/blob/017d25f49e60e18365a50756f524e15f8d4fa78a/murano/db/services/environments.py#L62 -- With kind regards, Andrew Pashkin. cell phone - +7 (985) 898 57 59 Skype - waves_in_fluids e-mail - apash...@mirantis.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
Re: [openstack-dev] [nova] Question about force_host skip filters
On 02/12/2015 03:44 AM, Sylvain Bauza wrote: Any action done by the operator is always more important than what the Scheduler could decide. So, in an emergency situation, the operator wants to force a migration to an host, we need to accept it and do it, even if it doesn't match what the Scheduler could decide (and could violate any policy) That's a *force* action, so please leave the operator decide. Are we suggesting that the operator would/should only ever specify a specific host if the situation is an emergency? If not, then perhaps it would make sense to have it go through the scheduler filters even if a host is specified. We could then have a --force flag that would proceed anyways even if the filters don't match. There are some cases (provider networks or PCI passthrough for example) where it really makes no sense to try and run an instance on a compute node that wouldn't pass the scheduler filters. Maybe it would make the most sense to specify a list of which filters to override while still using the others. Chris __ 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] [keystone] [nova]
A trust token cannot be used to get another token: https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156 You have to make your Nova client use the very same trust scoped token obtained from authentication using trust without trying to authenticate with it one more time. On Wed, Feb 11, 2015 at 9:10 PM, Adam Young ayo...@redhat.com wrote: On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote: No, I just checked it. Nova receives trust token and raise this error. In my script, I see: http://paste.openstack.org/show/171452/ And as you can see, token from trust differs from direct user's token. The original user needs to have the appropriate role to perform the operation on the specified project. I see the admin role is created on the trust. If the trustor did not have that role, the trustee would not be able to exececute the trust and get a token. It looks like you were able to execute the trust and get a token, but I would like you to confirm that, and not just trust the keystone client: either put debug statements in Keystone or call the POST to tokens from curl with the appropriate options to get a trust token. In short, make sure you have not fooled yourself. You can also look in the token table inside Keystone to see the data for the trust token, or validate the token via curl to see the data in it. In all cases, there should be an OS-TRUST stanza in the token data. If it is still failing, there might be some issue on the Policy side. I have been assuming that you are running with the default policy for Nova. http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json I'm not sure which rule matches for list servers (Nova developer input would be appreciated) but I'm guessing it is executing the rule admin_or_owner: is_admin:True or project_id:%(project_id)s, Since that is the default. I am guessing that the project_id in question comes from the token here, as that seems to be common, but if not, it might be that the two values are mismatched. Perhaps there Proejct ID value from the client env var is sent, and matches what the trustor normally works as, not the project in question. If these two values don't match, then, yes, the rule would fail. On Wed, Feb 11, 2015 at 7:55 PM, Adam Young ayo...@redhat.com wrote: On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote: Hi ! I investigated trust's use cases and encountered the problem: When I use auth_token obtained from keystoneclient using trust, I get *403* Forbidden error: *You are not authorized to perform the requested action.* Steps to reproduce: - Import v3 keystoneclient (used keystone and keystoneclient from master, tried also to use stable/icehouse) - Import v3 novaclient - initialize the keystoneclient: keystone = keystoneclient.Client(username=username, password=password, tenant_name=tenant_name, auth_url=auth_url) - create a trust: trust = keystone.trusts.create( keystone.user_id, keystone.user_id, impersonation=True, role_names=['admin'], project=keystone.project_id ) - initialize new keystoneclient: client_from_trust = keystoneclient.Client( username=username, password=password, trust_id=trust.id, auth_url=auth_url, ) - create nova client using new token from new client: nova = novaclient.Client( auth_token=client_from_trust.auth_token, auth_url=auth_url_v2, project_id=from_trust.project_id, service_type='compute', username=None, api_key=None ) - do simple request to nova: nova.servers.list() - get the error described above. Maybe I misunderstood something but what is wrong? I supposed I just can work with nova like it was initialized using direct token. From what you wrote here it should work, but since Heat has been doing stuff like this for a while, I'm pretty sure it is your setup and not a fundamental problem. I'd take a look at what is going back and forth on the wire and make sure the right token is being sent to Nova. If it is the original users token and not the trust token, then you would see that error. -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 -- Best Regards, Nikolay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
[openstack-dev] [Designate] Core reviewer update
Hello Designate folks, Betsy Luzader (betsy) resigned from her core reviewer position on Designate. In order to keep the momentum of reviews in Designate going, I'd like to propose adding Tim Simmons (timsim) to designate-core. For context on Designate reviews and who has been active, please see http://stackalytics.com/report/contribution/designate-group/30 Designate members, please reply with your vote on the proposed change. Thanks vinod __ 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] Lets keep our community open, lets fight for it
On 2015-02-12 17:20:37 +0100 (+0100), Alan Pevec wrote: Discussing CVEs in private came up few times but I'm not sure IRC is secure enough for that. IMHO discussion about embargoed issues must be kept in private Launchpad bugs but I'd like to hear from VMT team. I do from time to time /msg a security review liaison for some particular project to bring a new vulnerability report to their attention or prod them to put a status update in an embargoed bug. I connect to IRC via SSL/TLS, authenticate and protect my nick through the network's nickserv bot and hope most of them follow the same precautions. Nevertheless I do try not to discuss specifics, but rather keep those brief exchanges vague/general. In the end I'm not sure private, encrypted, authenticated discussion in IRC is substantially less secure than having a bug set to private in launchpad though (after all, I and the rest of the project infrastructure admins don't run either freenode nor launchpad so we're beholden to them to keep their services above board regardless). The VMT also do collectively have brief private discussions with one another via a variety of secured media around logistics/coordination efforts and to perform last-minute checks of our advisory texts prior to disclosure, but I don't want to paint the VMT in a special light here and feel that the point of all this is that the result of any such discussions should be reflected in public as soon as it is safe to do so (be that making the bug visible to everyone, sending an OSSA to various mailing lists, pushing patches into Gerrit, et cetera). -- Jeremy Stanley signature.asc Description: Digital signature __ 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] [Murano] [API WG] Environment status
On 02/12/2015 10:52 AM, Georgy Okrokvertskhov wrote: I think this is a good case for API WG as statuses of entities should be consistent among OpenStack APIs. As I recall, we are mixing two different statuses for environments. The first dimension for environment status is its content status: NEW, CONFIGURING, READY The second dimension is deployment status after Murano engine executes deployment action for this environment with statuses: NOT DEPLOYED, DEPLOYING, SUCCESS, FAIL Thanks Gosha One place we use these pretty extensively is in Heat and Ceilometer. Ceilometer: OK, INSUFFICIENT_DATA, ALARM In heat we have the notion of status and actions. Actions are something you do, a status is how the action has resolved. Actions: INIT, CREATE, DELETE, UPDATE, ROLLBACK, SUSPEND, RESUME, ADOPT, SNAPSHOT, CHECK Status: IN_PROGRESS FAILED COMPLETE This is presented to the user combined (e.g. INIT_COMPLETE or ROLLBACK_FAILED) together. On Thu, Feb 12, 2015 at 7:38 AM, Andrew Pashkin apash...@mirantis.com mailto:apash...@mirantis.com wrote: Initiall my interest to that problem was caused by the bug [1] due to whose once environment was deployed with failure it stays forever with that status even if it have been deployed sucessfully later. For now status determination happens in three stages: - If at least one of all sessions of env, regardless of version, is in DEPLOYING/DELETING or DEPLOY_FAILURE/DELETE_FAILURE states - state of that session taken as state of environment. Sessions prioritized by version and midification date. - If there is no such sessions, but at least one is in OPENED state - environment state will be PENDING. - Otherwise environment will have READY status. Accordingly to that - once session was deployed with failure - it stays in that status even if it was deployed successfully later. In UI statuses are taken directly from API except another calculated status NEW. Environment matches status NEW if it has version = 0 and it has apps with status 'pending' [2]. After discussion inside Mirantis Murano team we came to these thoughts: - We need to remove statuses that does not related to deployment (PENDING). - Introduce NEVER_DEPLOYED (or NEW) status. - Change READY to DEPLOYED. - Possibly we need to keep state in Environment table in DB and no calculate it queriyng session every time. PENDING status was needed to indicate that another user do something with the environment. But it was decided, that this information must be placed somwhere else, to not be in coflict with deployment status. Another proposal was to additionaly show if environment has some dirty/not-deployed changes in it. First of all let's discuss quick fix of the alghorithm of Environment status matching [3]. I propose to take status of last modified session as status of an environment. At second let's discuss overall situation and more extensive changes that we might want introduce. [1] https://bugs.launchpad.net/murano/+bug/1413260 [2] https://github.com/stackforge/murano-dashboard/blob/master/muranodashboard/environments/api.py#L140-140 [3] https://github.com/stackforge/murano/blob/017d25f49e60e18365a50756f524e15f8d4fa78a/murano/db/services/environments.py#L62 -- With kind regards, Andrew Pashkin. cell phone - +7 (985) 898 57 59 tel:%2B7%20%28985%29%20898%2057%2059 Skype - waves_in_fluids e-mail - apash...@mirantis.com mailto:apash...@mirantis.com __ 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com http://www.mirantis.com/ Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ 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 -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ 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] [glance] Metadef-tags create api change request.
On 2/12/15, 9:57 AM, Ian Cordasco ian.corda...@rackspace.com wrote: On 2/11/15, 11:10, Okuma, Wayne wayne.ok...@hp.com wrote: Hello, I would like to change the metadef-tags create API which was checked into Kilo (cycle 1). The python-glanceclient that would support metadef-tags has not been released yet and I would like to make this change before doing so. The details are here: https://review.openstack.org/#/c/154229/ Thanks and Regards, Wayne Hey Wayne, Thanks for bringing this to the Mailing List for discussion. Since this was added in K-1, and those milestones are effectively alpha/beta releases I don¹t think anyone can have a serious expectation that a feature added after Juno and before Kilo will be stable (and supported) until Kilo is released. This is a clear mistake in the implementation of the spec so it should be fixed before it is too late to fix it. It¹s a backwards incompatible change, but it¹s only incompatible with an alpha version of the code. There shouldn¹t ever be a guarantee of backwards compatibility between K-1 and K-3 (or any of the intermediate milestones). This isn¹t to say we should go around breaking features added in one of them while we still can, just that we shouldn¹t be so hesitant to fix something that was implemented incorrectly. Cheers, Ian +1. I agree with Ian on all points. I don¹t see a problem with this change. cheers, brian __ 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] [Designate] Core reviewer update
+1 - Tim has been giving good reviews over the last few months and will make a good addition.. Thanks, Kiall On 12/02/15 15:40, Vinod Mangalpally wrote: Hello Designate folks, Betsy Luzader (betsy) resigned from her core reviewer position on Designate. In order to keep the momentum of reviews in Designate going, I'd like to propose adding Tim Simmons (timsim) to designate-core. For context on Designate reviews and who has been active, please see http://stackalytics.com/report/contribution/designate-group/30 Designate members, please reply with your vote on the proposed change. Thanks vinod __ 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 signature.asc Description: OpenPGP digital signature __ 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] [Murano] [API WG] Environment status
I think this is a good case for API WG as statuses of entities should be consistent among OpenStack APIs. As I recall, we are mixing two different statuses for environments. The first dimension for environment status is its content status: NEW, CONFIGURING, READY The second dimension is deployment status after Murano engine executes deployment action for this environment with statuses: NOT DEPLOYED, DEPLOYING, SUCCESS, FAIL Thanks Gosha On Thu, Feb 12, 2015 at 7:38 AM, Andrew Pashkin apash...@mirantis.com wrote: Initiall my interest to that problem was caused by the bug [1] due to whose once environment was deployed with failure it stays forever with that status even if it have been deployed sucessfully later. For now status determination happens in three stages: - If at least one of all sessions of env, regardless of version, is in DEPLOYING/DELETING or DEPLOY_FAILURE/DELETE_FAILURE states - state of that session taken as state of environment. Sessions prioritized by version and midification date. - If there is no such sessions, but at least one is in OPENED state - environment state will be PENDING. - Otherwise environment will have READY status. Accordingly to that - once session was deployed with failure - it stays in that status even if it was deployed successfully later. In UI statuses are taken directly from API except another calculated status NEW. Environment matches status NEW if it has version = 0 and it has apps with status 'pending' [2]. After discussion inside Mirantis Murano team we came to these thoughts: - We need to remove statuses that does not related to deployment (PENDING). - Introduce NEVER_DEPLOYED (or NEW) status. - Change READY to DEPLOYED. - Possibly we need to keep state in Environment table in DB and no calculate it queriyng session every time. PENDING status was needed to indicate that another user do something with the environment. But it was decided, that this information must be placed somwhere else, to not be in coflict with deployment status. Another proposal was to additionaly show if environment has some dirty/not-deployed changes in it. First of all let's discuss quick fix of the alghorithm of Environment status matching [3]. I propose to take status of last modified session as status of an environment. At second let's discuss overall situation and more extensive changes that we might want introduce. [1] https://bugs.launchpad.net/murano/+bug/1413260 [2] https://github.com/stackforge/murano-dashboard/blob/master/muranodashboard/environments/api.py#L140-140 [3] https://github.com/stackforge/murano/blob/017d25f49e60e18365a50756f524e15f8d4fa78a/murano/db/services/environments.py#L62 -- With kind regards, Andrew Pashkin. cell phone - +7 (985) 898 57 59 Skype - waves_in_fluids e-mail - apash...@mirantis.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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ 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] [vmware-api] Weekly meeting
Hi, Over the last few IRC meetings we have discussed the following: 1. Providing a platform for people other than those working on the Nova driver to take part. There are efforts with the Glance, Cinder, Ceilometer and Neutron projects. Hopefully people working on those can also take part and we can share and discuss ideas, painpoints, bugs etc. 2. Meeting time. We have also spoken about alternating the meeting times so that people in different timezones can take part. At the moment we have Wednesday 17:00 UTC. How does the option of alternate weeks doing at 9:00 UTC? Thanks Gary __ 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] Lets keep our community open, lets fight for it
On 2015-02-12 10:35:18 + (+), Kuvaja, Erno wrote: [...] I'd like to point out that that this discussion has been pushing all inclusive open approach. Not ATC, not specially approved individuals, but everyone. Mailing list can easily facilitate participation of everyone who wishes to do so. Summits cannot. If we pull the line to ATCs and specially invited individuals, we can throw this whole topic to the trash as 90% of the discussed was just dismissed. [...] And perhaps I too should have been more clear. Plenty of people who have not contributed a patch to a project but contribute to the community in other ways also get free passes to the conference and qualify for travel assistance funding. It's just that we have an easy way to track code contributions so we can wrap some automation around that (along with people who have speaking proposals accepted, who assist as track chairs, who volunteer to assist with day-of tasks for the conference, et cetera), but anyone else who is consistently contributing should feel free to reach out and request complimentary passes or assistance. -- Jeremy Stanley __ 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] [Designate] Core reviewer update
On 12/02/15 15:50, Kiall Mac Innes wrote: +1 - Tim has been giving good reviews over the last few months and will make a good addition.. Thanks, Kiall On 12/02/15 15:40, Vinod Mangalpally wrote: Hello Designate folks, Betsy Luzader (betsy) resigned from her core reviewer position on Designate. In order to keep the momentum of reviews in Designate going, I'd like to propose adding Tim Simmons (timsim) to designate-core. For context on Designate reviews and who has been active, please see http://stackalytics.com/report/contribution/designate-group/30 Designate members, please reply with your vote on the proposed change. Thanks vinod +1 - I think Tim will make a great addition :) __ 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] [all][tc] Lets keep our community open, lets fight for it
Flavio, Thanks for your email. I've read your response as well as those from all the others who responded and one thing is very unclear to me in the position being advanced. You write, and other respondents appear to share the following sentiment: | I personally don't care if you have private discussions with other folks | regardless of what their ATC status and impact on the community is. You're | free to do so, I don't plan to critizice that and that's entirely your | problem. However, I do care when those discussions happen in a private IRC | channel because I don't beleive that's neither good for our community nor | necessary. How is a private IRC channel any different from a culture of private discussions? Having a chat over lunch, in the hallway, on the telephone, etc., If [hypothetically] you and I were located in the same location and were having these conversations and someone else joined us, we could just as well change the subject, no? I fail to understand the fascination and focus on a private IRC channel as being somehow the instrument of evil and the cause of back room decisions that needs special attention? If you don't care with whom I have private conversations [and] any impact they may have on the community, how come you view private IRC channels as being different? To be clear, I'm opposed to private conversations of all kinds if they impact the decision making in the community. And I agree with you that the correct approach is to build a culture where open conversation and discussion are fostered and encouraged. And a community where when people hear the statements similar to what you describe as it was discussed in a call, they feel empowered to push back and force an open discussion. So to summarize my first question, what's so evil about IRC (specifically) that you think it is bad but other private discussions that impact the community are not? Now, I have to assume that you are speculating that in these password protected IRC channels to which you have no access, there are all these decisions being made and discussions being had that you (and others) are being excluded from. And that the information therein is never revealed to the outside world and that this is bad for the community. I am a member of several private, password protected IRC channels (where the participants are OpenStack ATC's). After I read your email, I thought long and hard about what I'd seen in these private IRC channels. I can honestly tell you that: (a) the discussions there that could have been had on a public medium had nothing to do with OpenStack (unless OpenStack is impacted by the musical preferences of some participants, or OpenStack was adversely impacted by the fact that some people really love barbecue from a specific place, xkcd cartoons, and in one case a person saying he was leaving his [then] current employer and moving to a new workplace. I can give you some more if you would like but I think you get the idea). Oh, and someone shared a cute youtube video of their house lit up to music and it made me wonder whether I could do that with my raspberry Pi. (b) the discussions that related to OpenStack could not have been had on a public medium. They involved things of a legal nature, they involved things of a sensitive and confidential nature, and they involved a couple of bugs that related to security. The information about the barbecue is well known, i.e. there's no password required to go to this establishment but you have to get there at about 9am and wait in line. The fact that the individual in question has moved on from his [then] current employer is now also known. The discussion about the legal issues resulted in some actions being taken in the project, some code changes, some private conversations, and some not-insignificant legal expense for the parties involved. The issues relating to the security bugs have been addressed. The sensitive personnel issues are still a work in progress [I believe], but that’s my opinion. So, I don't believe that there is anything happening in the channel(s) that I know of that I would consider to be detrimental to open communication in the community. And if anyone required me to have some of these conversations in public rather than in private I would rather leave the community in a hurry for fear of prosecution for slander [or libel depending on whether IRC is considered written or oral]. I firmly believe that it is important for us to build a community where open discussion and participation are important. And I didn't know about the programs you describe (outreach and GSoC) but I'll find out more and ping you about those (in a private message :)). I know not that which you talk about with respect to the fact that people who have been in the community longer appear to be more not-open. Finally, you write: | Our community is far from perfect but lets try to not make it worse. | So, if
[openstack-dev] [Fuel][Plugins] Versioning, branching, tagging
Hello! I would like to discuss which policy we want to recommend for the versioning, branching and tagging for FUEL plugins and how it should correlate with FUEL/MOS versions/releases. According Fuel Plug-in Guide http://docs.mirantis.com/openstack/fuel/fuel-6.0/plugin-dev.html#metadata-yaml we recommend to use the following standard ( http://semver.org/Semantic Versioning 2.0.0 http://semver.org/) http://semver.org/ for the plugin versioning. IMO, it is a good idea, because in this case we have independent development process and release cycle from the FUEL/MOS. But very often we will need to find out which versions of FUEL/MOS is supported by each version of plugin and vice versa. Of course, we can checkout each version and look into metadata.yaml which contain a list of supported releases of FUEL/MOS, but it is not very convenient. For this purpose we can store this list in the commit message for each tag. It is allow us very quick and easily to get dependencies between plugin versions and FUEL/MOS releases, usging simple command: *git tag -n10*. It also will be very convenient for the CI process. What do you think about it? /Thanks and Best Regards, Andrey./ __ 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] [Designate] Core reviewer update
Changes have been applied, welcome Tim :) On 12/02/15 16:18, Rich Megginson wrote: On 02/12/2015 08:51 AM, Hayes, Graham wrote: On 12/02/15 15:50, Kiall Mac Innes wrote: +1 - Tim has been giving good reviews over the last few months and will make a good addition.. Thanks, Kiall On 12/02/15 15:40, Vinod Mangalpally wrote: Hello Designate folks, Betsy Luzader (betsy) resigned from her core reviewer position on Designate. In order to keep the momentum of reviews in Designate going, I'd like to propose adding Tim Simmons (timsim) to designate-core. For context on Designate reviews and who has been active, please see http://stackalytics.com/report/contribution/designate-group/30 Designate members, please reply with your vote on the proposed change. Thanks vinod +1 - I think Tim will make a great addition :) +1 __ 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 __ 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 signature.asc Description: OpenPGP digital signature __ 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] SDN Security in OpenStack
Hi all, I am a software developer working at HP, I do not work with OpenStack @HP though, only worked with it privately. I am finishing up a Masters and for my dissertation research I am focusing on SDN Security. I wanted to align my research to current SDN uses in the industry and was interested in researching the security of SDN in OpenStack. To help focus and narrow down my research topic it would be helpful to hear from the developers directly working on the Neutron project where they see areas of improvement from a security point of view or are there areas that need more research that would be helpful to the project. As part of the dissertation code will be written, tests will be run and the findings published. If the topic is aligned to industry then that code may be useful. People working close to the project will have a better view of the code and capabilities or lack thereof and may see an opportunity here to have some new functionality researched and contributed over the next 12 weeks. I tired asking the question on Ask OpenStack but it got swiftly closed. https://ask.openstack.org/en/question/60777/what-are-the-biggest-security-challenges-in-openstack-neutron/ If anyone has any comments, thoughts or feedback you can drop me a few lines to patricklism...@gmail.com best regards Patrick __ 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] [Designate] Core reviewer update
Thanks all, I’m honored :) —Tim On Feb 12, 2015, at 10:31 AM, Kiall Mac Innes ki...@macinnes.iemailto:ki...@macinnes.ie wrote: Changes have been applied, welcome Tim :) On 12/02/15 16:18, Rich Megginson wrote: On 02/12/2015 08:51 AM, Hayes, Graham wrote: On 12/02/15 15:50, Kiall Mac Innes wrote: +1 - Tim has been giving good reviews over the last few months and will make a good addition.. Thanks, Kiall On 12/02/15 15:40, Vinod Mangalpally wrote: Hello Designate folks, Betsy Luzader (betsy) resigned from her core reviewer position on Designate. In order to keep the momentum of reviews in Designate going, I'd like to propose adding Tim Simmons (timsim) to designate-core. For context on Designate reviews and who has been active, please see http://stackalytics.com/report/contribution/designate-group/30 Designate members, please reply with your vote on the proposed change. Thanks vinod +1 - I think Tim will make a great addition :) +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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.orgmailto: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.orgmailto: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.orgmailto: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] [nova] Priority resizing instance on same host
Yes, CONF.allow_resize_to_same_host exist, but the meaning is that the current host have chance to be selected in nova-scheduler, the final chosen host maybe not the current host, in this case, the instance will be migrated from current host to chosen host and the image will be copied to the chosen host even if the disk size remain the same. 2015-02-12 15:55 GMT+08:00 Jesse Pretorius jesse.pretor...@gmail.com: On Thursday, February 12, 2015, Rui Chen chenrui.m...@gmail.com wrote: Currently, resizing instance cause migrating from the host that the instance run on to other host, but maybe the current host is suitable for new flavor. Migrating will lead to copy image between hosts if no shared storage, it waste time. I think that priority resizing instance on the current host may be better if the host is suitable. The logic like this: if CONF.allow_resize_to_same_host: filte current host if suitable: resize on current host else: select a host resize on the host I don't know whether there have been some discussion about this question. Please let me know what do you think. If the idea is no problem, maybe I can register a blueprint to implement it. But the nova.conf flag for that already exists? What I would suggest, however, is that some logic is put in to determine whether the disk size remains the same while the cpu/ram size is changing - if so, then resize the instance on the host without the disk snapshot and copy. -- Jesse Pretorius mobile: +44 7586 906045 email: jesse.pretor...@gmail.com skype: jesse.pretorius __ 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] [all][tc] Lets keep our community open, lets fight for it
On 11/02/15 17:19 +, Amrith Kumar wrote: [snip] Mostly, I'm very happy to see Flavio's email which ends with this: All the above being said, I'd like to thank everyone who fights for the openness of our community and encourage everyone to make that a must have thing in each sub-community. You don't need to be core-reviewer or PTL to do so. Speak up and help keeping the community as open as possible. Open decision making and discussion are absolutely the lifeblood of an open source community. And I agree, as an ATC I will fight for the open discussion and decision making. In equal measure, I recognize that I'm human and there are times when a quiet sidebar with someone, either on the telephone, or over a glass of suitable beverage can go further and quicker than any extent of public conversation with the exact same participants. You write: | This is seriously disturbing. Yes, what would be seriously disturbing would be if there were decisions being made without the open/public scrutiny. There seems to be a leap-of-faith that a private IRC channel implies covert decisions and therefore they should be shutdown. OK, great, the Twenty-First Amendment took the same point of view, see how well that worked out. I assure you that later today, tomorrow, and the next day, I will have private conversations with other ATC's. Some will be on the telephone, and some will be on public IRC channels with some totally unique name that you'd never know to guess. But, I will try my best to, and I welcome the feedback when people feel that I deviate from the norm of ensuring public, open discussion and decision making where all are invited to participate. Personally, I think the focus on password protected IRC channels is a distraction from the real issue that we need to ensure that the rapidly growing community is one where public discussion and decision making are still the norm. Let's be adult about it and realize that people will have private conversations. What we need to focus on is ensuring that the community rejects private decision making. I personally don't care if you have private discussions with other folks regardless of what their ATC status and impact on the community is. You're free to do so, I don't plan to critizice that and that's entirely your problem. However, I do care when those discussions happen in a private IRC channel because I don't beleive that's neither good for our community nor necessary. It's not good for our community because it *excludes* people that are not in such channels and it creates the wrong message around what core means, just like it happened with integrated projects and like it happens with PTLs. In addition to that, it isolates discussions which is something we've been encouraging people not to do because not everyone sees it the same way. Furthermore, I don't think it is necessary because at the very end you will have to disclose the discussion in order to make it effective upstream. If this is not happening for you then I really don't want to know it because I'd just rage quit. The reason for that is that the only way to push something upstream without disclosing a hallway/phone conversation is by having a small group of folks pushing whatever was discussed quickly enough to avoid other community interactions, which is more than just wrong. Side Note: note that the above is not an accusation but just a speculation based on your previous email and on the fact that I keep fooling myself with the thought that I had seen it all and then finding out new things. Unfortunately, being an adult doesn't seem to be enough, we're lacking of education on how open-source works and it's affecting a community that we've been fighting to keep open and welcoming. If these casual private conversations are affecting our community, I'd rather not have them than seeing the work of these last years vanish. Our community is far from perfect but lets try to not make it worse. So, if you are participating in a private IRC channel, I ask you to please reconsider leaving such medium and encourage the openness. One last note. As someone that has mentored for the last three cycles in Outreachy and that also mentored in GSoC in one of those cycles (That makes it 4 programs in 3 cycles), I find it very offensive that people that have been longer in this community do the opposite of what I've been encouraging the participants of these programs to do. That is, having the courage to participate in public discussion and engaging with the community. There, I said it, and I said it in the open. And I infinitely thank you for this. Flavio -- @flaper87 Flavio Percoco pgpu_UbK5FTb3.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [nova] Priority resizing instance on same host
Yes, @Lingxian, I agree with you. Only the host pass the scheduler filters, the resizing can success, 'force_hosts' is not enough IMO. 2015-02-12 16:41 GMT+08:00 Lingxian Kong anlin.k...@gmail.com: Hi, Rui, I think resize VM to the same host if the host could pass scheduler filters makes sense to me. 2015-02-12 15:01 GMT+08:00 Rui Chen chenrui.m...@gmail.com: Hi: Currently, resizing instance cause migrating from the host that the instance run on to other host, but maybe the current host is suitable for new flavor. Migrating will lead to copy image between hosts if no shared storage, it waste time. I think that priority resizing instance on the current host may be better if the host is suitable. The logic like this: if CONF.allow_resize_to_same_host: filte current host if suitable: resize on current host else: select a host resize on the host I don't know whether there have been some discussion about this question. Please let me know what do you think. If the idea is no problem, maybe I can register a blueprint to implement it. Best Regards. __ 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 -- Regards! --- Lingxian Kong __ 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] [glance] File-backed glance scrubber queue
On 11/02/15 13:42 -0800, Chris St. Pierre wrote: I recently proposed a change to glance to turn the file-backed scrubber queue files into JSON: https://review.openstack.org/#/c/145223/ As I looked into it more, though, it turns out that the file-backed queue is no longer usable; it was killed by the implementation of this blueprint: https:// blueprints.launchpad.net/glance/+spec/image-location-status But what's not clear is if the implementation of that blueprint should have killed the file-backed scrubber queue, or if that was even intended. Two things contribute to the lack of clarity: 1. The file-backed scrubber code was left in, even though it is unreachable. 2. The ordering of the commits is strange. Namely, commit 66d24bb (https:// review.openstack.org/#/c/67115/) killed the file-backed queue, and then, *after* that change, 70e0a24 (https://review.openstack.org/#/c/67122/) updates the queue file format. So it's not clear why the queue file format would be updated if it was intended that the file-backed queue was no longer usable. Can someone clarify what was intended here? If killing the file-backed scrubber queue was deliberate, then let's finish the job and excise that code. If not, then let's make sure that code is reachable again, and I'll resurrect my blueprint to make the queue files suck less. Either way I'm happy to make the changes, I'm just not sure what the goal of these changes was, and how to properly proceed. Thanks for any clarification anyone can offer. I believe the commit you're looking for is this one: f338a5c870a36e493f8c818fa783942d1e0565a4 There the scrubber queue was switched on purpose, which leads to the conclusion that we're moving away from it. I've not participated in discussions around the change related to the scrubber queue so I'll let Zhi Yan weight in here. Thanks for bringing this up, Flavio P.S: Would you mind putting a link to this discussion on the spec review? -- Chris St. Pierre __ 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 -- @flaper87 Flavio Percoco pgpgi8R3xMssL.pgp Description: PGP signature __ 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] [nova] Question about force_host skip filters
Hi: If we boot instance with 'force_hosts', the force host will skip all filters, looks like that it's intentional logic, but I don't know the reason. I'm not sure that the skipping logic is apposite, I think we should remove the skipping logic, and the 'force_hosts' should work with the scheduler, test whether the force host is appropriate ASAP. Skipping filters and postponing the booting failure to nova-compute is not advisable. On the other side, more and more options had been added into flavor, like NUMA, cpu pinning, pci and so on, forcing a suitable host is more and more difficult. Best Regards. __ 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] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested
Hi Mash, we dropped Ceilometer as the core tool to gather metrics for our rating and billing system. I must admit it has improved, but I think it's broken by design: a metering and monitoring system is not the same thing. We have built a component that directly listens from rabbit notification tools (a-la-Stacktach). This tool stores the all events in a database (but anything could work, it's just a logging system) and then we process these events and store them in a datamart style database every hour. The rating and billing system reads this database and process it every hour too. We decided to implement this pipeline processing of data because we knew in advance that processing such an amount of data was a challenge. I think Ceilometer should be used just to trigger alarms for heat for example, and something else should be used for rating and billing. Cheers Diego -- Diego Parrilla http://www.stackops.com/*CEO* *www.stackops.com http://www.stackops.com/ | * diego.parri...@stackops.com | +34 91 005-2164 | skype:diegoparrilla On Wed, Feb 11, 2015 at 8:37 PM, Maish Saidel-Keesing mais...@maishsk.com wrote: 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-operators mailing list openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ 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] [nova] issues with fakelibvirt in tests
Looking recently at the following failure - http://logs.openstack.org/04/154804/1/gate/gate-nova-python27/1fe94bf/console.html#_2015-02-12_15_02_19_593 It appears that the fakelibvirt fixture is potentially causing races in tests because after the first test in a worker starts a libvirt connection, the libvirt python library spawns a thread which keeps running in a loop for the duration of the tests. This is happening regardless of whether or not the test in question is using libvirt (as in this case). Having threads thumping around in the background means that doing things like testing for when sleep is called can fail because libvirt's thread is getting in the way. What's the proper method of completely tearing down all the libvirt resources so that when this fixture exits it will actually do that correctly - https://github.com/openstack/nova/blob/master/nova/tests/unit/virt/libvirt/fakelibvirt.py#L1181-L1202 and not impact unrelated tests? -Sean -- Sean Dague http://dague.net __ 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] [glance] File-backed glance scrubber queue
Yeah, that commit definitely disables the file-backed queue -- it certainly *looks* like we want to be rid of it, but all of the code is left in place and even updated to support the new format. So my confusion remains. Hopefully Zhi Yan can clarify. Link added. Thanks. On Thu, Feb 12, 2015 at 12:59 AM, Flavio Percoco fla...@redhat.com wrote: On 11/02/15 13:42 -0800, Chris St. Pierre wrote: I recently proposed a change to glance to turn the file-backed scrubber queue files into JSON: https://review.openstack.org/#/c/145223/ As I looked into it more, though, it turns out that the file-backed queue is no longer usable; it was killed by the implementation of this blueprint: https:// blueprints.launchpad.net/glance/+spec/image-location-status But what's not clear is if the implementation of that blueprint should have killed the file-backed scrubber queue, or if that was even intended. Two things contribute to the lack of clarity: 1. The file-backed scrubber code was left in, even though it is unreachable. 2. The ordering of the commits is strange. Namely, commit 66d24bb (https:// review.openstack.org/#/c/67115/) killed the file-backed queue, and then, *after* that change, 70e0a24 (https://review.openstack.org/#/c/67122/) updates the queue file format. So it's not clear why the queue file format would be updated if it was intended that the file-backed queue was no longer usable. Can someone clarify what was intended here? If killing the file-backed scrubber queue was deliberate, then let's finish the job and excise that code. If not, then let's make sure that code is reachable again, and I'll resurrect my blueprint to make the queue files suck less. Either way I'm happy to make the changes, I'm just not sure what the goal of these changes was, and how to properly proceed. Thanks for any clarification anyone can offer. I believe the commit you're looking for is this one: f338a5c870a36e493f8c818fa783942d1e0565a4 There the scrubber queue was switched on purpose, which leads to the conclusion that we're moving away from it. I've not participated in discussions around the change related to the scrubber queue so I'll let Zhi Yan weight in here. Thanks for bringing this up, Flavio P.S: Would you mind putting a link to this discussion on the spec review? -- Chris St. Pierre __ 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 -- @flaper87 Flavio Percoco __ 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 -- Chris St. Pierre __ 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] Lets keep our community open, lets fight for it
On 12/02/15 16:01 +, Amrith Kumar wrote: Flavio, Thanks for your email. I've read your response as well as those from all the others who responded and one thing is very unclear to me in the position being advanced. You write, and other respondents appear to share the following sentiment: | I personally don't care if you have private discussions with other folks | regardless of what their ATC status and impact on the community is. You're | free to do so, I don't plan to critizice that and that's entirely your | problem. However, I do care when those discussions happen in a private IRC | channel because I don't beleive that's neither good for our community nor | necessary. How is a private IRC channel any different from a culture of private discussions? Having a chat over lunch, in the hallway, on the telephone, etc., If [hypothetically] you and I were located in the same location and were having these conversations and someone else joined us, we could just as well change the subject, no? I fail to understand the fascination and focus on a private IRC channel as being somehow the instrument of evil and the cause of back room decisions that needs special attention? If you don't care with whom I have private conversations [and] any impact they may have on the community, how come you view private IRC channels as being different? To be clear, I'm opposed to private conversations of all kinds if they impact the decision making in the community. And I agree with you that the correct approach is to build a culture where open conversation and discussion are fostered and encouraged. And a community where when people hear the statements similar to what you describe as it was discussed in a call, they feel empowered to push back and force an open discussion. So to summarize my first question, what's so evil about IRC (specifically) that you think it is bad but other private discussions that impact the community are not? The problem is not just the private discussion but also the medium where it happens. From a community perspective, if I came to know there's a private channel were things happen, I'd feel excluded and not a part of such community. If we leave aside the emotional implications on other members of the community when there are things like a my-nice-private-gang channel and we focus on the impact it has in the openness of our community and project, it's clear that we would be violating such tenent. When I say I don't care about your private discussions is because I don't. I don't care if you have a quick lunch-talk with someone, I don't care if you have a quick call with someone about a specific issue/blueprint/whatever as long as you bring the results of those discussions to the open. The big difference between a hallway discussion or a quick call and a private IRC channel is that we *don't* have a public voip channel, common office where you can have those coversation in a open enough way to include *everyone*. However, we *do* have public IRC channels - far too many, I'd dare to say - where those conversations can happen. Therefore, I don't believe - and I'll put all my stubbornness on this - there's *ANY* need for private IRC channels that *exclude* other members of this community. You want to have private hallway/phone discussions? Fine, feel free but please, make sure that: 1. The results of those discussions are disclosed afterwards and made available for *further* discussions. 2. All the participants understand that the discussion doesn't *end* there. Now, I have to assume that you are speculating that in these password protected IRC channels to which you have no access, there are all these decisions being made and discussions being had that you (and others) are being excluded from. And that the information therein is never revealed to the outside world and that this is bad for the community. I am a member of several private, password protected IRC channels (where the participants are OpenStack ATC's). After I read your email, I thought long and hard about what I'd seen in these private IRC channels. I can honestly tell you that: (a) the discussions there that could have been had on a public medium had nothing to do with OpenStack (unless OpenStack is impacted by the musical preferences of some participants, or OpenStack was adversely impacted by the fact that some people really love barbecue from a specific place, xkcd cartoons, and in one case a person saying he was leaving his [then] current employer and moving to a new workplace. I can give you some more if you would like but I think you get the idea). Oh, and someone shared a cute youtube video of their house lit up to music and it made me wonder whether I could do that with my raspberry Pi. What about a public #my-openstack-but-not-openstack (a.k.a offtopic) public channel that would welcome other folks in the community to engage? This would also make the $whatever-project community
Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it
On 11/02/15 11:24 +, Chris Dent wrote: On Wed, 11 Feb 2015, Flavio Percoco wrote: During the last two cycles, I've had the feeling that some of the things I love the most about this community are degrading and moving to a state that I personally disagree with. With the hope of seeing these things improve, I'm taking the time today to share one of my concerns. Thanks for writing this. I agree with pretty much everything you say, especially the focus on the mailing list being only truly available and persistent medium we have for engaging everyone. Yes it is noisy and takes work, but it is an important part of the work. I'm not certain, but I have an intuition that many of the suboptimal and moving-in-the-direction-of-closed behaviors that you're describing are the result of people trying to cope with having too much to do with insufficient tools. Technology projects often sacrifice the management of information in favor of what's believed to be the core task (making stuff?) when there are insufficient resources. This is unfortunate because the effective sharing and management of information is the fuel that drives, optimizes and corrects the entire process and thus leads to more effective making of stuff. This thread and many of the threads going around lately speak a lot about people not being able to participate in a way that lets them generate the most quality -- either because there's insufficient time and energy to move the mountain or because each move they make opens up another rabbit hole. As many have said this is not sustainable. Many of the proposed strategies or short term tactics involve trying to hack the system so that work that is perceived to be extraneous is removed or made secondary. This won't fix it. I think it is time we recognize and act on the fact that the corporate landlords that pay many of us to farm on this land need to provide more resources. This will help to ensure the health of semi-artifical opensource ecology that is OpenStack. At the moment many things are packed tight with very little room to breathe. We need some air. I agree with lots of what you said except for this last bit here. I don't believe OpenStack is a semi-artificial opensrouce ecology. OpenStack has demostrated throughout the years the ability of growing without sacrificing openness. Have there been cases where we've failed to do so? Probably but there's always someone that raises the red-flag and calls out the community on the things that are not working well enough. Saying OpenStack is semi-artificial opensource is degrading some of the things most of us have been fighting for. I'm not offended, just worried. We've many similar messages from outside the community and having them coming from within the community is worrisome. That said, I may have mis-understood what you meant so, please correct me if I did. Tired and I should've probably waited 'til tomorrow before replying. Oh well, :D Cheers, Flavio -- @flaper87 Flavio Percoco pgpAgmbwI00Mk.pgp Description: PGP signature __ 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
